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

LLDP interface data not rendering into NetBox web interface #3769

New Issue
Closed
opened 2025-12-29 18:31:08 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:31:08 +01:00
Owner
Copy Link

Originally created by @t0i on GitHub (Jun 11, 2020).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.8.5
  • napalm version: 3.0.1
  • napalm-ftos version: latest

Steps to Reproduce

  1. Have Dell OS switches, add to local_requirements.txt the napalm and napalm-ftos lines.
  2. Confirm API output is good
  3. Hit devices/lldp-tab and see it doesnt render the green or other colours and doesn't import the LLDP data that the API returns

Expected Behavior

Expect the LLDP information that is returned by the API to be put into the GUI on the table rows for each interface.

Observed Behavior

The screen goes grey while the AJAX query executes the API call, however the returned data never gets scraped into the GUI.

API output is good:

{
    "get_lldp_neighbors_detail": {
        "TenGigabitEthernet 1/1": [
            {
                "remote_chassis_id": "E4:F0:04:E9:D1:0B",
                "remote_port": "Te1/0/1",
                "remote_port_description": "Te1/0/1",
                "remote_system_name": "office3-as1",
                "remote_system_description": "",
                "remote_system_capab": [],
                "remote_system_enable_capab": [],
                "parent_interface": ""
            }
        ],
        "TenGigabitEthernet 1/2": [
            {
                "remote_chassis_id": "E4:F0:04:B9:D2:1A",
                "remote_port": "Te1/0/1",
                "remote_port_description": "Te1/0/1",
                "remote_system_name": "office3-as2",
                "remote_system_description": "",
                "remote_system_capab": [],
                "remote_system_enable_capab": [],
                "parent_interface": ""
            }
        ],
..... snip .....
"TenGigabitEthernet 1/48": [
            {
                "remote_chassis_id": "4C:D9:8F:D0:FC:60",
                "remote_port": "TenGigabitEthernet 1/26",
                "remote_port_description": "TenGigabitEthernet 1/26",
                "remote_system_name": "kel-cs1",
                "remote_system_description": "",
                "remote_system_capab": [],
                "remote_system_enable_capab": [],
                "parent_interface": ""
            }
        ],
        "FortyGigabitEthernet 1/53": [
            {
                "remote_chassis_id": "68:4F:64:15:A4:98",
                "remote_port": "fortyGigE 1/53",
                "remote_port_description": "fortyGigE 1/53",
                "remote_system_name": "keloffice3-cs2",
                "remote_system_description": "",
                "remote_system_capab": [],
                "remote_system_enable_capab": [],
                "parent_interface": ""
            }
        ],

Notice in the above that the remote_port names can either be a full length version, a semi-shortened version (fortyGigE 1/53), or a fully shortened version (Te1/0/1). This depends on what the far-side switch passes along. The napalm-ftos driver is doing minimal string manipulations. Of course it could be written to expand to the full length versions of those strings but its best if that logic is written into netbox probably.

Doing a chrome devtools debug, I'm not seeing this variable be populated, however could be my inability to do ajax debugging as thats not something i've ever done before:

// Glean configured hostnames/interfaces from the DOM
                var configured_device = row.children('td.configured_device').attr('data');

I've determined at line 60 is at fault
https://github.com/netbox-community/netbox/blob/develop/netbox/templates/dcim/device_lldp_neighbors.html#L60

because of spaces in the interfaces names.

Originally created by @t0i on GitHub (Jun 11, 2020). ### Environment * Python version: 3.6.8 * NetBox version: 2.8.5 * napalm version: 3.0.1 * napalm-ftos version: latest ### Steps to Reproduce 1. Have Dell OS switches, add to local_requirements.txt the napalm and napalm-ftos lines. 2. Confirm API output is good 3. Hit devices/lldp-tab and see it doesnt render the green or other colours and doesn't import the LLDP data that the API returns ### Expected Behavior Expect the LLDP information that is returned by the API to be put into the GUI on the table rows for each interface. ### Observed Behavior The screen goes grey while the AJAX query executes the API call, however the returned data never gets scraped into the GUI. API output is good: ``` { "get_lldp_neighbors_detail": { "TenGigabitEthernet 1/1": [ { "remote_chassis_id": "E4:F0:04:E9:D1:0B", "remote_port": "Te1/0/1", "remote_port_description": "Te1/0/1", "remote_system_name": "office3-as1", "remote_system_description": "", "remote_system_capab": [], "remote_system_enable_capab": [], "parent_interface": "" } ], "TenGigabitEthernet 1/2": [ { "remote_chassis_id": "E4:F0:04:B9:D2:1A", "remote_port": "Te1/0/1", "remote_port_description": "Te1/0/1", "remote_system_name": "office3-as2", "remote_system_description": "", "remote_system_capab": [], "remote_system_enable_capab": [], "parent_interface": "" } ], ..... snip ..... "TenGigabitEthernet 1/48": [ { "remote_chassis_id": "4C:D9:8F:D0:FC:60", "remote_port": "TenGigabitEthernet 1/26", "remote_port_description": "TenGigabitEthernet 1/26", "remote_system_name": "kel-cs1", "remote_system_description": "", "remote_system_capab": [], "remote_system_enable_capab": [], "parent_interface": "" } ], "FortyGigabitEthernet 1/53": [ { "remote_chassis_id": "68:4F:64:15:A4:98", "remote_port": "fortyGigE 1/53", "remote_port_description": "fortyGigE 1/53", "remote_system_name": "keloffice3-cs2", "remote_system_description": "", "remote_system_capab": [], "remote_system_enable_capab": [], "parent_interface": "" } ], ``` Notice in the above that the remote_port names can either be a full length version, a semi-shortened version (fortyGigE 1/53), or a fully shortened version (Te1/0/1). This depends on what the far-side switch passes along. The napalm-ftos driver is doing minimal string manipulations. Of course it could be written to expand to the full length versions of those strings but its best if that logic is written into netbox probably. Doing a chrome devtools debug, I'm not seeing this variable be populated, however could be my inability to do ajax debugging as thats not something i've ever done before: ``` // Glean configured hostnames/interfaces from the DOM var configured_device = row.children('td.configured_device').attr('data'); ``` I've determined at line 60 is at fault https://github.com/netbox-community/netbox/blob/develop/netbox/templates/dcim/device_lldp_neighbors.html#L60 because of spaces in the interfaces names.
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 18:31:08 +01:00
adam closed this issue 2025-12-29 18:31:08 +01:00
adam commented 2025-12-29 18:31:08 +01:00
Author
Owner
Copy Link

@t0i commented on GitHub (Jun 11, 2020):

image
attach an image to show my interface naming, i experimented with both longform and shortform names, with spaces and no spaces, it makes no difference.
The proper interface names are "TenGigabitEthernet 1/1" with a space between the word and the port numberings. I consider this the proper name due to thats what's pulled via SNMP.

@t0i commented on GitHub (Jun 11, 2020): ![image](https://user-images.githubusercontent.com/6345150/84330048-304d1680-ab3b-11ea-9cce-be8d1b00e3f8.png) attach an image to show my interface naming, i experimented with both longform and shortform names, with spaces and no spaces, it makes no difference. The proper interface names are "TenGigabitEthernet 1/1" with a space between the word and the port numberings. I consider this the proper name due to thats what's pulled via SNMP.
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@t0i commented on GitHub (Jun 12, 2020):

If anyone cares about the large number of changes I had to go through to get it working.

  1. Modified napalm-ftos code:
    1.1 utils/__init.py__ had a bad regex on line 30 afaict , fixed it to match *GigabitEthernet like what I assumed the author intended, this provided a fix for the inconsistent canonical_name function outputs.
    fixed line: m = re.search(r'^(.*GigabitEthernet)(\d+\/\d+)$', iface)
    1.2 napalm_ftos/ftos.py I commented out the from napalm.base.utils import py23_compat line and then modified all the functions referring to it to omit the py23_compat helper function(s).
    1.3 napalm_ftos/ftos.py added self.force_no_enable = None around line 49.
    1.4 napalm_ftos/ftos.py around line 321, removed remote_port from the for k in clause.
    1.5 napalm/base/canonical_map.py modified line 53 to show "Ma": "ManagementEthernet", . I learned later that I can import a device-specific canonical_map but haven't played with that yet. This change was necessary so Ma1/1 didn't convert to Management1/1 which doesn't match LLDP results, it needs to be ManagementEthernet 1/1.
  2. Modified netbox code:
    2.1 netbox/netbox/templates/dcim/device_lldp_neighbors.html set line 23 to: <tr id="{{ iface.name|cut:" "|cut:"nGigabitEthernet"|cut:"rtyGigE"|cut:"gabitEthernet"|lower }}"> in order to cut out any spaces, then trim TenGigabitEthernet to just Te, fortyGigE to just fo, GigabitEthernet to just Gi. Then toLowerCase the result.
    2.2 netbox/netbox/templates/dcim/device_lldp_neighbors.html made modifications to the AJAX to take in the LLDP results from the API call and convert them to shortened format (Te / Fo / Gi), then finally toLower those results to match the modifications in step 2.1. I didn't touch ManagementEthernet as that was fine from the LLDP results.
var ifacefixed = iface.split(".")[0].replace(/TenGigabitEthernet[ ]/g, "Te");
ifacefixed = ifacefixed.replace(/FortyGigabitEthernet[ ]/g, "Fo");
ifacefixed = ifacefixed.replace(/GigabitEthernet[ ]/g, "Gi");
ifacefixed = ifacefixed.replace(/fortyGigE/g, "Fo");
ifacefixed = ifacefixed.toLowerCase();
var row = $('#' + ifacefixed.replace(/([\/:])/g, "\\$1"));

I'm sure I over-complicated everything but at least I got it to work.

@t0i commented on GitHub (Jun 12, 2020): If anyone cares about the large number of changes I had to go through to get it working. 1. Modified `napalm-ftos` code: 1.1 `utils/__init.py__` had a bad regex on line 30 afaict , fixed it to match *GigabitEthernet like what I assumed the author intended, this provided a fix for the inconsistent canonical_name function outputs. fixed line: `m = re.search(r'^(.*GigabitEthernet)(\d+\/\d+)$', iface)` 1.2 `napalm_ftos/ftos.py` I commented out the `from napalm.base.utils import py23_compat` line and then modified all the functions referring to it to omit the py23_compat helper function(s). 1.3 `napalm_ftos/ftos.py` added `self.force_no_enable = None` around line 49. 1.4 `napalm_ftos/ftos.py` around line 321, removed `remote_port` from the for k in clause. 1.5 `napalm/base/canonical_map.py` modified line 53 to show `"Ma": "ManagementEthernet",` . I learned later that I can import a device-specific canonical_map but haven't played with that yet. This change was necessary so Ma1/1 didn't convert to Management1/1 which doesn't match LLDP results, it needs to be ManagementEthernet 1/1. 2. Modified netbox code: 2.1 `netbox/netbox/templates/dcim/device_lldp_neighbors.html` set line 23 to: `<tr id="{{ iface.name|cut:" "|cut:"nGigabitEthernet"|cut:"rtyGigE"|cut:"gabitEthernet"|lower }}">` in order to cut out any spaces, then trim TenGigabitEthernet to just Te, fortyGigE to just fo, GigabitEthernet to just Gi. Then toLowerCase the result. 2.2 `netbox/netbox/templates/dcim/device_lldp_neighbors.html` made modifications to the AJAX to take in the LLDP results from the API call and convert them to shortened format (Te / Fo / Gi), then finally toLower those results to match the modifications in step 2.1. I didn't touch ManagementEthernet as that was fine from the LLDP results. ``` var ifacefixed = iface.split(".")[0].replace(/TenGigabitEthernet[ ]/g, "Te"); ifacefixed = ifacefixed.replace(/FortyGigabitEthernet[ ]/g, "Fo"); ifacefixed = ifacefixed.replace(/GigabitEthernet[ ]/g, "Gi"); ifacefixed = ifacefixed.replace(/fortyGigE/g, "Fo"); ifacefixed = ifacefixed.toLowerCase(); var row = $('#' + ifacefixed.replace(/([\/:])/g, "\\$1")); ``` I'm sure I over-complicated everything but at least I got it to work.
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 15, 2020):

Seems like the root issue is that the device is returning interface names with whitespace in them. Probably just need to strip/replace whitespace in the interface name when assigning and referencing the table row in the DOM.

@jeremystretch commented on GitHub (Jun 15, 2020): Seems like the root issue is that the device is returning interface names with whitespace in them. Probably just need to strip/replace whitespace in the interface name when assigning and referencing the table row in the DOM.
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 15, 2020):

Instead of stripping whitespace, could we do something like:

var row = $('[data-name='+ iface.split(".")[0].replace(/([\/:])/g, "\\$1")+']');

Store the interface name in a data-name="" attribute, then move to using the PK for the #id? This would allow us to maintain the name. A whitespace is an invalid value in the id field however, so we should fix that.

@DanSheps commented on GitHub (Jun 15, 2020): Instead of stripping whitespace, could we do something like: ``` var row = $('[data-name='+ iface.split(".")[0].replace(/([\/:])/g, "\\$1")+']'); ``` Store the interface name in a `data-name=""` attribute, then move to using the PK for the #id? This would allow us to maintain the name. A whitespace is an invalid value in the id field however, so we should fix that.
adam commented 2025-12-29 18:31:09 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jun 30, 2020):

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.

@stale[bot] commented on GitHub (Jun 30, 2020): 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 18:31:09 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jul 7, 2020):

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.

@stale[bot] commented on GitHub (Jul 7, 2020): 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: bug
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#3769
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?