Network Topology discovery with CDP
Starting from TKU November 2022, network topology discovery with CDP is supported. The network topology discovery via LLDP is already supported, for details, see here. LLDP data prevails over CDP data, but when LLDP is unable, it is necessary to use CDP data on Cisco devices to collect topology information.
Discovery relies on CDP data obtained via SNMP to find Network Topology links between Cisco:
- NetworkDevice nodes
- SNMPManagedDevice and NetworkDevice nodes
- ManagementController and NetworkDevice nodes
The example of visualization of the discovered Network Topology.
and the Infrastructure section of the discovered Network Device.
Supported Discovery versions
The minimum supported Discovery version is 21.05 (12.2).
How it works
Module Layer_2_Discovery has three patterns CDP_Discovery_NetworkDevice, CDP_Discovery_ManagementController, and CDP_Discovery_SNMPManagedDevice, each triggering on appropriate node - Network Device, Management Controller, and SNMP Managed Device with hidden attribute __cdp_device_id set.
After triggering, the pattern finds all the local Network Interfaces with hidden attribute __cdp_port_name attribute set.
For each Network Interface found, the pattern tries to find the corresponding CDP remote 'neighbour' interface using the CDP-related attributes:
- '__cdp_remote_sysname' or '__cdp_remote_device_id': to find remote 'neighbour' device
- '__cdp_remote_port_name': to find the interface on the remote device
The pattern then creates relationships between Network Interfaces on the local and remote devices.
There can be two different relationships created:
- "with impact"—where one device is acting as EdgeClient (the one who is impacted) and another like EdgeDevice (the one who is impacted).
- "without impact" or Peer-to-Peer relationship.
The pattern creates relationships mentioned above based on the following:
- If the local device capability belongs to client_capabilities table and the remote device
does not, then the local interface is EdgeClient, and remote is EdgeDevice; - If remote device capability belongs to client_capabilities table and the local device
does not, then the remote interface is EdgeClient, and the local is EdgeDevice; - Peer-to-Peer relationships in other cases.
CMDB mapping
- Only "with impact" relationships are synced to CMDB (EdgeClient-EdgeDevice). Peer-to-Peer relathionships are NOT synced to CMDB.
This is because, in the CMDB, all relationships are directional – they have a Source end and a Destination end. If we don’t know the direction of a device-to-device connection, then we represent it in Discovery with a Peer to Peer relationship, but there is no such thing in the CMDB.
- Only "with impact" relationships are synced to CMDB (EdgeClient-EdgeDevice). Peer-to-Peer relathionships are NOT synced to CMDB.
Important notes and pre-requisites
- It might require several scans of the devices to build the entire topology
- Network Topology is made based on CDP data obtained via SNMP. Hence, the discovered devices must be properly configured with CDP
- CDP patterns would not create L2 topology between interfaces if the same one were made with LLDP patterns.