starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Use MAC address for LLDP status #5234

New Issue
Closed
opened 2025-12-29 19:25:43 +01:00 by adam · 9 comments
adam commented 2025-12-29 19:25:43 +01:00
Owner
Copy Link

Originally created by @BegBlev on GitHub (Aug 26, 2021).

NetBox version

v2.10.2

Feature type

Change to existing functionality

Proposed functionality

Improve the decision algorithm to decide if a "LLDP Neighbors" line should be green or not.
If, in Netbox, a device interface has a MAC adress configured on it and if Napalm returns a MAC address and if both MAC address match then the line should be green.

Use case

"LLDP Neighbors" panel is very usefull for checking connectivity between switches and routers as we can easily configure LLDP field content in network equipements. Futhermore, network devices are generally managed by the infrastructure team.
image
Regarding servers (Dell, HP...) this is not the same story. Installing an LLDP daemon is not always possible because the server can be used by an other team or because the installed software does not offer LLDP. Futhermore we generally want to check the cabling before providing the server to someone else as a cabling error could prevent the installation itself.
By using the MAC address, cable checking can be done just after racking and cabling.

Database changes

No response

External dependencies

No response

Originally created by @BegBlev on GitHub (Aug 26, 2021). ### NetBox version v2.10.2 ### Feature type Change to existing functionality ### Proposed functionality Improve the decision algorithm to decide if a "LLDP Neighbors" line should be green or not. If, in Netbox, a device interface has a MAC adress configured on it and if Napalm returns a MAC address and if both MAC address match then the line should be green. ### Use case "LLDP Neighbors" panel is very usefull for checking connectivity between switches and routers as we can easily configure LLDP field content in network equipements. Futhermore, network devices are generally managed by the infrastructure team. ![image](https://user-images.githubusercontent.com/27002365/130942771-fbf16ec4-92bf-423b-86fe-195567779866.png) Regarding servers (Dell, HP...) this is not the same story. Installing an LLDP daemon is not always possible because the server can be used by an other team or because the installed software does not offer LLDP. Futhermore we generally want to check the cabling before providing the server to someone else as a cabling error could prevent the installation itself. By using the MAC address, cable checking can be done just after racking and cabling. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:25:43 +01:00
adam closed this issue 2025-12-29 19:25:43 +01:00
adam commented 2025-12-29 19:25:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 27, 2021):

The entire premise of the LLDP neighbors tab is that it employs LLDP information to validate connections. Relying on MAC addresses would be extraneous to this function, and likely very error-prone, if even feasible. I'm sorry but this is not a change that would be appropriate to implement. Both devices on a link will need to run LLDP in order to take advantage of this feature in NetBox.

@jeremystretch commented on GitHub (Aug 27, 2021): The entire premise of the LLDP neighbors tab is that it employs LLDP information to validate connections. Relying on MAC addresses would be extraneous to this function, and likely very error-prone, if even feasible. I'm sorry but this is not a change that would be appropriate to implement. Both devices on a link will need to run LLDP in order to take advantage of this feature in NetBox.
adam commented 2025-12-29 19:25:44 +01:00
Author
Owner
Copy Link

@BegBlev commented on GitHub (Aug 27, 2021):

But this is LLDP.
In the exemple above, R640 servers from Dell send LLDP packets with their address MAC inside "port info" field.
On my switch I got:

root@qfx5120-1> show lldp neighbors interface xe-0/0/28 
LLDP Neighbor Information:
Local Information:
Index: 327 Time to live: 121 Time mark: Fri Aug 27 15:59:26 2021 Age: 3 secs 
Local Interface    : xe-0/0/28
Parent Interface   : ae28
Local Port ID      : 521
Ageout Count       : 0

Neighbour Information:
Chassis type       : Mac address
Chassis ID         : e4:43:4b:d1:b4:aa
Port type          : Mac address
Port ID            : e4:43:4b:d1:b4:aa
Organization Info
       OUI      : Ethernet Bridged (0x0080c2)
       Subtype  : (9)
       Info     : 800000000064000000000000000200000000000000 
       Index    : 1

Organization Info
       OUI      : Ethernet Bridged (0x0080c2)
       Subtype  : (11)
       Info     : 8800 
       Index    : 2

Organization Info
       OUI      : Ethernet Bridged (0x0080c2)
       Subtype  : (12)
       Info     : 00618906 
       Index    : 3

So, matching against "system name" and "port name" is not the only solution.
Matching against MAC address can be a very good solution too if this information is filled in Netbox and retrieved from LLDP.

