How Network Topology Is Built Automatically Using SNMP, LLDP and CDP.

A network diagram is easy to draw but keeping that diagram accurate while the network is constantly changing is a completely different problem. In a modern enterprise, switches are added, uplinks are moved, interfaces are reconfigured, firewalls are replaced, servers migrate, and network segments are redesigned. A topology diagram maintained manually can become outdated almost as soon as it is created.

This is why a modern Network Management System, or NMS, should treat topology as discovered infrastructure data rather than simply as a manually maintained diagram.

But how does an NMS actually determine that ‘Core-SW port Gi1/0/1’ is connected to ‘Dist-SW port Gi1/0/48’ or it represents a real network connection?

The answer is not simply “SNMP”. A topology engine typically combines information collected through SNMP, LLDP, CDP, interface data, bridge information, IP information, and device identity data. It then normalizes and correlates those observations to construct relationships between devices. The result is not just a picture.It is a continuously updated model of how the network is connected.

Why Network Topology Matters?

Imagine an enterprise network containing hundreds of switches, routers, firewalls, servers, wireless access points, printers, and other infrastructure devices. Knowing that those devices exist is useful but knowing how they are connected is much more valuable. Suppose an access switch suddenly becomes unreachable then a conventional monitoring system might produce a simple alarm: Access-SW: DOWN. But an engineer immediately needs more context.

  • Which device is upstream?
  • Which interface connects to it?
  • Is another device failing at the same time?
  • Which downstream systems depend on it?
  • Did the network topology recently change?
  • Is this an isolated failure or part of a larger outage?

Instead of showing only: Access-SW: DOWN, an NMS can provide a topology relationship showing how the devices are interconnected.The NMS can begin to understand not only what failed, but where that failure sits within the network.

This makes topology useful for many things like network troubleshooting, RCA, impact analysis, capacity planning and security visibility etc. The challenge faced here is determining how that topology can be discovered automatically and kept accurate over time.

What Does Network Topology Actually Mean?

It is important to define what an NMS is actually trying to discover. At the simplest level: ‘Topology describes the relationships between network entities.‘

There are several different types of topology:

Physical topology: Physical topology describes actual connectivity between physical interfaces. Core-SW Gi1/0/1 → Dist-SW Gi1/0/48. This tells us that a particular interface on Core-SW is connected to a particular interface on Dist-SW which is much more useful operationally than simply knowing Core-SW → Dist-SW because an engineer troubleshooting the link needs to know exactly which ports are involved.

Layer 2 topology: Layer 2 topology concerns switching relationships. It can involve around Ethernet Ports, Bridge ports, VLAN’s, MAC address Forwarding etc. Switch-A → VLAN 100 → Switch-B does not simply describe a cable. It describes how Layer 2 traffic is carried through the network. Physical connectivity and Layer 2 forwarding are related, but they are not necessarily identical concepts.

Layer 3 topology: Layer 3 topology describes IP-level relationships and may also contain IP interfaces, Subnets, Routing relationships, Virtual Interfaces, Tunnels etc. For Example Router-A → 10.10.10.0/30 → Router-B

Therefore, when an NMS says that it has “discovered topology,” the statement is straightforward Device A → Interface A → Relationship → Interface B → Device B. The topology engine’s job is to discover and maintain those relationships.

What’s actually behind the topology engine?

SNMP: The Management Data Foundation- One of the most common misconceptions about topology discovery is SNMP discovers the topology. SNMP provides access to management information. The information itself comes from standardized MIBs and vendor-specific management objects. The Interfaces MIB, for example, provides objects such as ifIndex, ifDescr, ifName, ifAdminStatus, and ifOperStatus. An NMS can therefore build an interface inventory such a the following

Device: Core-SW

ifIndex    ifName       Status
101        Gi1/0/1      up
102        Gi1/0/2      up
103        Gi1/0/3      down
104        Gi1/0/4      up

This information is fundamental because topology relationships ultimately need to be associated with interfaces, not just devices. Without a reliable interface inventory, neighbor information becomes much harder to attach to the correct port.

Link Layer Discovery Protocol, or LLDP, is a standardized Layer 2 neighbor-discovery protocol. Unlike SNMP, LLDP is specifically designed for neighboring devices to advertise information about themselves. Depending on the implementation and enabled TLVs, LLDP can provide information such as Port ID, System name, Chassis ID, Management address etc.

Consider two switches Core-SW Gi1/0/1 → Dist-SW Gi1/0/48. Core-SW can learn information about Dist-SW through LLDP, while Dist-SW can similarly learn information about Core-SW. The NMS can retrieve the learned LLDP information through the device’s management interface, commonly through SNMP-accessible LLDP MIB objects.

It may receive information conceptually similar to:

Local Device:       Core-SW
Local Interface:    Gi1/0/1

Remote Chassis ID:  AA:BB:CC:DD:EE:01
Remote Port ID:     Gi1/0/48
Remote System Name: Dist-SW

The NMS now has evidence that Core-SW Gi1/0/1 → Dist-SW Gi1/0/48. However, it is still important to understand that the raw LLDP record is not necessarily the final topology edge.

