Network topology mapping guide: building a live device map from CDP, LLDP, and MTR

You build a live network topology map by merging three data sources you already have: CDP and LLDP (IEEE 802.1AB) neighbour tables for switch and access point links, MTR path hops for the routed layer 3 path, and a LAN subnet sweep for endpoints. Unlike a hand-drawn Visio diagram, the map redraws itself each time discovery runs.

What does a live topology map actually do?

A topology map shows which devices exist and how they connect: switch to switch, switch to access point, router to router. A hand-drawn Visio diagram records that picture once. It is accurate on the day you draw it. It starts drifting the next time someone swaps a switch, re-patches a comms room or adds a desktop switch under a reception desk.

A live map uses evidence the network already produces:

• Every managed switch advertises its identity to its neighbours.
• Every router answers a traceroute probe.
• Every host on a subnet answers an ARP request.

Collect those three signals and merge them on common identifiers, and the diagram builds itself.

The difference shows up during an outage. With a stale diagram, you trace cables with a torch. With a live map, you can see that the access point on floor 4 now hangs off a switch that did not exist last month.

The three layers you are mapping

• Layer 2 adjacency. Which physical port on which switch connects to which neighbour. Source: CDP and LLDP.
• Layer 3 path. Which routers and firewalls traffic crosses to reach a destination, and where it loses packets or gains latency. Source: MTR.
• Endpoints. Which hosts are live on each subnet, with IP address, MAC address and hardware vendor. Source: a LAN subnet sweep.

No single source gives you all three. CDP and LLDP stop at one hop. MTR sees routers but not the switches between them. A subnet sweep sees hosts but not the cabling that joins them.

What do you need before you start mapping?

Five things, most of which you already have.

• Discovery protocols enabled. CDP runs by default on most Cisco IOS switches. LLDP is often disabled by default on Cisco IOS and needs enabling globally. Switch and access point ranges from Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet all document LLDP support.
• Read access to neighbour tables. That means a CLI login, SNMP read access to the LLDP MIB defined in IEEE 802.1AB, or the vendor's cloud dashboard. Read-only is enough.
• A presence on each subnet you sweep. ARP, defined in RFC 826, only works inside a broadcast domain. To sweep a remote VLAN (virtual LAN, a logically separate layer 2 segment), you need a host on it or a routed path for ICMP probes.
• Written permission. A subnet sweep can trip intrusion detection and alarm a managed service provider. Agree the scan window with your security team and the venue first.
• A list of critical destinations for MTR. Include the default gateway, the internet edge, your payment gateway, your cloud RADIUS service and any head-office data centre. RADIUS (Remote Authentication Dial-In User Service) is the protocol your network uses to authenticate logins.

If you already poll devices by SNMP and collect syslog, the read-only access model is covered in Network device management guide: SNMP, TFTP, and syslog without a full NMS.

What is the difference between CDP and LLDP for topology discovery?

Both protocols do the same job. A device sends a small layer 2 frame out of each port, announcing its name, the port it sent from and its management address. The neighbour stores that announcement in a table you can read. The differences lie in who supports them and what extra data they carry.

Attribute	CDP	LLDP
Standard	Cisco proprietary	IEEE 802.1AB open standard
Vendor coverage	Cisco devices	Multi-vendor switches, access points, phones and servers
Default advertisement interval	60 seconds	30 seconds
Default hold time	180 seconds	120 seconds (30-second interval x hold multiplier of 4)
Destination multicast MAC	01:00:0C:CC:CC:CC	01:80:C2:00:00:0E
Extra data carried	Native VLAN, VTP domain, duplex, platform, software version	Optional TLVs for system name, description, capabilities and management address
Endpoint extension	None	LLDP-MED (ANSI/TIA-1057) adds voice VLAN policy, inventory and PoE data
Best fit	All-Cisco estates	Mixed-vendor estates

TLV stands for type-length-value, the building block of an LLDP frame. LLDP has four mandatory TLVs: chassis ID, port ID, time to live and end of LLDPDU. Everything else is optional, so two vendors can both "support LLDP" and still send different detail.

The one-hop limit

Neither protocol crosses a switch. A standards-compliant bridge consumes LLDP frames rather than forwarding them. This means you need neighbour tables from every managed switch, not only the core. If you read only the core switch, you see its direct neighbours and nothing beyond.