@BegBlev commented on GitHub (Aug 27, 2021): But this is LLDP. In the exemple above, R640 servers from Dell send LLDP packets with their address MAC inside "port info" field. On my switch I got: ``` root@qfx5120-1> show lldp neighbors interface xe-0/0/28 LLDP Neighbor Information: Local Information: Index: 327 Time to live: 121 Time mark: Fri Aug 27 15:59:26 2021 Age: 3 secs Local Interface : xe-0/0/28 Parent Interface : ae28 Local Port ID : 521 Ageout Count : 0 Neighbour Information: Chassis type : Mac address Chassis ID : e4:43:4b:d1:b4:aa Port type : Mac address Port ID : e4:43:4b:d1:b4:aa Organization Info OUI : Ethernet Bridged (0x0080c2) Subtype : (9) Info : 800000000064000000000000000200000000000000 Index : 1 Organization Info OUI : Ethernet Bridged (0x0080c2) Subtype : (11) Info : 8800 Index : 2 Organization Info OUI : Ethernet Bridged (0x0080c2) Subtype : (12) Info : 00618906 Index : 3 ``` So, matching against "system name" and "port name" is not the only solution. Matching against MAC address can be a very good solution too if this information is filled in Netbox and retrieved from LLDP.
adam commented 2025-12-29 19:25:44 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (Aug 29, 2021):

I just spent the last week enabling LLDP on all of our hosts in the lab and connecting them in NetBox! Don't get me started about Intel NIC's and LLDP packets ;)

This would be a great feature for the systems that I can't beat into submission for various reasons. On another note LLDP breaks for me when I use a label in netbox since that label does not exist on the host, would be great if that could get looked at too. Cheers!

@bitcollector1 commented on GitHub (Aug 29, 2021): I just spent the last week enabling LLDP on all of our hosts in the lab and connecting them in NetBox! Don't get me started about Intel NIC's and LLDP packets ;) This would be a great feature for the systems that I can't beat into submission for various reasons. On another note LLDP breaks for me when I use a label in netbox since that label does not exist on the host, would be great if that could get looked at too. Cheers!
adam commented 2025-12-29 19:25:44 +01:00
Author
Owner
Copy Link

@BegBlev commented on GitHub (Aug 30, 2021):

On another note LLDP breaks for me when I use a label in netbox since that label does not exist on the host...

@bitcollector1 I don't really understand. Could you please elaborate a bit more?

@BegBlev commented on GitHub (Aug 30, 2021): > On another note LLDP breaks for me when I use a label in netbox since that label does not exist on the host... @bitcollector1 I don't really understand. Could you please elaborate a bit more?
adam commented 2025-12-29 19:25:45 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (Aug 30, 2021):

Sonic uses Alias for the actual port number so I wanted to use that as a label to make it easy to see what physical port was being used. I've had to use the description instead since the label interferes with LLDP. I was already using description to capture the various "lanes" configured with the breakout ports, this is why I was trying the label.

Screen Shot 2021-08-30 at 8 44 30 AM Screen Shot 2021-08-30 at 8 57 05 AM
@bitcollector1 commented on GitHub (Aug 30, 2021): Sonic uses Alias for the actual port number so I wanted to use that as a label to make it easy to see what physical port was being used. I've had to use the description instead since the label interferes with LLDP. I was already using description to capture the various "lanes" configured with the breakout ports, this is why I was trying the label. <img width="1524" alt="Screen Shot 2021-08-30 at 8 44 30 AM" src="https://user-images.githubusercontent.com/50723251/131367085-fa8503a5-b246-4bfe-9691-22b96bcdd453.png"> <img width="742" alt="Screen Shot 2021-08-30 at 8 57 05 AM" src="https://user-images.githubusercontent.com/50723251/131368275-237180a4-4447-410c-a003-815f9cddc7e8.png">
adam commented 2025-12-29 19:25:45 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (Aug 30, 2021):

FYI - Here is one of the fixes for the Intel NIC cards......only works for a few types.

sudo ethtool --set-priv-flags ens6f0 disable-fw-lldp on

As the ethtool toggle does not seems to be persistent across reboots we’ve setup following udev rule.

/etc/udev/rules.d/10-disable-fw-lldp.rules:

ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="*", DRIVERS=="i40e", PROGRAM="/usr/sbin/ethtool --set-priv-flags $name disable-fw-lldp on"

@bitcollector1 commented on GitHub (Aug 30, 2021): FYI - Here is one of the fixes for the Intel NIC cards......only works for a few types. sudo ethtool --set-priv-flags ens6f0 disable-fw-lldp on As the ethtool toggle does not seems to be persistent across reboots we’ve setup following udev rule. /etc/udev/rules.d/10-disable-fw-lldp.rules: ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="*", DRIVERS=="i40e", PROGRAM="/usr/sbin/ethtool --set-priv-flags $name disable-fw-lldp on"
adam commented 2025-12-29 19:25:45 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (Sep 9, 2021):

Today I upgraded to 3.0.2 and I was happy to see that my LLDP was playing nicer than previous versions :)

Screen Shot 2021-09-09 at 2 10 11 PM
@bitcollector1 commented on GitHub (Sep 9, 2021): Today I upgraded to 3.0.2 and I was happy to see that my LLDP was playing nicer than previous versions :) <img width="1485" alt="Screen Shot 2021-09-09 at 2 10 11 PM" src="https://user-images.githubusercontent.com/50723251/132763196-6a534222-d532-4160-a6f7-82aacce830ba.png">
adam commented 2025-12-29 19:25:45 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 16, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Nov 16, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:25:45 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 17, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Dec 17, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: needs owner type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5234
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?