Probably one of the more difficult things to do when you have an extremely large network, is map out the structure of that network. Especially if you want to monitor the devices on that make up that network.  Why would you need to know the structure of the network if you’re monitoring it? Well, If you’re monitoring 400 switches and 1 of those switches go down, but 125 switches uplinked from that 1 down switch, do you really want 126 notifications that you have down equipment?  I think not.  So what are your options? Well you could just be the ultimate IT Ninja and know exactly how your giant network is setup, you could manually go out and map out what switch uplinks to other switches, or you could turn to a little feature that has been a part of Enterasys’ switches for a long time, but more on that later.

Some Background Stuff About Icinga and Nagios

First of all, Icinga is a fork of the Nagios project. The process of configuring network devices is nearly if not totally identical between the two. In my setup I have each switch configured in its own directory, with its own config file for host, and a file for each service associated with that host. But you can organize the configurations however you would like.

Back to that Enterasys Thing

So, the Enterasys and Old Cabletron equipment have a feature called the Cabletron Discovery Protocol (CDP), not to be confused with the Cisco Discovery Protocol (which may or may not work the same way). Enterasys hasn’t dropped CDP even from their latest K series switches either. I can’t speak too much on how CDP works, so I’m just going to tell you how we’re using it to build our network configuration in Icinga.

Enterasys Netsight Console

From the Netsight Console we are able to load a flexview that displays CDP Neighbor Info.  CDP Neighbor Info, you ask? When you select a set of switches, this flexview will display all of their neighboring switches in a table.  A lot of the Cabletron DP data can be pulled via snmp, but I haven’t had time to write the script to do that just yet. That will be a future project.

Once you have the neighbor switch data you can export the flexview output to a CSV file that will be used by the next phase of this project.

You said something about Python?

Python has been my favorite programming language since I was forced to learn it during my first year of college (Thank You University of Northern Iowa). This first script that I wrote in Python creates a “graph” data structure. If you’re not sure what I’m talking about, click here. The original purpose of this script actually had nothing to do with Icinga, instead it was created to find the farthest end point switches on the network.

Back to the script, The Python Graphs are actually implemented using a Python Dictionary data structure.  Where each switch is its own Key while each key’s value is a python list of the switches neighbors.

For Example,

graph={'a':['b','d','f'],
            'b':['a'],
            'd':['b','a'],
            'f':['a']}

Once the graph is built, a shortest path algorithm is ran on each switch. In our case we find the shortest path from each switch to our core switch. In my opinion, I believe that you should actually find the shortest path to the switch that your icinga/nagios server is connected to, but in our case the icinga vm tends to move between several switches. Anyways, the shortest path algorithm I run, creates a list of lists, where each element in the list is a path. That path is display as a list of switches going to the core. Once that shortest path list is created, I use a nifty feature in Python called Pickle, that lets me dump that data structure to be used by any other scripts.

Quick thing about Pickling

When Pickling a data structure such as a list in Python, Python serializes the data structure and writes it out to a binary file.  This is in NO WAY SECURE.  Anyone who has write access to that file could potentially inject code in to it. However, the nice thing is, when I write another script that needs that same data structure, once I depickle the file, I have instant access to the data structure without having to rebuild the entire list of lists.

Building the Nagios config

This part is pretty straight forward.  Pretty much you write a script that outputs text files of your configuration, but you want your network layout to be part of the configuration.  Icinga & Nagios have a nice little setting that you can set in each device config called parent. That is where you identify who the the switch uplinks to. The best way to figure this out is to loop through that list of shorest paths you created in the previous phase. The important thing to remember is that in each path, there are only 2 switches that are important.  Also, I should mention that the shortest paths that were created have the core switch or whoever you were finding that path to, at the end of each path. Back to the 2 important switches.  The first switch in each path is the switch that you’ll write your configurations for, while the second switch in each path is the parent switch of the first.

So once you have the configurations built, Icinga will know how your network infrastructure is mapped. So if a switch with 20 switches below it go down. Icinga will note in the web interface the 20 other switches are unreachable, but say that the 1 switch went critical and it will only notify you that the one switch went down.

If you have any questions or comments, feel free to leave them in the comments below. If you would like to request some code, please email support@rychannel.com.