Topology

NetXMS automatically discovers and maintains network topology information, providing Layer 2 (switching) and Layer 3 (routing) views of your infrastructure. Topology data is used for root cause analysis, network visualization, and understanding the physical and logical layout of your network.

Topology Discovery

Topology information is gathered during topology polls and routing table polls, which run periodically on all managed nodes.

Layer 2 (Data Link) Topology

Layer 2 topology describes the physical switching connections between devices. NetXMS discovers L2 topology using multiple protocols:

Protocol Description

LLDP

Link Layer Discovery Protocol. Provides the most reliable topology data including port identification and device capabilities. Supported by most modern switches and routers.

CDP

Cisco Discovery Protocol. Cisco-proprietary protocol that provides similar information to LLDP. Supported on Cisco and some third-party devices.

STP

Spanning Tree Protocol. Topology is inferred from STP port roles and designated bridge information. Works on older switches that do not support LLDP/CDP.

NDP

Nortel Discovery Protocol. Supported on legacy Nortel/Avaya switches.

FDB

Forwarding Database (MAC address table) analysis. The server correlates MAC addresses seen on different switch ports to build topology links. Used as a fallback when protocol-based discovery is not available.

The server combines information from all available sources to build a comprehensive Layer 2 topology map. Neighbor information supplied by the network device driver is collected first and may suppress collection via the standard MIB-based protocols. The standard protocols are then processed in order: LLDP, CDP, NDP, STP, then FDB. STP and FDB are used only for devices with bridge capability, and STP discovery is additionally controlled by the Topology.EnableSTPDiscovery server configuration variable (can be overridden per node with a SysConfig:Topology.EnableSTPDiscovery custom attribute). Once a connection is established for an interface, duplicate reports from later protocols are ignored.

Layer 3 (Network) Topology

Layer 3 topology describes the logical routing relationships between subnets and routers. It is built from:

  • IP routing tables — collected via SNMP or agent from all routers and Layer 3 switches

  • Interface address information — used to determine which subnets each node connects to

  • ARP tables — used to associate IP addresses with MAC addresses for L2/L3 correlation

L3 topology allows the system to determine the network path between any two nodes.

Topology Views

Node Topology Views

Topology views for a node can be opened from the node’s context menu under Topology maps:

  • Layer 2 topology — shows physical switching connections to neighboring devices

  • IP topology — shows routing topology with subnets and routers

  • Internal communication topology — shows agent and proxy connections to the management server

Each of these opens a graphical map view built from the discovered topology, centered on the selected node.

Connection Point

The Topology element on the node’s overview page shows its connection point — the switch port where the node is connected. This information is derived from the switch forwarding database (FDB) and topology discovery data, and appears after Update connection point information is triggered.

Find by MAC / IP Address

The Tools perspective provides two search views for locating devices on the network:

  • MAC Address Search — finds which switch port a given MAC address is seen on. Works even for devices not managed by NetXMS.

  • IP Address Search — finds the network location of a given IP address.

Both views show the connection point details: switch name, port, and connection type (direct or indirect).

Network Maps

Network maps provide a graphical view of topology. NetXMS can auto-generate maps based on discovered topology or administrators can build custom maps.

Auto-generated topology maps include:

  • Layer 2 topology map — shows physical switching connections

  • IP topology map — shows routing topology with subnet nodes

  • OSPF topology map — shows OSPF routing topology

  • Internal communication topology map — shows agent and proxy connections to the management server

  • Hybrid topology map — combines L2, IP, and OSPF topology in a single map

For details on creating and configuring network maps, see Network Maps.

Topology-Based Features

Root Cause Analysis

When a network device fails, NetXMS uses topology data to determine which downstream devices become unreachable as a result. This feature requires the Events.Correlation.TopologyBased server configuration variable to be enabled.

The check runs for each node during its own status poll: if the node does not respond and the network path from the server toward it is broken, the server generates the SYS_NODE_UNREACHABLE event for that node instead of SYS_NODE_DOWN, and resets the node’s interfaces and network services to Unknown status.

This significantly reduces alert noise during network outages.

Network Path Trace

The Trace path submenu (available from the right-click menu on any node) calculates and displays the network path:

  • Route from NetXMS server — L3 route from the server to the selected node

  • Route from…​ — L3 route from another node you choose to the selected node

  • Route to…​ — L3 route from the selected node to another node you choose

  • L2 path from NetXMS server — L2 path from the server to the selected node (added in 6.1)

  • L2 path from…​ — L2 path from another node you choose to the selected node (added in 6.1)

  • L2 path to…​ — L2 path from the selected node to another node you choose (added in 6.1)