Should you run both?

Yes, on a mixed estate. Many Cisco switches can run CDP and LLDP side by side on the same port. CDP gives you richer detail between Cisco devices. LLDP gives you the links to Juniper Mist access points, HPE Aruba switches and third-party firewalls that CDP cannot see.

How do you build the map from CDP, LLDP, MTR and a subnet sweep?

Work from the outside in: find what exists, then find how it connects, then find how traffic leaves.

Step 1: sweep the LAN subnet

Start with an ARP sweep of each local subnet. Hosts must answer ARP to communicate at all, so ARP finds devices that drop ICMP ping. Record IP address, MAC address and reverse DNS name for each responder.

Look up the first three bytes of each MAC address in the IEEE Registration Authority OUI list. That tells you the hardware vendor. A block of addresses from one switch vendor usually marks your managed infrastructure. A cluster of printer or camera vendors marks a building services VLAN that probably should not share a subnet with point-of-sale terminals.

Step 2: collect neighbour tables

For each infrastructure device found in step 1, read its CDP and LLDP neighbour tables. On Cisco IOS, the commands are:

show cdp neighbors detail
show lldp neighbors detail

Each entry gives you an edge: local device, local port, remote device, remote port. Add every edge to the map. Then read the tables on each newly discovered neighbour, and repeat until no new devices appear.

Step 3: trace the routed path with MTR

MTR combines traceroute and ping. It sends probes with increasing TTL (time to live) values and records which router returns an ICMP "time exceeded" message at each hop. It repeats this continuously, so you get loss and latency per hop rather than a single snapshot.

Run it in report mode with enough cycles to be statistically useful, for example mtr --report --report-cycles 100 followed by your target. Run it to each critical destination from your list. The hops become the layer 3 spine of your map.

Step 4: merge on shared identifiers

Three data sets now describe the same devices in different terms. Merge them using:

• Management IP address. LLDP and CDP both advertise it, and it matches your subnet sweep and MTR hops.
• Chassis ID and MAC address. LLDP chassis IDs are often a MAC address, which matches the ARP table.
• System name. Useful as a tiebreaker, but only if your naming convention is consistent.

A device that appears in all three sets is confirmed. A device that appears in one only needs investigating.

How Netforge assembles the map for you

Netforge Network Multi-Tool's topology view runs this merge as you work. Path analysis, switch discovery and LAN scans each feed the same view. The map grows as each test runs, rather than at the end of a separate mapping project. You get the topology as a by-product of the diagnostics you were running anyway.

How do you check the map is accurate?

A map you have not checked is a hypothesis. Run these five checks before you rely on it.

1. Test both directions. If switch A reports switch B on port 24, switch B should report switch A. A one-sided entry means LLDP is disabled on one end, the port filters the frames or the link is faulty in one direction.
2. Count MACs per port. A port with no LLDP neighbour but many learned MAC addresses has an unmanaged switch or hub behind it. Those are invisible to CDP and LLDP and are a common source of loops.
3. Walk one comms room. Pick a single switch and compare its physical patching with the map. If one cabinet matches, the method is sound.
4. Compare MTR runs over time. A hop count that changes between runs suggests a routing change or equal-cost multipath. Investigate before you document a single path.
5. Reconcile against your asset register. Devices on the map but not in the register are unmanaged risk. Devices in the register but absent from the map are either offline or on a segment you have not swept.

What goes wrong, and how do you fix it?

Switches are missing from the map

The usual cause is LLDP disabled on one vendor's kit. Enable it globally and on the uplink ports. If a switch is still missing, check that its management address is reachable from your discovery host. A firewall between VLANs often blocks SNMP or SSH to switch management interfaces.

MTR shows packet loss at a middle hop but not at the destination

That loss is usually not real. RFC 1812 allows routers to rate-limit the ICMP messages they generate, and many deprioritise them. Loss that starts at one hop and continues to every later hop is genuine. Loss at a single hop that clears further along is the router protecting its control plane.

The same device appears twice

A device with several management addresses, or a stacked switch reporting each member, can split into duplicates. Merge on chassis ID first, then on system name. Fix the root cause by standardising one management address per device.

Phones and laptops appear as new devices every day

