If you didn’t read Part 1, you can find it here.
A more complex case
Slurp’it’s LLDP model is quite basic and collects very little information. This makes sense when we have equipment that actually implements LLDP in a very basic way, but what happens when we have more complex configurations?
So far, our LLDP configuration has been pretty straightforward, and as we mentioned earlier, we have adapted our network for this plotter to work. However, would you change the configuration of your actual production network to accommodate an external tool? Maybe not.
For example, this is a typical LLDP configuration.
A:PE1>config>port# info
----------------------------------------------
ethernet
lldp
dest-mac nearest-bridge
admin-status tx-rx
exit
exit
exit
no shutdown
----------------------------------------------
A:PE1>config>port#
on the remote side this looks like:
*A:PE2>config>port# show system lldp neighbor Link Layer Discovery Protocol (LLDP) System Information =============================================================================== NB = nearest-bridge NTPMR = nearest-non-tpmr NC = nearest-customer =============================================================================== Lcl Port Scope Remote Chassis ID Index Remote Port Remote Sys Name ------------------------------------------------------------------------------- 1/1/c2/1 NB FC:14:FF:00:00:00 4 1610899585 n/a =============================================================================== Number of neighbors : 1
Note that we currently lack access to the name of the remote system and the name of the remote port.
Our basic template will not suffice, and our plotter will lack the essential information needed to diagram the network.
Therefore, if our network does not conform to Slurp’it, we must adapt Slurp’it to our network.
We can refine our strategy based on the LLDP standard. A straightforward and direct approach:
- Collect LLDP information (local system data+ remote system data)
- For each remote system in our Local remote systems list: Find a device whose local data matches the information on the remote system.
- Since in local data we have a reference to the port, if we find a match, we have a relationship between two ports.
1. Collecting Local LLDP information
We will use the following commands:
- show system lldp: from here we will get chassis-id-subtype, chassis-id and system-name
*A:PE2# show system lldp =============================================================================== ... ------------------------------------------------------------------------------- LLDP System Information ------------------------------------------------------------------------------- Chassis Id Subtype : 4 Chassis Id : fc:1e:ff:00:00:00 System Name : PE2 ...
- show port 1/1/c2/1 ethernet lldp: from here we will get dest-mac, and port-id-subtype
*A:PE2# show port 1/1/c2/1 ethernet lldp ============================================================================== Link Layer Discovery Protocol (LLDP) Port Information ============================================================================== Port 1/1/c2/1 Bridge nearest-bridge ------------------------------------------------------------------------------- Admin State : txAndRx Notifications : Disabled Tunnel Nearest Bridge : Disabled Transmit TLVs : sysName PortID TLV Subtype : tx-if-name Management Address Transmit Configuration: ... Port 1/1/c2/1 Bridge nearest-non-tpmr ------------------------------------------------------------------------------- Admin State : disabled Notifications : Disabled Transmit TLVs : None PortID TLV Subtype : tx-local Management Address Transmit Configuration: ...
Nokia does not specify the value of the port-id that will is announced to the neighbor. However, utilizing the port-id-subtype parsed earlier, this value can be calculated by extracting information from the show port detail command. Therefore, we will parse the description, interface, and ifIndex. Depending on the value of the port-id-subtype, the port-id will be derived from one of these values.
===============================================================================
Ethernet Interface
===============================================================================
Description : 10-Gig Ethernet
Interface : 1/1/c2/1 Oper Speed : 10 Gbps
FP Number : 1 MAC Chip Number : 1
Link-level : Ethernet Config Speed : N/A
Admin State : up Oper Duplex : full
Oper State : up
Config Duplex : N/A
Physical Link : Yes MTU : 9212
Single Fiber Mode : No Min Frame Length : 64 Bytes
IfIndex : 1610899585 Hold time up : 0 seconds
Last State Change : 02/15/2024 17:43:49 Hold time down : 0 seconds
Hold Time Down Rmng: 0 cs Hold Time Up Rmng: 0 cs
Last Cleared Time : N/A
Phys State Chng Cnt: 1
RS-FEC Config Mode : None
RS-FEC Oper Mode : None 2. Collecting Local LLDP remote-systems information
We will use the command show port 1/1/c2/1 ethernet lldp remote-info
and extract the chassis-id, chassis-id-subtype, port-id, and port-id-subtype.
*A:PE2# show port 1/1/c2/1 ethernet lldp remote-info ============================================================================== Link Layer Discovery Protocol (LLDP) Port Information ============================================================================== Port 1/1/c2/1 Bridge nearest-bridge Remote Peer Information ------------------------------------------------------------------------------- Remote Peer Index 4 at timestamp 02/15/2024 20:43:32: Supported Caps : (Not Specified) Enabled Caps : (Not Specified) Chassis Id Subtype : 4 (macAddress) Chassis Id : FC:14:FF:00:00:00 PortId Subtype : 7 (local) Port Id : 1610899585 Port Description : n/a System Name : n/a System Description : n/a Age : 6844 seconds Port 1/1/c2/1 Bridge nearest-non-tpmr Remote Peer Information ------------------------------------------------------------------------------- No remote peers found Port 1/1/c2/1 Bridge nearest-customer Remote Peer Information ------------------------------------------------------------------------------- No remote peers found ============================================================================== *A:PE2
Now, we write the templates, test them, add them to a plan, and we are ready to collect all the necessary LLDP information.
After making adaptations to our algorithm and expanding our plotter, we have something like:
Collecting more LLDP data
Slurp’it has turned out to be flexible enough to allow me to define my templates and store the information in my own way.
He is in charge of parsing according to the information and providing me with the data in batches, plans, etc.
Let’s add more devices to our mix:
I have marked with dotted lines links that have been discovered in the nearest-customer mac-destination address, this can serve as an indication that this link is really through a pseudowire and that the device CE1 is not connected to CE2 but to PE1 which is the closest.
Now, let’s activate LLDP between CEs and PEs:
It seems to work, now let’s try to simulate an outage between PE1 and PE2 this should interrupt the CE1-CE2 connection as well.
So effectively, we are diagramming the network based on data collected by Slurp’it
Conclusion
The realm of automation tools resembles a dense jungle, where identifying the precise role of each tool can be challenging. Many off-the-shelf solutions boast broad feature sets, yet falter when confronted with complex scenarios. Adapting your existing network to such tools isn’t always feasible, and requesting new features can be frustrating, if not impossible, depending on the tool’s architecture.
Exploring Slurp’it through this PoC has been enlightening. I’ve tested its adaptability, and exposing the gathered data via an API reveals significant potential.
However, this adaptability comes with a drawback: certain workflows may prove more intricate to implement. For instance, repeatedly collecting all LLDP information from scratch during each refresh might not be practical. Instead, focusing on processing only the changes and executing subsequent commands based on that data could be more efficient. This added complexity now requires management at the client side.
Nonetheless, Slurp’it shines in one aspect— It does one thing, and it does it very well.
