Modern networks rely on multiple protocols to maintain visibility, manage topology, and troubleshoot connectivity issues. Two key protocols that help network engineers diagnose and optimize networks are LLDP (Link Layer Discovery Protocol) and STP (Spanning Tree Protocol).

LLDP is a vendor-neutral protocol used for device discovery. It helps administrators identify connected devices, their capabilities, and their network roles.
STP is a protocol used to prevent loops in a network by blocking redundant links. It also allows us to detect upstream switches, even when the link appears to be down.

By leveraging these two protocols, network engineers can map network topologies, troubleshoot misconfigurations, and prove when an ISP is at fault for connectivity issues.

What is LLDP?

LLDP (Link Layer Discovery Protocol) is an industry-standard protocol (IEEE 802.1AB) designed for network discovery. It allows network devices such as switches, routers, and servers to advertise and receive information about directly connected devices.

Why is LLDP Useful?

Network Visibility – LLDP provides an inventory of directly connected neighbors, showing device names, MAC addresses, ports, and system capabilities.
Troubleshooting Mismatches – It helps verify that devices are connected to the correct switch ports and VLANs.
Documentation & Auditing – Automates the mapping of network infrastructure, reducing reliance on outdated diagrams.
Diagnosing WAN Issues – Helps determine whether an ISP’s equipment is present at a site.

Installing LLDP on Debian

To use LLDP on Debian, we install lldpd, which runs as a background daemon.

Step 1: Install lldpd

sudo apt update
sudo apt install lldpd -y

Enable and start the service:

sudo systemctl enable --now lldpd

Check the service status to confirm it is running:

sudo systemctl status lldpd

Step 2: Query LLDP Neighbors

Once lldpd is running, use the following command to display connected network devices:

sudo lldpctl

Example output:

---------------------------------------------------
Interface:    eth0, via LLDP,  30s ago
  Chassis:
    ChassisID:    mac 00:1a:2b:3c:4d:5e
    SysName:      Core-Switch
    SysDescr:     Cisco IOS XE
  Port:
    PortID:       ifname Gi1/0/1
    PortDescr:    Uplink to Firewall
---------------------------------------------------

In this case, our Debian system is connected to a Cisco switch on eth0 via GigabitEthernet1/0/1.

Using LLDP to Troubleshoot a Network

Scenario 1: Missing LLDP Information on the WAN Interface

Let’s say we have a WAN connection on eth3, and the ISP is claiming no issues. Normally, running lldpctl should show an ISP device if LLDP is enabled.

If lldpctl shows no neighbors, it could mean:

The ISP does not use LLDP.
The link is down (ISP problem).
A cable or hardware issue is present.

In such cases, we can use STP (Spanning Tree Protocol) packets to check for an upstream device.

What is STP?

Spanning Tree Protocol (STP) is used in switches to prevent loops in Layer 2 networks. Even if LLDP is disabled, network switches still send STP packets to manage redundant paths.

How Can STP Help in Troubleshooting?

If an ISP claims there is no issue on their end, but you suspect otherwise, you can use STP packet captures to confirm whether their equipment is powered on and connected.

Capturing STP Packets on the WAN Interface

Run the following tcpdump command to capture STP packets:

sudo tcpdump -i eth3 -n -s0 -vvv 'stp'

If there is an upstream switch, you will see STP frames, such as:

08:30:25.123456 STP 802.1d, Config, Flags [none], bridge-id 8000.84:d3:43:de:93:3f

The bridge ID (MAC address) of the switch is 84:d3:43:de:93:3f.

Step 1: Identify the ISP’s Switch Vendor

Look up the MAC prefix at 👉 https://macvendors.com/

For example:

84:d3:43 belongs to Calix Inc.

This confirms that an ISP switch is connected and powered on.

Real-World Troubleshooting Example

Scenario 2: ISP Denies There’s an Issue

Imagine you report a WAN outage, and the ISP claims,

“There’s no issue on our side.”

What You Do:

Check LLDP (lldpctl) → No response.
Run STP Packet Capture (tcpdump) → You see STP packets from the ISP’s switch.
Look Up the MAC Address → Confirms the ISP’s switch is reachable.

What This Means:

If you see STP packets, then their equipment is online, and the problem is elsewhere. You can push back on their response with evidence.

Final Thoughts | The ISP’s Favourite Excuse – “No Fault Found”

Most network operators test only from their core and assume everything is fine if they don’t see an issue from their end. This is lazy troubleshooting and leads to misdiagnosed outages.

💡 Here’s the problem:

They run ICMP probes from their core → No packet loss detected.
They conclude "Your network is the problem."

🚀 What they should be doing:

Check LLDP/STP to confirm presence of their equipment.
Test traffic bidirectionally (TX and RX).
Acknowledge when the issue is between their edge and core instead of shifting blame.

Wrap

LLDP helps map networks, confirm VLANs, and detect directly connected devices.
STP packets reveal upstream ISP equipment, even when LLDP is disabled.
Using tcpdump, you can prove when an ISP’s equipment is powered but unreachable.
Network engineers should always validate ISP claims before accepting a No Fault Found excuse.

This LLDP + STP method is a powerful toolset for troubleshooting WAN links, holding ISPs accountable, and getting to the real root cause of connectivity issues. 🚀

🌉 Using LLDP & STP for Network Discovery & Troubleshooting on Debian 🏝️