Modern phones and laptops randomise their MAC address per network. These addresses set the locally administered bit, so the second character of the MAC is 2, 6, A or E. Filter them out of the infrastructure map and count them as endpoints only.

Discovery protocols leak data on guest-facing ports

CDP and LLDP advertise model, software version and management address to anything plugged into the port. On a lobby or meeting room port, that hands an attacker a ready-made target list. Disable both protocols on untrusted access ports, and keep them on uplinks and infrastructure ports. The CIS Benchmark for Cisco IOS recommends disabling CDP where you do not need it.

How does a live map compare with paid and free mappers?

Four approaches dominate. They differ less in the drawing and more in where the data comes from and whether it stays current.

Approach	Data source	Updates when the network changes	Set-up you need	Cost model	Best suited to
Hand-drawn Visio diagram	Engineer's memory and cable walks	No, only when someone redraws it	A Visio licence and site visits	Microsoft licence plus engineer hours	A single small site that rarely changes
LanTopoLog	SNMP data polled from managed switches	Yes, when you re-run discovery	A Windows host and SNMP read access on every switch	Free	A single site with full SNMP access
Commercial mapper (for example SolarWinds Network Topology Mapper or Auvik)	SNMP, CDP, LLDP and vendor APIs	Yes, on a polling schedule	A server or collector, credentials and licence management	Paid licence or subscription	Large estates with a dedicated NOC
Netforge topology view	Path analysis, switch discovery and LAN scans	Yes, every time you run a test	The Network Multi-Tool on a host connected to the network	Included in Network Multi-Tool	Engineers and MSPs diagnosing sites in person

When a free network topology mapper is enough

A free tool such as LanTopoLog works well when you control every switch and can configure SNMP across the estate. It struggles at a venue where the landlord owns the core, or where you have no SNMP credentials for the building services switches.

When a paid mapper earns its licence

A commercial mapper pays back when you need continuous monitoring, alerting and historical change records across hundreds of devices. It needs ongoing care: credentials rotate, collectors fail and polling schedules need tuning.

Where a discovery-driven live map fits

A live map built during diagnostics suits the engineer standing in a comms room with a fault to fix. It needs no prior polling infrastructure. It also captures the routed path, which a pure layer 2 mapper does not show.

Worked scenarios

The scenarios below are illustrative. They show how the method plays out in real venue types, with the measurements you would expect to take.

A 200-room hotel with intermittent guest WiFi on one floor

Situation. Guests on the fourth floor of a 200-room hotel reported dropped connections every evening. The diagram on file, drawn three years earlier, showed one access switch per floor, each uplinked to the core.

What was done. The engineer ran a LAN sweep and switch discovery from the fourth-floor comms room. LLDP showed the floor switch, but one port had 14 learned MAC addresses and no LLDP neighbour. That pointed to an unmanaged eight-port switch, added during a refurbishment to feed two extra access points. MTR to the internet edge showed clean results, ruling out the WAN.

Outcome. The unmanaged switch had created a loop with a second patch lead. Removing the duplicate lead and replacing the unmanaged unit stopped the drops. The fault was isolated in under two hours, against a full day of cable tracing on previous visits. The live map then replaced the three-year-old diagram. Hotel operators can read more in our Hotels section.

A 40-store retail estate preparing PCI DSS evidence

Situation. A retailer with 40 stores needed current network diagrams for its PCI DSS v4.0 assessment. Requirement 1.2.3 asks for an accurate diagram showing all connections between the cardholder data environment and other networks, including wireless networks. Its diagrams were templates, not records of each store.

What was done. The MSP ran discovery at each store during routine maintenance visits. CDP and LLDP mapped the store switch and access points. MTR confirmed the path from the payment VLAN to the payment gateway. The subnet sweep checked that only payment terminals sat on the payment VLAN.

Outcome. Six of the 40 stores had a building services device, such as a CCTV recorder, on the payment VLAN. The MSP moved each device to its own VLAN before the assessment. Every store left with a diagram drawn from evidence rather than a template. See how this applies across Retail estates.

A conference centre with temporary exhibition switching

Situation. A conference centre installs temporary switches for each exhibition. After a three-day event, attendees reported slow connections in one hall, and the event crew could not say what had been patched where.

What was done. The resident engineer ran switch discovery and a LAN scan on the first morning of the next event, before doors opened. LLDP revealed 12 temporary switches, two of which were daisy-chained four deep from a single uplink. MTR from the hall showed latency rising sharply at the first hop, the hall's distribution switch.

