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

Integrate NAPALM to support pulling live data from devices #1103

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

Originally created by @jeremystretch on GitHub (Jul 14, 2017).

Issue type: Feature request

Python version: 2.7.6
NetBox version: 2.0.10

Today, NetBox has very limited support for interacting with network devices. It has some custom RPC code for connecting to some Juniper, Cisco, and Opengear devices to pull inventory and LLDP information, but this functionality is very limited and error-prone. We can integrate the NAPALM automation project to abstract the RPC logic and support much more functionality with a wide array of devices.

At a high level, here are some changes that will be needed:

  • Add a napalm_driver field to dcim.Platform (new database migration)
  • Create a custom form widget for the napalm_driver field to list all built-in drivers but also allow free text to specify a custom driver
    • The field's help_text should indicate that NAPALM must be installed
  • Add a custom permission napalm_read to dcim.Device
  • Add a napalm detail route to dcim.api.DeviceViewSet. This will accept the NAPALM operation as part of the URL
    • E.g. GET /api/dcim/devices/<pk>/napalm/get_facts/
    • Unsupported operations will return an error indicating such
  • Create a "NAPALM" tab on the device view (this replaces the LLDP tab)
    • This view will include a list of all available NAPALM operations. Selecting an operation will populate the page with data from the API
Originally created by @jeremystretch on GitHub (Jul 14, 2017). ### Issue type: Feature request **Python version:** 2.7.6 **NetBox version:** 2.0.10 Today, NetBox has very limited support for interacting with network devices. It has some custom RPC code for connecting to some Juniper, Cisco, and Opengear devices to pull inventory and LLDP information, but this functionality is very limited and error-prone. We can integrate the [NAPALM automation](https://github.com/napalm-automation) project to abstract the RPC logic and support much more functionality with a wide array of devices. At a high level, here are some changes that will be needed: * Add a `napalm_driver` field to dcim.Platform (new database migration) * Create a custom form widget for the `napalm_driver` field to list all built-in drivers but also allow free text to specify a custom driver * The field's `help_text` should indicate that NAPALM must be installed * Add a custom permission `napalm_read` to dcim.Device * Add a `napalm` detail route to dcim.api.DeviceViewSet. This will accept the NAPALM operation as part of the URL * E.g. `GET /api/dcim/devices/<pk>/napalm/get_facts/` * Unsupported operations will return an error indicating such * Create a "NAPALM" tab on the device view (this replaces the LLDP tab) * This view will include a list of all available NAPALM operations. Selecting an operation will populate the page with data from the API
adam closed this issue 2025-12-29 16:28:53 +01:00
adam commented 2025-12-29 16:28:54 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 14, 2017):

Just to comment on this, I agree that this integration would be nice, however it appears to contradict with what NetBox was originally intended to be. To quote from the documentation, "As such, automated import of live network state is strongly discouraged." Perhaps that goal has changed as NetBox has matured.

While I would be interested in the functionality, great care would be needed to ensure that the information gathered from NAPALM is "vetted by a human to ensure its integrity" with a few validation steps that the user would need to walk through.

This is just me thinking out loud, not necessarily "gospel".

