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

Napalm broken since 2.8.9-ldap or before #4203

New Issue
Closed
opened 2025-12-29 18:33:50 +01:00 by adam · 3 comments
adam commented 2025-12-29 18:33:50 +01:00
Owner
Copy Link

Originally created by @guillaume-harvey on GitHub (Oct 20, 2020).

Environment

  • Python version: 3.7.9
  • NetBox version: 2.9.7

Steps to Reproduce

  1. Make sure you have access to a physical switch for testing
  2. Open firewall between netbox server and physical switch
  3. Make sure you can access the physical switch from you netbox server using SSH (note user/password)
  4. Create a Organization>Sites Ex: {name: WNPGMB01, slug: wnpgmb01, status: active, dc type: local, site id: 12}
  5. Create a Devices>Manufacturers Ex: {name: Juniper, slug: juniper}
  6. Create a Devices>Platforms Ex: {name: JunOS 14.1X53-D42.3, slug: junos-14-1x53-d42-3, manufacturer: Juniper, NAPALM driver: junos, NAPALM arguments: {"NAPALM_TIMEOUT": "60", "NAPALM_PASSWORD": "a_fake_password", "NAPALM_USERNAME": "the_user"} }
  7. Create a Devices>Device roles Ex: {name: netinfra-mtw, slug: netinfra-mtw, color: Blue }
  8. Create a Devices>Device types Ex: {manufactuer: Juniper, model: EX4300-48T-AFI DC, slug: ex4300-48t-afi-dc, height: 1}
  9. Create a IPAM>IP addresses Ex: {address: 10.65.41.30/24, status: active}
  10. Create a Devices>Devices Ex: {name: mtw29-winnipeg01, device role: netinfra-mtw, manufacturer: Juniper, device type: EX4300-48T-AFI DC, sites: WNPGMB01}
  11. Find the new device in Devices>Devices
  12. Add previously created IP address to primary IP for the device
  13. Navigate inside the LLDP Neighbors tabs

Expected Behavior

The page should display the LLDP Neigbors like this:

{
        "ge-0/0/47": [
            {
                "parent_interface": "-",
                "remote_port": "MgmtEth0/RP0/CPU0/0",
                "remote_chassis_id": "9C:E1:76:70:18:D9",
                "remote_port_description": "",
                "remote_system_name": "tor-29.wnpgmb01",
                "remote_system_description": "6.6.3, NCS-5500",
                "remote_system_capab": [
                    "router"
                ],
                "remote_system_enable_capab": [
                    "router"
                ]
            }
        ],
        "xe-0/2/0": [
            {
                "parent_interface": "ae0",
                "remote_port": "xe-0/0/21",
                "remote_chassis_id": "CC:E1:94:CA:7E:E0",
                "remote_port_description": "mtw29-winnipeg01  xe-0/2/0 Mgmt",
                "remote_system_name": "mtw0-0-winnipeg01",
                "remote_system_description": "Juniper Networks, Inc. qfx5100-48s-6q Ethernet Switch, kernel JUNOS 14.1X53-D42.3, Build date: 2017-02-14 20:10:57 UTC Copyright (c) 1996-2017 Juniper Networks, Inc.",
                "remote_system_capab": [
                    "bridge",
                    "router"
                ],
                "remote_system_enable_capab": [
                    "bridge",
                    "router"
                ]
            }
        ],
        "xe-0/2/1": [
            {
                "parent_interface": "ae0",
                "remote_port": "xe-1/0/21",
                "remote_chassis_id": "CC:E1:94:CA:7E:E0",
                "remote_port_description": "mtw29-winnipeg01  xe-0/2/1 Mgmt",
                "remote_system_name": "mtw0-0-winnipeg01",
                "remote_system_description": "Juniper Networks, Inc. qfx5100-48s-6q Ethernet Switch, kernel JUNOS 14.1X53-D42.3, Build date: 2017-02-14 20:10:57 UTC Copyright (c) 1996-2017 Juniper Networks, Inc.",
                "remote_system_capab": [
                    "bridge",
                    "router"
                ],
                "remote_system_enable_capab": [
                    "bridge",
                    "router"
                ]
            }
        ]
    }
}

Observed Behavior

We are getting a {"detail":"Error connecting to the device at 10.65.41.30: ConnectAuthError(10.65.41.30)"}

More information

After some debugging, we checked the ssh logs from the switch we are trying to get Neighbors from:

