Complex Network Topology Discovery using Slurp’it

Mar 6, 2024

Guest post by Flavio Esquivel
In this guest post, Flavio delves into the practical application of Slurp’it for network topology discovery. Through hands-on experimentation, he evaluates Slurp’it’s efficacy in automating the collection and processing of Command Line Interface (CLI) data using TextFSM templates.
Flavio’s conclusion: Slurp’it shines in one aspect— It does one thing, and it does it very well.
The blog post is Part 2 from a previous blog post writting by Flavio.
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                      
                dest-mac nearest-bridge
                    admin-status tx-rx
        no shutdown

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:

  1. Collect LLDP information (local system data+ remote system data)
  2. For each remote system in our Local remote systems list: Find a device whose local data matches the information on the remote system.
  3. Since in local data we have a reference to the port, if we find a match, we have a relationship between two ports.
Slurpit lldp topology

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


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.

outage simulation

So effectively, we are diagramming the network based on data collected by Slurp’it


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.

Most Read
Yes, keep me informed

Connect with us on LinkedIn to stay updated on the latest happenings, news, and exciting developments at Slurp’it. Just click the button below to follow us and be a part of our professional network.