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.Read the full article.