Each hop is shown with the device name, interface, and IP address. The trace uses topology data from the NetXMS database, not live ICMP traceroute.

This is useful for troubleshooting connectivity issues because it works even when the target node is unreachable.

VPN Topology

Most modern VPN technologies (e.g., WireGuard, OpenVPN) create their own network interfaces, and NetXMS discovers these connections automatically during topology polls.

For interfaceless VPN tunnels (e.g., IPsec) that do not create a visible network interface, VPN Connector objects can be used to manually represent the tunnel in the topology. For example, if two firewalls are connected by an IPsec tunnel, creating a VPN Connector on each firewall, each configured with the other firewall as its peer gateway, tells NetXMS that the networks behind those firewalls are connected. The system will then include this connection in topology maps, root cause analysis, and event correlation.

To create a VPN connector:

  1. Right-click a node and select Create > VPN Connector

  2. Select the peer gateway (the node at the other end of the tunnel)

  3. Specify the local and remote networks carried by the tunnel

  4. Create a matching VPN Connector on the peer node with mirrored settings

Physical Links

Physical links track physical cabling connections between network interfaces and patch panels. Unlike topology data which is discovered automatically, physical links are created manually to document the physical infrastructure.

Physical links can be managed from the Physical Links view and support:

  • Connections between two device interfaces

  • Connections through patch panels (front and back ports)

  • Port number tracking

When Topology.AdHocRequest.IncludePhysicalLinks is set to true, physical links are included in ad-hoc L2 topology maps.

Topology Polling Configuration

Variable Default Description

Topology.PollingInterval

1800

Interval (seconds) between topology polls.

Topology.RoutingTable.UpdateInterval

300

Interval (seconds) between routing table updates.

Topology.RoutingTable.MaxSize

4000

Maximum retrievable routing table size. Larger routing tables will not be retrieved from devices.

Topology.AdHocRequest.ExpirationTime

900

Expiration time (seconds) for ad-hoc topology requests. Server will use cached result of a previous request if it is newer than this interval.

Topology.AdHocRequest.IncludePhysicalLinks

false

If set to true, physical links will be added to ad-hoc L2 maps.

Topology.DefaultDiscoveryRadius

5

Default number of hops from seed node to be added to topology map.

Topology.EnableSTPDiscovery

1

Enable (1) or disable (0) topology discovery based on STP information.

Topology and routing table polls can be disabled per node in the node’s Polling property page.

The Hook::TopologyPoll script executes after each topology poll completes, allowing custom post-processing of topology data.

Topology Data Accuracy

Topology data quality depends on:

  • SNMP access — devices must be monitored via SNMP for the server to read neighbor tables, FDB, and routing tables

  • Protocol support — LLDP provides the most accurate data; FDB-only environments may have ambiguities

  • Poll intervals — shorter intervals detect topology changes faster but increase SNMP polling load

  • Network design — complex topologies with redundant paths and link aggregation may require manual VPN connectors or custom map layouts for accurate visualization

Verifying Topology

To verify that topology is being discovered correctly:

  1. Open the node’s topology maps from the context menu (Topology maps > Layer 2 topology) to check for expected neighbors

  2. Collect the internal table metrics Topology.RoutingTable and Topology.SwitchForwardingDatabase as table DCIs to inspect raw topology data

  3. Force a topology poll: right-click the node, select Poll > Topology

  4. Check server debug log with the topology.link, topology.lldp, and topology.arp debug tags at level 6 for detailed discovery output

Common Topology Issues

Issue Resolution

Missing L2 links

Verify SNMP access to both endpoints. Check that LLDP/CDP is enabled on the switch ports. Force a topology poll on both devices.

Incorrect L2 connections

FDB-based topology can be inaccurate when switch port security or MAC filtering is active. Enable LLDP for better results.

Missing L3 paths

Verify routing table is accessible via SNMP (check SNMP community and IP-FORWARD-MIB access). Ensure routing table poll interval is sufficient.

Stale topology data

Topology data persists until the next poll updates it. Force a topology poll to refresh. Old entries are cleaned up when the polled device no longer reports them. Peer information on interfaces is retained for a configurable period even after it is no longer confirmed by polls (Objects.Interfaces.PeerRetentionTime, default: 30 days). Set Objects.Interfaces.ClearPeerOnUnmanage to true to clear peer data when an interface is unmanaged.