The NMS still has to determine:

  • Which device does that chassis ID represent?
  • Does that device already exist in inventory?
  • Which interface object corresponds to Gi1/0/48?
  • Is the observation current?
  • Does the remote device report the same relationship?
  • Is the interface operationally up?

That correlation process is where the topology engine becomes important.

Cisco Discovery Protocol(Similar Purpose, Different Scope) serves a similar purpose to LLDP, but it is a Cisco proprietary neighbor-discovery protocol. CDP can provide information such as device ID, Local interface, Platform, Management address etc.

In a multi-vendor network, LLDP is particularly important whereas in a Cisco-heavy environment, CDP can provide additional information. A capable NMS like ArkayNMS can support both and use the available information rather than assuming that one protocol will exist everywhere.

How the NMS Actually Builds the Topology?

This is the technical core of automated topology discovery. The topology engine takes distributed observations from the network and turns them into a consistent graph.

Step 1: Discover the Devices

Before topology can be constructed, the NMS needs to know which devices exist. Devices may enter the NMS through:

  • Manual configuration
  • IP discovery
  • SNMP discovery
  • Network scanning
  • Existing inventory
  • External integrations

Suppose the NMS discovers:

10.10.1.10 → Core-SW
10.10.1.20 → Dist-SW
10.10.1.30 → Access-SW
10.10.1.40 → Firewall

At this stage, the NMS has identified nodes. But it does not necessarily know the relationships between them. It knows that devices exist but still doesn’t know which devices are actually connected.

Step 2: Build the Interface Inventory

The NMS then collects interface-related information. For Core-SW, it may discover:

ifIndex    ifName       Operational State
101        Gi1/0/1      up
102        Gi1/0/2      up
103        Gi1/0/3      down
104        Gi1/0/4      up

Internally, the NMS may represent each interface with attributes such as:

Interface
 ├── Device ID
 ├── ifIndex
 ├── ifName
 ├── ifDescr
 ├── ifAlias
 ├── Administrative State
 ├── Operational State
 └── Interface Type

This becomes important because the topology should not simply say Core-SW → Dist-SW, rather It should ideally identify the actual connection Core-SW Gi1/0/1 → Dist-SW Gi1/0/48

Step 3: Collect LLDP and CDP Information

The NMS now retrieves neighbor information.Suppose Core-SW reports:

Local Port:       Gi1/0/1
Remote Chassis:   AA:BB:CC:DD:EE:01
Remote Port:      Gi1/0/48
Remote System:    Dist-SW

The topology engine now has an observation. That distinction matters as the record is evidence that:

Core-SW Gi1/0/1 → a device identified as Dist-SW → port Gi1/0/48 But the topology engine still needs to resolve that observation against its inventory. It needs to determine whether Dist-SW already exists as a known device and whether Gi1/0/48 corresponds to a known interface object.

Step 4: Resolve Device Identity

Identity resolution is one of the most important parts of topology discovery. A single physical device can have many identifiers such as

Management IP:   10.10.1.20
Hostname:        dist-sw.example.com
System Name:     DIST-SW
Chassis ID:      AA:BB:CC:DD:EE:01
MAC Address:     AA:BB:CC:DD:EE:01

If the NMS treats every identifier as a separate device, one physical switch could incorrectly appear multiple times. Instead, the topology engine needs a canonical device identity. Potential identity evidence can include any one of the above and once the device is resolved, the LLDP or CDP observation can be associated with the correct inventory object.

Step 5: Resolve the Remote Interface

The same problem exists for interfaces.

Suppose LLDP reports:

Remote Port ID: Gi1/0/48

The topology engine needs to determine which interface object belongs to that port. The NMS may already have:

Device ID: 4821
ifIndex:   148
ifName:    Gi1/0/48

The observation can therefore be resolved to: Dist-SW → interface index 148 → Gi1/0/48

The original observation Core-SW Gi1/0/1 → remote port Gi1/0/48 can now become: Core-SW interface 101 → Dist-SW interface 148. “That is a topology ready relationship”

Step 6: Correlate Local and Remote Observations

Now imagine the NMS polls Dist-SW and it reports:

Local Device:      Dist-SW
Local Port:        Gi1/0/48

Remote Device:     Core-SW
Remote Port:       Gi1/0/1

The topology engine now has two observations.

Observation A: Core-SW Gi1/0/1 → Dist-SW Gi1/0/48

Observation B: Dist-SW Gi1/0/48 → Core-SW Gi1/0/1

These observations corroborate one another. The NMS can consolidate them into a single relationship as Core-SW Gi1/0/1 ↔ Dist-SW Gi1/0/48

The important architectural concept is this:

“The topology graph represents the relationship, while the collected observations provide the evidence behind that relationship. The separation is important because observations can change while the underlying device identity and topology model remain stable”

Step 7 — Validate the Relationship

Real networks are not perfectly clean. Suppose Core-SW reports: Core-SW Gi1/0/1 → Dist-SW Gi1/0/48 but Dist-SW does not report Core-SW. Now what to do? Should the NMS immediately remove the relationship? The answer is not necessarily.