@bdlamprecht commented on GitHub (Jul 14, 2017): Just to comment on this, I agree that this integration would be nice, however it appears to contradict with what NetBox was _originally_ intended to be. To quote from the [documentation](http://netbox.readthedocs.io/en/stable/#serve-as-a-source-of-truth), "As such, automated import of live network state is strongly discouraged." Perhaps that goal has changed as NetBox has matured. While I would be interested in the functionality, great care would be needed to ensure that the information gathered from NAPALM is "vetted by a human to ensure its integrity" with a few `validation` steps that the user would need to walk through. This is just me thinking out loud, not necessarily "gospel".
adam commented 2025-12-29 16:28:54 +01:00
Author
Owner
Copy Link

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

@bdlamprecht The intent here is provide a convenient way of retrieving data from live devices for display and (to some extent) validation. For example, NetBox currently supports pulling live LLDP neighbors from a device to compare with what's defined in its database and highlight any discrepancies (this functionality will be replaced by NAPALM). The key is that none of this data is being written to NetBox's database: it is only being retrieved and inspected.

The one exception to this will be inventory data, which makes sense to import directly from devices. Unfortunately, NAPALM doesn't currently support collecting inventory data so this functionality may still be a ways off.

@jeremystretch commented on GitHub (Jul 14, 2017): @bdlamprecht The intent here is provide a convenient way of retrieving data from live devices for display and (to some extent) validation. For example, NetBox currently supports pulling live LLDP neighbors from a device to compare with what's defined in its database and highlight any discrepancies (this functionality will be replaced by NAPALM). The key is that none of this data is being written to NetBox's database: it is only being retrieved and inspected. The one exception to this will be inventory data, which makes sense to import directly from devices. Unfortunately, NAPALM doesn't currently support collecting inventory data so this functionality may still be a ways off.
adam commented 2025-12-29 16:28:54 +01:00
Author
Owner
Copy Link

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

I have this working in the develop-2.1 branch. It will be included in the v2.1 release.

@jeremystretch commented on GitHub (Jul 17, 2017): I have this working in the `develop-2.1` branch. It will be included in the v2.1 release.
adam commented 2025-12-29 16:28:54 +01:00
Author
Owner
Copy Link

@rkutsel commented on GitHub (Jul 17, 2017):

I agree this is a huge deal. I've been waiting for this announcement for a
while and can't wait to test it once the stable is out.

On Mon, Jul 17, 2017 at 10:35 bdlamprecht notifications@github.com wrote:

Wow, very cool that you got this working already! Nice work.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/1348#issuecomment-315825246,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARj55TReWAg72RQn_ntm-4biOMQWt2iSks5sO5tGgaJpZM4OYaD6
.

--
Roman N. Kutsel

@rkutsel commented on GitHub (Jul 17, 2017): I agree this is a huge deal. I've been waiting for this announcement for a while and can't wait to test it once the stable is out. On Mon, Jul 17, 2017 at 10:35 bdlamprecht <notifications@github.com> wrote: > Wow, very cool that you got this working already! Nice work. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/digitalocean/netbox/issues/1348#issuecomment-315825246>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ARj55TReWAg72RQn_ntm-4biOMQWt2iSks5sO5tGgaJpZM4OYaD6> > . > -- Roman N. Kutsel
adam commented 2025-12-29 16:28:54 +01:00
Author
Owner
Copy Link

@alesz commented on GitHub (Jul 20, 2017):

Great feature, will definitely come handy. Would it be possible to run queries via dedicated bastion CM host at some point?

@alesz commented on GitHub (Jul 20, 2017): Great feature, will definitely come handy. Would it be possible to run queries via dedicated bastion CM host at some point?
adam commented 2025-12-29 16:28:55 +01:00
Author
Owner
Copy Link

@MrQuiX commented on GitHub (Feb 9, 2018):

It would be great to use NAPALM to compare the output of get_interfaces_ip against the existing table, just like LLDP. Even better would be an option to import interfaces without any data, or manually affirm an overwrite.

@MrQuiX commented on GitHub (Feb 9, 2018): It would be great to use NAPALM to compare the output of get_interfaces_ip against the existing table, just like LLDP. Even better would be an option to import interfaces without any data, or manually affirm an overwrite.
adam commented 2025-12-29 16:28:55 +01:00
Author
Owner
Copy Link

@mk311d commented on GitHub (Feb 12, 2018):

+1 for a bit of automation
Could imagine to import the interfaces after the device has been added to the inventory or during the process of adding it.
An additional thing I can imagine but maybe it's not aligned with the concept of netbox, to automatically monitor the assigned IP's to hosts. To make it easier, let's say for only those IP's where the device has an interface in the subnet (physical interface or SVI). Monitoring ARP or pinging the device.

Automatically populating the interfaces would be a big big help anyway.

@mk311d commented on GitHub (Feb 12, 2018): +1 for a bit of automation Could imagine to import the interfaces after the device has been added to the inventory or during the process of adding it. An additional thing I can imagine but maybe it's not aligned with the concept of netbox, to automatically monitor the assigned IP's to hosts. To make it easier, let's say for only those IP's where the device has an interface in the subnet (physical interface or SVI). Monitoring ARP or pinging the device. Automatically populating the interfaces would be a big big help anyway.
adam commented 2025-12-29 16:28:55 +01:00
Author
Owner
Copy Link

@davelaramee-ssense commented on GitHub (May 2, 2018):

Hello,

First awesome tool, I love netbox!

! EDIT
! My issue is the name of the interfaces does not match in netbox vs lldp response
! I need to rename my interfaces in netbox
!

I have just integrated napalm (running locally on ubuntu 16.04, version 2.3.3, via: pip3 install napalm)

But,
Running Cisco ios-xe
System image file is "bootflash:isr4400-universalk9.03.16.04b.S.155-3.S4b-ext.SPA.bin"

With lldp running, I am not able to get neighbor information under the neighbors tab.
Although the other tabs do show proper information (status and config)

The router does display lldp information as following;
S418-RTR-BS01#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID Local Intf Hold-time Capability Port ID
S418-DSW-BS01.corp.sGi0/0/0 120 B Gi1/0/23
S418-DSW-BS01.corp.sGi0/0/1 120 B Gi1/0/22

Total entries displayed: 2

I guess I am missing something, Not too sure where to check for any troubleshooting.

Thank you for you help

@davelaramee-ssense commented on GitHub (May 2, 2018): Hello, First awesome tool, I love netbox! ! EDIT ! My issue is the name of the interfaces does not match in netbox vs lldp response ! I need to rename my interfaces in netbox ! I have just integrated napalm (running locally on ubuntu 16.04, version 2.3.3, via: pip3 install napalm) But, Running Cisco ios-xe System image file is "bootflash:isr4400-universalk9.03.16.04b.S.155-3.S4b-ext.SPA.bin" With lldp running, I am not able to get neighbor information under the neighbors tab. Although the other tabs do show proper information (status and config) The router does display lldp information as following; S418-RTR-BS01#show lldp neighbors Capability codes: (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other Device ID Local Intf Hold-time Capability Port ID S418-DSW-BS01.corp.sGi0/0/0 120 B Gi1/0/23 S418-DSW-BS01.corp.sGi0/0/1 120 B Gi1/0/22 Total entries displayed: 2 I guess I am missing something, Not too sure where to check for any troubleshooting. Thank you for you help
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#1103
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?