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

Device info retrieval fails if device dual stacked, but netbox is not #1134

New Issue
Closed
opened 2025-12-29 16:29:17 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:29:17 +01:00
Owner
Copy Link

Originally created by @wmclendon on GitHub (Jul 30, 2017).

Issue type: Bug Report

**Python version: 2.7.12
**NetBox version: 2.1.0

Hello,

Upgraded to 2.1 today, and got NAPALM working with Junos devices -- great work! Issue I came across is some of my Junos devices have primary IPv4 and IPv6 addresses defined (ie border router), however my Netbox server is not yet dual stacked, and has only link local IPv6 address. When trying to pull LLDP neighbor or any NAPALM data for device, Netbox reports the following error:

{"detail":"Error connecting to the device: ConnectRefusedError(2001:db8::1)"}

Obviously it cannot reach the IPv6 address, however it never tries the IPv4 address as well

I suspect this is not an issue directly related to Netbox, however curious if something could be implemented where it either will try the IPv6 address first, then the IPv4 address if the IPv6 address fails, or allow some sort of user-defined preference as to which to try.

The workaround I have right now is to just uncheck the 'primary' setting for the IPv6 address for the given devices.

Thanks,

Will

Originally created by @wmclendon on GitHub (Jul 30, 2017). <!-- Please note: GitHub issues are to be used only for feature requests and bug reports. For installation assistance or general discussion, please join us on the mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please indicate "bug report" or "feature request" below. Be sure to search the existing set of issues (both open and closed) to see if a similar issue has already been raised. --> ### Issue type: Bug Report <!-- If filing a bug, please indicate the version of Python and NetBox you are running. (This is not necessary for feature requests.) --> **Python version: 2.7.12 **NetBox version: 2.1.0 <!-- If filing a bug, please record the exact steps taken to reproduce the bug and any errors messages that are generated. If filing a feature request, please precisely describe the data model or workflow you would like to see implemented, and provide a use case. --> Hello, Upgraded to 2.1 today, and got NAPALM working with Junos devices -- great work! Issue I came across is some of my Junos devices have primary IPv4 and IPv6 addresses defined (ie border router), however my Netbox server is not yet dual stacked, and has only link local IPv6 address. When trying to pull LLDP neighbor or any NAPALM data for device, Netbox reports the following error: {"detail":"Error connecting to the device: ConnectRefusedError(2001:db8::1)"} Obviously it cannot reach the IPv6 address, however it never tries the IPv4 address as well I suspect this is not an issue directly related to Netbox, however curious if something could be implemented where it either will try the IPv6 address first, then the IPv4 address if the IPv6 address fails, or allow some sort of user-defined preference as to which to try. The workaround I have right now is to just uncheck the 'primary' setting for the IPv6 address for the given devices. Thanks, Will
adam closed this issue 2025-12-29 16:29:17 +01:00
adam commented 2025-12-29 16:29:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 31, 2017):

NetBox will default to the IPv6 address for a device if it has one, but you can override this behavior by setting PREFER_IPV4 to True in configuration.py.

@jeremystretch commented on GitHub (Jul 31, 2017): NetBox will default to the IPv6 address for a device if it has one, but you can override this behavior by setting [`PREFER_IPV4`](http://netbox.readthedocs.io/en/stable/configuration/optional-settings/#prefer_ipv4) to True in configuration.py.
adam commented 2025-12-29 16:29:18 +01:00
Author
Owner
Copy Link

@wmclendon commented on GitHub (Jul 31, 2017):

Indeed, that fixed it right up -- sorry not sure how I missed that option. Thanks for response! i'll close the issue out

@wmclendon commented on GitHub (Jul 31, 2017): Indeed, that fixed it right up -- sorry not sure how I missed that option. Thanks for response! i'll close the issue out
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#1134
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?