There are several possible explanations:

  • LLDP is disabled on one side
  • Polling occurred at different times
  • One device has stale information
  • The vendor implementation behaves differently
  • SNMP collection failed on one device
  • The remote device is temporarily unreachable

A mature NMS should therefore treat topology as observed data with evidence, timestamps, and state rather than unquestionable truth.

For example:

Relationship:
Core-SW Gi1/0/1 ↔ Dist-SW Gi1/0/48

Evidence:
✓ LLDP reported by Core-SW
✓ LLDP reported by Dist-SW
✓ Local interface is up
✓ Remote port matches

This is strong evidence.

Another relationship might look like:

Relationship:
Core-SW Gi1/0/1 → Dist-SW Gi1/0/48

Evidence:
✓ LLDP reported by Core-SW
✗ No reverse LLDP observation
✓ Local interface is up
? Remote interface state unavailable

The relationship may still be displayed, but the NMS can internally treat it as partial or lower-confidence evidence. This is much more realistic than assuming that every topology record is automatically correct.

Step 8: Use Additional Data Sources

LLDP and CDP are extremely useful, but they are not the only sources of topology evidence. A topology engine can also use

  • INTERFACE STATE: If an interface is administratively disabled or operationally down, the NMS should consider that when interpreting the relationship.
  • BRIDGE MIB information can help associate interfaces with Layer 2 forwarding structures.
  • MAC FORWARDING INFORMATION: MAC address tables can provide additional Layer 2 evidence about where devices or other switches are being learned.
  • IP INFORMATION: IP addresses, interfaces, and subnet information can help the NMS understand Layer 3 relationships.
  • DEVICE INVENTORY: Serial numbers, chassis identifiers, platform information, and other inventory data can strengthen device identity resolution.
Step 9: Create the Topology Edge

Once device identity and interface identity have been resolved, the NMS can create a topology edge.

Source Device:       Core-SW
Source Interface:    Gi1/0/1

Destination Device:  Dist-SW
Destination Interface: Gi1/0/48

The resulting relationship is: Core-SW Gi1/0/1 → Dist-SW Gi1/0/48. It can further have the info about the device attributes in them.

Example:
Consider a small enterprise network containing: Internet → Firewall → Core-SW. The core switch connects to: Core-SW → Dist-SW and Core-SW → Server-01The distribution switch connects to: Dist-SW → Access-SW

The resulting topology might be represented as:

Internet
   ↓
Firewall
   ↓
Core-SW
   ├──→ Dist-SW
   │       └──→ Access-SW
   │
   └──→ Server-01

The user sees a network diagram.

Underneath that diagram, the NMS maintains:

Devices
Interfaces
Observations
Relationships
Evidence
Timestamps
States

That underlying model is what makes automated topology possible.

What Happens When the Network Changes?

This is where automated topology becomes significantly more valuable than a static diagram. The topology engine should detect the changes such as changed link and replaces the old relationship with the newly discovered one. Topology should be treated as a time-varying state, not a static drawing.

The NMS needs mechanisms for:

  • Refreshing observations
  • Aging stale information
  • Detecting disappeared neighbors
  • Handling device outages
  • Detecting newly connected devices
  • Detecting changed interfaces
  • Updating relationships
  • Preserving historical information where required

A topology system that can discover new connections but cannot remove stale ones will eventually become inaccurate.

The Complication of Link Aggregation

When two network devices are connected through multiple physical links, those links can be combined into a single logical connection such as a LAG or port-channel. The NMS should understand both levels: the logical connection and the physical interfaces that make it up.

This is important because if one physical link fails, the logical connection may still remain operational through the other links. Therefore, an interface-down event does not necessarily mean that the overall topology relationship is down.

Bringing Topology Into the Monitoring Architecture

Topology becomes much more valuable when it is connected to the rest of the monitoring architecture.

A modern NMS such as ArkayNMS can combine SNMP data such as CPU, memory, interface utilization, errors, discards, temperature, and overall device health with SNMP Traps for link events, hardware alarms, and threshold notifications. Syslog adds context through interface events, configuration changes, authentication, security, and system messages, while NetFlow and IPFIX provide visibility into traffic relationships, top talkers, bandwidth consumption, and application visibility. ICMP helps determine reachability, latency, and packet loss, while Topology ties everything together by showing infrastructure relationships, upstream and downstream dependencies, and interface-to-interface connectivity.

Each source answers a different question.

  • SNMP: How healthy is the device?
  • Syslog: What events did the device report?
  • NetFlow and IPFIX: What traffic is moving through the network?
  • ICMP: Is the device reachable?
  • Topology: How is the device connected to everything else?

When these datasets are combined, the NMS gains much richer operational context which enables more meaningful:

  • Alarm correlation
  • Root-cause analysis
  • Impact analysis
  • Dependency mapping
  • Incident investigation

Topology provides the structure. Telemetry provides the health. Events provide the context and together, they provide a much clearer operational picture.

Leave a Reply

Your email address will not be published. Required fields are marked *