When trying directly from netbox GUI we get a null or blank user while SSH:
RP/0/RP0/CPU0:Oct 19 20:12:46.388 EDT: SSHD_[68735]: %SECURITY-SSHD-3-ERR_GENERAL : User name in USERAUTH_REQUEST is null or blank

When trying using netbox napalm CLI or API it is working:

RP/0/RP0/CPU0:Oct 19 20:13:59.483 EDT: SSHD_[68821]: %SECURITY-SSHD-6-INFO_SUCCESS : Successfully authenticated user 'netbox' from '10.55.18.209' on 'vty1'(cipher 'aes128-ctr', mac 'hmac-sha2-256')

It seems that Napalm from the GUI is not using the NAPALM_USERNAME and NAPALM_PASSWORD provided by the Devices>Platforms we previously created.

Originally created by @guillaume-harvey on GitHub (Oct 20, 2020). ### Environment * Python version: 3.7.9 * NetBox version: 2.9.7 ### Steps to Reproduce 1. Make sure you have access to a physical switch for testing 2. Open firewall between netbox server and physical switch 3. Make sure you can access the physical switch from you netbox server using SSH (note user/password) 4. Create a Organization>Sites Ex: {name: WNPGMB01, slug: wnpgmb01, status: active, dc type: local, site id: 12} 5. Create a Devices>Manufacturers Ex: {name: Juniper, slug: juniper} 6. Create a Devices>Platforms Ex: {name: JunOS 14.1X53-D42.3, slug: junos-14-1x53-d42-3, manufacturer: Juniper, NAPALM driver: junos, NAPALM arguments: {"NAPALM_TIMEOUT": "60", "NAPALM_PASSWORD": "a_fake_password", "NAPALM_USERNAME": "the_user"} } 7. Create a Devices>Device roles Ex: {name: netinfra-mtw, slug: netinfra-mtw, color: Blue } 8. Create a Devices>Device types Ex: {manufactuer: Juniper, model: EX4300-48T-AFI DC, slug: ex4300-48t-afi-dc, height: 1} 9. Create a IPAM>IP addresses Ex: {address: 10.65.41.30/24, status: active} 10. Create a Devices>Devices Ex: {name: mtw29-winnipeg01, device role: netinfra-mtw, manufacturer: Juniper, device type: EX4300-48T-AFI DC, sites: WNPGMB01} 12. Find the new device in Devices>Devices 13. Add previously created IP address to primary IP for the device 13. Navigate inside the LLDP Neighbors tabs ### Expected Behavior The page should display the LLDP Neigbors like this: ``` { "ge-0/0/47": [ { "parent_interface": "-", "remote_port": "MgmtEth0/RP0/CPU0/0", "remote_chassis_id": "9C:E1:76:70:18:D9", "remote_port_description": "", "remote_system_name": "tor-29.wnpgmb01", "remote_system_description": "6.6.3, NCS-5500", "remote_system_capab": [ "router" ], "remote_system_enable_capab": [ "router" ] } ], "xe-0/2/0": [ { "parent_interface": "ae0", "remote_port": "xe-0/0/21", "remote_chassis_id": "CC:E1:94:CA:7E:E0", "remote_port_description": "mtw29-winnipeg01 xe-0/2/0 Mgmt", "remote_system_name": "mtw0-0-winnipeg01", "remote_system_description": "Juniper Networks, Inc. qfx5100-48s-6q Ethernet Switch, kernel JUNOS 14.1X53-D42.3, Build date: 2017-02-14 20:10:57 UTC Copyright (c) 1996-2017 Juniper Networks, Inc.", "remote_system_capab": [ "bridge", "router" ], "remote_system_enable_capab": [ "bridge", "router" ] } ], "xe-0/2/1": [ { "parent_interface": "ae0", "remote_port": "xe-1/0/21", "remote_chassis_id": "CC:E1:94:CA:7E:E0", "remote_port_description": "mtw29-winnipeg01 xe-0/2/1 Mgmt", "remote_system_name": "mtw0-0-winnipeg01", "remote_system_description": "Juniper Networks, Inc. qfx5100-48s-6q Ethernet Switch, kernel JUNOS 14.1X53-D42.3, Build date: 2017-02-14 20:10:57 UTC Copyright (c) 1996-2017 Juniper Networks, Inc.", "remote_system_capab": [ "bridge", "router" ], "remote_system_enable_capab": [ "bridge", "router" ] } ] } } ``` ### Observed Behavior We are getting a {"detail":"Error connecting to the device at 10.65.41.30: ConnectAuthError(10.65.41.30)"} ### More information After some debugging, we checked the ssh logs from the switch we are trying to get Neighbors from: When trying directly from netbox GUI we get a null or blank user while SSH: `RP/0/RP0/CPU0:Oct 19 20:12:46.388 EDT: SSHD_[68735]: %SECURITY-SSHD-3-ERR_GENERAL : User name in USERAUTH_REQUEST is null or blank` When trying using netbox napalm CLI or API it is working: `RP/0/RP0/CPU0:Oct 19 20:13:59.483 EDT: SSHD_[68821]: %SECURITY-SSHD-6-INFO_SUCCESS : Successfully authenticated user 'netbox' from '10.55.18.209' on 'vty1'(cipher 'aes128-ctr', mac 'hmac-sha2-256')` It seems that Napalm from the GUI is not using the NAPALM_USERNAME and NAPALM_PASSWORD provided by the Devices>Platforms we previously created.
adam closed this issue 2025-12-29 18:33:50 +01:00
adam commented 2025-12-29 18:33:50 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 20, 2020):