Outcome. The crew rebalanced the temporary switches across three uplinks instead of one. First-hop latency dropped to match the other halls. The centre now runs the same discovery before every event, so every build starts from an accurate picture.

What does it cost, and what do you get back?

The cost of the stale diagram

The real cost of a hand-drawn diagram is not the Visio licence. It is the engineer hours spent redrawing it after every change, and the longer outages caused when it is wrong. A diagram that misses one unmanaged switch can turn a 30-minute fix into a day of cable tracing, as the hotel scenario shows.

What a live map returns

• Faster fault isolation. You see the actual path, not the intended one.
• Compliance evidence. PCI DSS v4.0 requirement 1.2.3 asks for an accurate network diagram. A map built from discovery data is easier to defend than a drawing.
• Change detection. Comparing this month's map with last month's shows unmanaged additions, such as the switch under the reception desk.
• No new hardware. CDP, LLDP and MTR run on the switches and hosts you already own.

That last point matches how Purple works more broadly. Purple is hardware-agnostic and runs as a cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Knowing exactly what you run, and where, is the first step to adding identity-based access or analytics without a rip and replace. Venues with large, distributed estates, such as rail operators, can see this approach in our Trains section, and clinical sites in Healthcare.

Frequently asked questions

Is there a free alternative to a paid network topology mapping tool?

Yes. LanTopoLog is a free Windows tool that builds a physical topology from SNMP data polled from your managed switches. It suits a single site where you hold SNMP credentials for every switch. If you lack SNMP access, a discovery-driven approach using CDP, LLDP, MTR and a subnet sweep builds the map from what the network already advertises. Netforge Network Multi-Tool's topology view assembles that map as you run path analysis, switch discovery and LAN scans.

Do I need SNMP access to my switches to build a topology map?

No, SNMP is one route but not the only one. You can read CDP and LLDP neighbour tables through a read-only CLI login or a vendor cloud dashboard. A LAN subnet sweep needs no switch credentials, because it relies on hosts answering ARP. MTR needs only a host with a routed path to each destination. SNMP becomes useful when you want scheduled polling across hundreds of switches without logging in to each one.

Will CDP and LLDP discovery work on a mixed Cisco and non-Cisco network?

Yes, if you enable LLDP alongside CDP. CDP is Cisco proprietary, so it cannot see links to other vendors' equipment. LLDP, defined in IEEE 802.1AB, is supported by Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Many Cisco switches run both protocols side by side on the same port. On Cisco IOS, LLDP is often disabled by default, so enable it globally before you start discovery.

Does an automatic network diagram help with PCI DSS compliance?

Yes. PCI DSS v4.0 requirement 1.2.3 asks you to maintain an accurate network diagram showing all connections between the cardholder data environment and other networks, including wireless networks. A diagram built from CDP, LLDP, MTR and subnet sweep data shows the network as it actually is. It also exposes devices that sit on the payment VLAN without authorisation. Your assessor will still expect you to review the diagram and keep it current after changes.

Is it safe to leave CDP and LLDP enabled on every switch port?

No, disable them on untrusted access ports. Both protocols advertise device model, software version and management address to anything plugged into the port. On a lobby, meeting room or guest-facing port, that gives an attacker a target list. Keep CDP and LLDP enabled on uplinks, trunk ports and ports serving your own access points and phones. The CIS Benchmark for Cisco IOS recommends disabling CDP wherever you do not need it.

Can a LAN topology scanner see across firewalls and remote sites?

Only partly. CDP and LLDP stop at one hop, so you need a discovery point at each site to map its switches. ARP sweeps only work inside a broadcast domain. MTR crosses routed boundaries and shows each router hop, but firewalls that drop ICMP hide the hops behind them. For a multi-site estate, run discovery locally at each site and use MTR to map the WAN path between them.

How often should I refresh a live network map?

Refresh it after every change and at least monthly. Run discovery after any switch replacement, re-patching or refurbishment, and before any large event or busy trading period. A monthly comparison catches unmanaged additions, such as desktop switches added by contractors. Because a discovery-driven map rebuilds each time you run the tests, the refresh costs minutes rather than the hours a hand-redrawn Visio diagram demands.