Feature Request - Enable LLDP/CDP discovery and crawl discovered hosts

[sudoritz]

Feature Request - Enable LLDP/CDP discovery and crawl discovered hosts at auto add and crawl based on neighbors and new IP scopes but only scan with SNMP Community allowed or multiple . Scan the LLDP/CDP/OSPF/BGP (later or discovery)

Add the neighbor/interfaces to cabling/port matrix

[leoparente]

I will migrate this ticket to orb-agent repo to make it easier for us to track it

[udow-up]

I just want +1 for this feature. I have customers where the switches are cluttered across a /16 network. Scanning it all is not a usefull option, so CDP,LLDP would be great. Should be easy both with snmp and ios module. Great would be to be able to exclude ip networks by config, so the scan does not walk to far.

[oyabiccha]

Thanks for the discussion in #558. I am moving the request here since #558 was identified as a duplicate of this issue.

What I would like to achieve is to use CDP/LLDP neighbor information to make network connectivity in NetBox as automatic as possible.

I understand the concerns raised in #558:

• Device Discovery runs each target asynchronously and independently, so correlating information from multiple devices to create Cable objects may require additional logic, potentially on the Diode side.
• CDP/LLDP adjacency does not always represent the exact physical cabling path because passive components such as patch panels, media converters, or optical distribution frames may not be visible.

Even with those limitations, I think there is still significant value in using the information that can be discovered automatically.

For my use case, it is not essential that every passive component in the physical path be represented perfectly. Even knowing the logical adjacency between switch ports is already useful:

Device A / Interface X
        <->
Device B / Interface Y

This becomes especially valuable when combined with topology visualization tools such as netbox-topology-views.

Even if the resulting topology is approximate, being able to generate and maintain a rough network topology automatically would provide a large operational benefit.

In many environments, a topology that is mostly correct and automatically maintained is more useful than a perfectly detailed physical topology that has to be entered and maintained entirely by hand.

I therefore think it would be useful if the feature could support different levels of automation rather than requiring a single all-or-nothing behavior.

For example:

• Collect CDP/LLDP neighbor information only
• Match discovered neighbors to existing Device / Interface objects in NetBox
• Generate Cable candidates without creating them
• Provide a dry-run showing which Cable objects would be created
• Automatically create Cables only when both endpoints can be uniquely identified
• Optionally require bidirectional CDP/LLDP confirmation
• Allow users to explicitly opt in to automatic Cable creation even when passive elements may be omitted
• Avoid overwriting existing Cable data when the discovered result conflicts with what is already stored in NetBox

This would allow conservative environments to use neighbor discovery only, while environments that prioritize automation could enable more aggressive behavior.

For larger networks in particular, even if automatic discovery is not 100% accurate, automatically identifying or creating most of the topology and manually reviewing only the exceptions would still be much more practical than maintaining every connection manually.

If automatic Cable creation is too difficult as a first step, I think it would still be very useful if NetBox could at least retain and expose the discovered logical neighbor relationships so that they could be used for topology visualization and further processing.

My main goal is therefore not necessarily to guarantee a perfectly accurate physical cabling model, but to make as much use as possible of the topology information that CDP/LLDP can provide, with the level of automation being configurable by the user.

[MadsFraIP]

I also want to +1 this, especially if it can be used to create cabling between devices

[ssgadzhi]

Hi)))

We would like to help move this feature forward with captures and validation against physical multi-vendor equipment.

Test environment

We currently have access to a production-like test topology containing:

• Juniper QFX5100-48S-6Q, Junos 21.4R3-S9.5
• Multiple Juniper EX4550 switches
• MikroTik CCR2116-12G-4S+, RouterOS 7.23.5
• Eltex MES2324B

The QFX currently reports dozens of active LLDP adjacencies to Juniper, MikroTik, and Eltex devices. This gives us a useful environment for validating both ordinary links and less straightforward cases such as LAG members and multiple LLDP records received on one physical port.

Verified example

One physical link is:

QFX5100 xe-0/0/19 <-> CCR2116 sfp-sfpplus2

Junos reports two LLDP remote entries on the same local physical interface:

Local interface:    xe-0/0/19
Local port ID:      606
Remote chassis ID: d4:01:c3:e6:ea:8e
Remote system name: CCR2116_R1

First remote entry:

Remote port ID:          sfp-sfpplus2
Remote port description: sfp-sfpplus2

Second remote entry:

Remote port ID:          sfp-sfpplus2.665
Remote port description: sfp-sfpplus2.665
Remote management IPv4:  assigned to the VLAN subinterface

The two entries have the same local interface, remote chassis ID, remote system name, and physical path. RouterOS advertises both the physical interface and the VLAN subinterface over the same link.

The relevant Junos XML fields are:

<lldp-local-interface>xe-0/0/19</lldp-local-interface>
<lldp-local-port-id>606</lldp-local-port-id>
<lldp-remote-chassis-id>d4:01:c3:e6:ea:8e</lldp-remote-chassis-id>
<lldp-remote-system-name>CCR2116_R1</lldp-remote-system-name>
<lldp-remote-port-id>sfp-sfpplus2</lldp-remote-port-id>

and the additional record contains:

<lldp-local-interface>xe-0/0/19</lldp-local-interface>
<lldp-local-port-id>606</lldp-local-port-id>
<lldp-remote-chassis-id>d4:01:c3:e6:ea:8e</lldp-remote-chassis-id>
<lldp-remote-system-name>CCR2116_R1</lldp-remote-system-name>
<lldp-remote-port-id>sfp-sfpplus2.665</lldp-remote-port-id>

Expected NetBox result

Discovery should resolve this as a single physical connection:

QFX5100 xe-0/0/19 <-> CCR2116 sfp-sfpplus2

The sfp-sfpplus2.665 LLDP record must not create a second cable to the same QFX port. It may be retained as neighbor metadata or associated with the physical parent interface.

Suggested minimum scope

A useful first implementation could focus on LLDP topology import without automatically crawling every discovered neighbor:

1. Read the local interface and LLDP remote tables.
2. Resolve the local LLDP port to an existing NetBox interface.
3. Match the remote device using chassis ID, system name, or management address.
4. Match the advertised remote port to an existing remote interface.
5. Prefer a physical interface when the same chassis advertises both a physical port and one or more VLAN subinterfaces on the same local link.
6. Create a cable only when both endpoints are resolved unambiguously.
7. Log unresolved or ambiguous neighbors without creating potentially incorrect cables.

Automatic crawling of newly discovered hosts could then remain a separate optional stage.

Validation we can provide

We can help validate the implementation against physical links involving:

• Juniper ↔ Juniper
• Juniper ↔ MikroTik
• Juniper ↔ Eltex
• individual physical ports
• LAG member interfaces
• multiple LLDP records on one physical link
• neighbors with and without management addresses

We can collect sanitized LLDP-MIB walks, Junos XML output, expected endpoint mappings, and run one-off dry-run tests using develop images. The captures can also be used as regression-test fixtures.

Please let us know which exact MIB branches and output format would be most useful for the initial implementation.