Network Topology discovery with LLDP

Starting from TKU July 2021 network topology discovery with LLDP is supported.

Discovery relies on LLDP data obtained via SNMP in order to find Network Topology links between:

• NetworkDevice nodes
• StorageDevice and NetworkDevice nodes
• SNMPManagedDevice and NetworkDevice nodes.

Below is the visualization of the discovered Network Topology example.

and the Infrastructure section of the discovered Network Device

Network Topology discovery with LLDP is complementary feature to the edge connectivity feature (which is discovering connections between devices and Hosts (Printers/Management Controllers)). 

Supported Discovery versions

Minimum supported Discovery version is 21.05 (12.2). 

How it works

Module Layer_2_Discovery has three patterns LLDP_Discovery_NetworkDevice, LLDP_Discovery_SNMPManagedDevice and LLDP_Discovery_StorageDevice, each triggering on appropriate node - Network Device, SNMP Managed Device or Storage Device with hidden attribute __lldp_chassis_id set.

After triggering, pattern finds all the local Network Interfaces with hidden attribute __lldp_port_id attribute set.

For each Network Interface found, pattern tries to find corresponding LLDP remote 'neighbour' interface using the LLDP related attributes:

• '__lldp_remote_sysname' or '__lldp_remote_chassis_id': to find remote 'neighbour' device;
• '__lldp_remote_port_id' or '__lldp_remote_port_desc' or 'description': to find interface on remote device;

Pattern then creates releationships 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 other like EdgeDevice (the one who is impacting).

• "without impact" or Peer-to-Peer relationship.

Pattern creates relationships mentioned above based on the following:

For Network Devices nodes:

• does local device has Hosts/Printers/ManagementControllers connected (edge clients) ? 
  If yes, then the attribute '__edge_clients_connected' set to true on the local device.
• number of LLDP neighbours for the device. This number is set as '__num_lldp_neighbours' attribute on the local device.

Given both attributes obtained for local and remote device:

• If both local and remote devices have  '__edge_clients_connected' set to true, then Peer-to-Peer relationship is created between local and remote interfaces;

  	'__edge_clients_connected' attribute value	device 'role'
  local device	True	Peer
  remote device	True	Peer

• If local device has '__edge_clients_connected' set, but the remote hasn't, then the local device is EdgeClient and the remote is EdgeDevice;

  	'__edge_clients_connected' attribute value	device 'role'
  local device	True	EdgeClient
  remote device	False	EdgeDevice

• If local device doesn't have '__edge_clients_connected' set, but remote does, then the local device is EdgeDevice and remote is EdgeClient ;

  	'__edge_clients_connected' attribute value	device 'role'
  local device	False	EdgeDevice
  remote device	True	EdgeClient

• Then, if the percentage difference between local and remote '__num_lldp_neighbours' is bigger then impact_limit (40 % by default, can be changed as it is configuration), then the device with bigger '__num_lldp_neighbours' is EdgeDevice and the one with the smaller number is EdgeClient. Otherwise, still Peer-to-Peer relationship will be created.
  
  

Some examples:

	'__num_lldp_neighbours' attribute value	percentage difference	device's 'role'
local device	10	66 %	EdgeClient
remote device	20	66 %	EdgeDevice

	'__num_lldp_neighbours' attribute value	percentage difference	device's 'role'
local device	50	18 %	Peer
remote device	60	18 %	Peer

For SNMP Managed Devices and Storage System nodes:

• 
  
  • When creating relationships it is assumed that Storage System and SNMP Managed Devices are always acting like EdgeClients.

CMDB mapping

• 
  
  • Only "with impact" relationships are synced to CMDB (EdgeClient-EdgeDevice). Peer-to-Peer relathionships are NOT synced to CMDB.
    The reason for this is that 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.
    
    

Important notes and pre-requisites

• It might required several scans of the devices to build the full topology.
• As mentioned before, Network Topology is build based on LLDP data obtained via SNMP. Hence, it is required that the discovered devices have properly configured LLDP.
• When building Network Topology, Discovery relies on edge connectivity feature discovering connections between device and edge clients like Host, Printer or Management Controllers (attribute '__edge_clients_connected' represents whether or not device has connected edge clients).  So please ensure that the edge connectivity is enabled.