# 🌉 Using LLDP & STP for Network Discovery & Troubleshooting on Debian 🏝️ 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?** 1. **Network Visibility** – LLDP provides an inventory of **directly connected neighbors**, showing device names, MAC addresses, ports, and system capabilities. 2. **Troubleshooting Mismatches** – It helps verify that devices are connected to the correct switch ports and VLANs. 3. **Documentation & Auditing** – Automates the mapping of **network infrastructure**, reducing reliance on outdated diagrams. 4. **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** ```plaintext sudo apt update sudo apt install lldpd -y ``` Enable and start the service: ```plaintext sudo systemctl enable --now lldpd ``` Check the service status to confirm it is running: ```plaintext sudo systemctl status lldpd ``` ### **Step 2: Query LLDP Neighbors** Once `lldpd` is running, use the following command to display connected network devices: ```plaintext sudo lldpctl ``` Example output: ```plaintext --------------------------------------------------- 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: 1. The ISP does not use LLDP. 2. The link is down (ISP problem). 3. 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**: ```plaintext sudo tcpdump -i eth3 -n -s0 -vvv 'stp' ``` If there is an **upstream switch**, you will see STP frames, such as: ```plaintext 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/](https://macvendors.com/) For example: ```plaintext 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:** 1. **Check LLDP (**`lldpctl`) → No response. 2. **Run STP Packet Capture (**`tcpdump`) → You see STP packets from the ISP’s switch. 3. **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. 🚀 %[https://bsky.app/profile/mastelek.bsky.social/post/3lqonlm5xhk2s]