Network Topology – Completely Reimplemented

Complex
Complex
An over-engineered engine

Dear JDisc friends,

as a developer, you sometimes create solutions that are more complex than needed.

Our algorithm for calculating the network topology is such an example!

We had a lot of ideas about what to implement. Some algorithms are pretty complex and succeed only in an ideal world (which of course rarely exists in the real world 🙂 ). The algorithm also required a pretty complex configuration that we solved using the network topology jobs.

Those topology jobs were running on a regular base (e.g. every 15 minutes). However, it was not obvious which networks should have topology jobs enabled. That was confusing for customers. Furthermore, troubleshooting topology issues was nearly impossible without having the complete database with all port forwarding information included. And even then, it took hours for us to troubleshoot the issue and fix it.

Therefore, we decided to reimplement the network topology detection. The confusing topology jobs are gone and the topology information (CDP, LLDP, and mac forwarding entries) are being read when a switch gets scanned! So when the Networking add-on is installed, the topology gets calculated out of the box without any manual configuration.

In networks, where CDP or LLDP are not used, they can be disabled within the protocols section.

Protocols Discovery Configuration - Protocols

We also experienced that some devices have issues in their CDP or LLDP implementation. We got incorrect information when reading the CDP and LLDP tables via SNMP. In those cases, CDP or LLDP can be disabled individually for the switch. This avoids processing false information from the switch.

DisableDevice UDP and ODP Protocols

Is the topology algorithm now perfect? Unfortunately, the answer is: NO. There may be circumstances that might lead to incomplete or even wrong network topology. The root cause is usually mixing different switch vendors and mix the protocols (e.g. some switches run CDP, some run LLDP and others might run none of them).

So let’s suppose we have three switches (Switch A, Switch B and Switch C). Switch A, Port 1 is connected to Switch B, Port 1. Switch B, Port 2 is connected to Switch C, Port 1.

CDP_LLDP A simple Switch Topology
A simple Switch Topology

Switch A and C have CDP configured, Switch B does not support CDP. Since Switch B does not reply to CDP requests, Switch A thinks that it is directly connected to Switch C. When JDisc Discovery reads CDP information from Switches A and C, then it gets incomplete information that those two switches are directly connected. Switch B is not visible because it is not supporting CDP.

In combination with LLDP, it might even be more complex. LLDP and CDP information might provide different connections due to supported or not supported protocols on the switches.

Whenever you know, that CDP or LLDP information for a switch is incomplete or not correct, then you can disable CDP or LLDP for individual switches using the context menu Manage > Disable Discovery Protocols.

I hope, that those changes make it more intuitive and easier to get a network topology. But always keep in mind. Especially heterogeneous networks supporting different protocols might cause trouble…

These changes are being released with build 5019.

Cheers,
Thomas

About The Author

Thomas Trenz
I own and manage JDisc and its network inventory and discovery products. Before I started JDisc, I worked quite a long time for Hewlett-Packard developing software for network assessments and inventory projects. Feel free to contact me on Linked-In or Xing.

Leave A Comment


The reCAPTCHA verification period has expired. Please reload the page.

Network Topology – Completely Reimplemented

Complex
Complex
An over-engineered engine

Dear JDisc friends,

as a developer, you sometimes create solutions that are more complex than needed.

Our algorithm for calculating the network topology is such an example!

We had a lot of ideas about what to implement. Some algorithms are pretty complex and succeed only in an ideal world (which of course rarely exists in the real world 🙂 ). The algorithm also required a pretty complex configuration that we solved using the network topology jobs.

Those topology jobs were running on a regular base (e.g. every 15 minutes). However, it was not obvious which networks should have topology jobs enabled. That was confusing for customers. Furthermore, troubleshooting topology issues was nearly impossible without having the complete database with all port forwarding information included. And even then, it took hours for us to troubleshoot the issue and fix it.

Therefore, we decided to reimplement the network topology detection. The confusing topology jobs are gone and the topology information (CDP, LLDP, and mac forwarding entries) are being read when a switch gets scanned! So when the Networking add-on is installed, the topology gets calculated out of the box without any manual configuration.

In networks, where CDP or LLDP are not used, they can be disabled within the protocols section.

Protocols Discovery Configuration - Protocols

We also experienced that some devices have issues in their CDP or LLDP implementation. We got incorrect information when reading the CDP and LLDP tables via SNMP. In those cases, CDP or LLDP can be disabled individually for the switch. This avoids processing false information from the switch.

DisableDevice UDP and ODP Protocols

Is the topology algorithm now perfect? Unfortunately, the answer is: NO. There may be circumstances that might lead to incomplete or even wrong network topology. The root cause is usually mixing different switch vendors and mix the protocols (e.g. some switches run CDP, some run LLDP and others might run none of them).

So let’s suppose we have three switches (Switch A, Switch B and Switch C). Switch A, Port 1 is connected to Switch B, Port 1. Switch B, Port 2 is connected to Switch C, Port 1.

CDP_LLDP A simple Switch Topology
A simple Switch Topology

Switch A and C have CDP configured, Switch B does not support CDP. Since Switch B does not reply to CDP requests, Switch A thinks that it is directly connected to Switch C. When JDisc Discovery reads CDP information from Switches A and C, then it gets incomplete information that those two switches are directly connected. Switch B is not visible because it is not supporting CDP.

In combination with LLDP, it might even be more complex. LLDP and CDP information might provide different connections due to supported or not supported protocols on the switches.

Whenever you know, that CDP or LLDP information for a switch is incomplete or not correct, then you can disable CDP or LLDP for individual switches using the context menu Manage > Disable Discovery Protocols.

I hope, that those changes make it more intuitive and easier to get a network topology. But always keep in mind. Especially heterogeneous networks supporting different protocols might cause trouble…

These changes are being released with build 5019.

Cheers,
Thomas

About The Author

Thomas Trenz
I own and manage JDisc and its network inventory and discovery products. Before I started JDisc, I worked quite a long time for Hewlett-Packard developing software for network assessments and inventory projects. Feel free to contact me on Linked-In or Xing.

Leave A Comment


The reCAPTCHA verification period has expired. Please reload the page.