Graph Database Model for Network Management

This is a very simple approach to modelling network via graph database.

I have tried to model network as we draw on whiteboard while working on project for simple network monitoring tool to detect failure or alarms from the devices.

First step is to model the device with its connected interfaces which will be enough for the beginning (device-[contains]-interface).  After that each device will be connected to another device via its’s interfaces. I model the interface as a vertex/node. Logical interfaces will be the leaf of the physical interfaces. We can set the status of each interface individually without touching the root interface. If there is an alarm on the root interface it will be very easy to set all leaf interface status.

 

Level 2 network data model for Graph Database

 

Why I don’t directly connect the device interfaces to the remote device interface? : Generally devices are connected via another physical/logical layer. Devices can be directly connected (without any physical devices) which can be local cabling that is a fiber, a copper or they can be connected via another provider or another logical layer by means of vlan’s. For all them this connection represented via Circuit. By adding circuit, we can add dependency for the connection between devices to a another layer.

With this information you can get the effected circuits after a breakout in the lower layer like fiber cut or upper provider failure. (Return circuit depends on fiber? which will be an easy query for graph database). Also you can add more dependency at lower layers like this fiber depends on that route or fiber group.

Next step is modelling the logical connections between devices, our backbone. I modelled IGP connections as LINK and IP connections for devices that do not have IGP configured as UPSTREAM (access devices like DSLAM). BGP-LS node and link notifications reflected to the database to set node or relation status (with reach and unreach NLRI). If an IGP node is down this means all the devices connected this node (connected to backbone via single logical ip link) are down. First you get the nodes that have an upstream relation with the node that is subject to BGP-LS message. If the current node is down this means all the nodes that behind it is down. (of down set all nodes-[upstream]->downnode status to down). If a link is down set link status to down, check if nodes related both with the link has an another link thats status is up (return node-[:LINK {status:up}]-node. If no link returns this means that node’s unreachable. Set its status and all nodes which has upstream like connected  behind it is down.  If its a up message you set the status of all nodes behind it as warn (actually those node may be down and may need further lookup). Also messages coming from devices or any monitoring tool like syslog, snmp,  cacti graph alarms etc reflected to the database.

Above that you can add multiple layers like services that’s depend on a device. Or you can more node types like BGP sessions or L2 tunnels or customers that connected or depend on a device.

Grouping of devices may also be modelled via separate nodes like CITY and node should have BELONGS to relation to that group. Also nested groups can be used like; device BELONGS to a pop, pop BELONGS a CITY or you may add group membership as an attribute to nodes. Sure this will be needed for virtualisation of network. Other wise IT’s very hard to browse hundreds of nodes via GUI.

TOOLS :

Drawing Tool : https://www.draw.io