We recently added code to discover switches, switch ports and settings - all in the Stealth DiscoveryTM way - without sending out any packets at all! So now you know which switches and which switch ports every monitored server is plugged into. As a bonus we pick up some interesting configuration information on your switch and your particular switch port - just by perking our ears up and listening... Now when you send someone to the closet to do something to your switch port, there is no doubt which port is yours - regardless of that little mistake in the cross-connects, or that tiny error in documentation. [Anyone want to write a cool iPad switch mapping app for this?]
This discovery info is also helps our highly scalable monitoring protocol keep 96% of our heartbeat packets off your backbone network as described on the web site, and our first article on the subject. Of course, if another monitoring system wanted to know your switch connectivity, it would likely ask you to enter it. But that would suck - so we discover it instead. Because we (re-)discover it continually, it stays up to date (within a minute or so), and we can use that discovered information in several ways.
Since most people don't have a clue how to do this let's talk about it... All modern managed switches implement one or both of two link level discovery protocols - LLDP or CDP. These protocols send out unsolicited packets on each switch port about once a minute that tell you things like what switch is your NIC connected to, which port on that switch, what it's IP and MAC addresses are, and other configuration infomation (VLAN, MTU, speed, other things).
So we just listen for those packets and when they change, send them upstream to the CMA which then translates them into JSON and puts them into the database - nodes, relationships and all. So what does that look like when you put it into the database?
If you look on the right, you'll see it introduces a new kind of node - a Switch, and a new relationship "wiredto" which indicates a physical connection between two NICs. In this case, one NIC is in the switch and one is in the host. If you change which port or switch a host is plugged into, we will update the database within a minute or so of its happening. This is Way Cool!
The switch NIC has some interesting information about it - it knows which switch port it is, and pulls some descriptive information about the port from the switch. If you look further, you'll see that we know the switch's administrative address, and the corresponding MAC address - which in this case is the same as the switch's name. Note that at least in this case, this isn't a physical NIC, but a logical one - there is no corresponding jack on the switch.
Since all this information shows up in the database, we can take the switch dependency into account when monitoring, produce a port map for a switch, and of course, properly create the switch-level rings for our monitoring protocol - all without manual configuration! Since we know the switch's administrative address, we can easily monitor it - either continually or when we suspect it of flaking out - again without any manual configuration.
Is this something you'd like to see at your site? Do you know if your site enables LLDP or CDP? What would you do with this information if you had it? What dowsides to this do you envision?
Comments
You can follow this conversation by subscribing to the comment feed for this post.