I did some digging, and it looks like NAPALM arguments only affects optional NAPALM arguments.

This hasn't changed substantially since v2.6.1 to current

@DanSheps commented on GitHub (Oct 20, 2020): I did some digging, and it looks like NAPALM arguments only affects optional NAPALM arguments. This hasn't changed substantially since [v2.6.1](https://github.com/netbox-community/netbox/blob/v2.6.1/netbox/dcim/api/views.py#L389-L404) to [current](https://github.com/netbox-community/netbox/blob/develop/netbox/dcim/api/views.py#L438-L468)
adam commented 2025-12-29 18:33:51 +01:00
Author
Owner
Copy Link

@guillaume-harvey commented on GitHub (Oct 20, 2020):

I just checked back with a colleague and it seems the environment variable in the configuration.py for NAPALM_USERNAME and NAPALM_PASSWORD was empty. My bad for this error. Filling it solve the no user used for the ssh connection.

Though, setting the username and password by the platform should be allowed in order to connect to switch with deferent credentials. In a company with thousands of switch, it is sometime impossible to have unique credentials for all of them.

It should be possible to overwrite that USERNAME and PASSWORD from the NAPALM arguments. My colleague confirmed me that he was able to overwrite them from the Platform in the past maybe 2.6.1 or before.

Is it a change in the design that is expected or is it bugged?

@guillaume-harvey commented on GitHub (Oct 20, 2020): I just checked back with a colleague and it seems the environment variable in the configuration.py for NAPALM_USERNAME and NAPALM_PASSWORD was empty. My bad for this error. Filling it solve the no user used for the ssh connection. Though, setting the username and password by the platform should be allowed in order to connect to switch with deferent credentials. In a company with thousands of switch, it is sometime impossible to have unique credentials for all of them. It should be possible to overwrite that USERNAME and PASSWORD from the NAPALM arguments. My colleague confirmed me that he was able to overwrite them from the Platform in the past maybe 2.6.1 or before. Is it a change in the design that is expected or is it bugged?
adam commented 2025-12-29 18:33:51 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 21, 2020):

Thanks for letting us know! I will go ahead and close this out.

Is it a change in the design that is expected or is it bugged?

AFAIK there was no change to the behaviour that allowed for overwriting. You can overwrite it by setting the X-Napalm-Username and X-Napalm-Password headers however those only work for API requests.

Though, setting the username and password by the platform should be allowed in order to connect to switch with deferent credentials. In a company with thousands of switch, it is sometime impossible to have unique credentials for all of them.

I don't disagree with this, however it is already open under #4980 and that is blocked by #4346. Hopefully we can have some movement on these shortly.

@DanSheps commented on GitHub (Oct 21, 2020): Thanks for letting us know! I will go ahead and close this out. >Is it a change in the design that is expected or is it bugged? AFAIK there was no change to the behaviour that allowed for overwriting. You can overwrite it by setting the X-Napalm-Username and X-Napalm-Password headers however those only work for API requests. > Though, setting the username and password by the platform should be allowed in order to connect to switch with deferent credentials. In a company with thousands of switch, it is sometime impossible to have unique credentials for all of them. I don't disagree with this, however it is already open under #4980 and that is blocked by #4346. Hopefully we can have some movement on these shortly.
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
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#4203
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?