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

Add support for "Network Protocols" #9509

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

Originally created by @dmulyalin on GitHub (Apr 21, 2024).

NetBox version

v3.7.5

Feature type

New functionality

Proposed functionality

Add support to document network protocols in Netbox.

Proposed approach would allow to model protocols that we run in the Networks, including but not limited to:

  • OSPFv2/OSPFv3
  • ISIS
  • BGP
  • RIP
  • EIGRP
  • PCEP
  • MSDP
  • mLDP
  • LLDP
  • CDP
  • PIM
  • IGMPv2/IGMPv3
  • STP
  • MSTP
  • RSTP
  • BFD
  • LDP
  • RSVP
  • REP
  • SyncE
  • PTP
  • Ethernet CFM
  • LISP

Use case

Network Protocols is what makes Networks work the way they intended to. Support to document network protocols can become a major milestone in Netbox evolution and give birth to a vast amount of productive use cases.

The goal is not to document network routing, the goal is to document Network Protocols, their administrative boundaries, devices they are running on, interfaces participating in protocol and protocol peerings.

Few use case examples:

  1. Service Provider runs MPLS Network and would like to document network devices and interfaces that have LDP and RSVP enabled making sure all interfaces participating in MPLS have correct configuration applied.
  2. Enterprise recently designed IP multicast architecture for their network and would like to model PIM and IGMP protocol in their source of truth to drive network configuration provisioning.
  3. Decision been made by IT department to roll out BFD across their WAN infrastructure, they would like to document BFD enabled interfaces and timers in their Source of Truth.
  4. ISIS enabled in the core of the Service Provider network with OSPF running on aggregation and access layers, capturing devices running these protocols and keeping track of interface metrics would help to deprecate the spreadsheets Ops teem been maintaining for 99 years.
  5. New customers are onboarded regularly by MSP, each running a set of protocols such as IGP, BGP, BFD, PIM. Modeling network protocols in the SoT would help MSP NOC to facilitate troubleshooting efforts as automation can be created to verify protocols state based on the SoT records.

I understand this is a big ask, but the upside of this being implemented in Netbox is really exciting.

I am happy to assist wherever I can.

Database changes

Network Protocols from the perspective of documentation practicality can be broken down into four major components:

  • Protocol Instance - represents protocol administrative boundary
  • Protocol Processes - represents a process running on an individual device
  • Protocol Interfaces - a set of interfaces that protocol enabled on
  • Protocol Peerings - connections or sessions used by protocol to exchange information

Proposed approach would allow to model any network protocol that can be described using above components.

Above components can be represented in WEB UI navigation pane as such:

"Network Protocols"
|____"Instances"
|____"Devices"
|____"Interfaces"
|____"Peerings"

Protocol Instance Table

Protocol Instance represents a set of devices that collectively participate in a protocol under same administrative boundary. For example, all OSPF enabled devices that form same routing domain would be a single protocol instance of OSPF. There are could be multiple instances of same protocol type running on same set of devices, which is accounted for by this approach. For BGP because it can have only single process on the device, protocol instance would map to BGP ASN. For STP, protocol instance would correspond to a set of devices that share interconnected L2 domains. For BFD, protocol instance would simply represent a collection of devices that share same protocol parameters and administered by same team.

As such this table needed to represent protocol instance:

Field Name Field Type Description
id integer protocol_instance database identifier
name string Protocol Instance name
type selection string protocol type, one of supported protocols: ISIS, OSPF, RIP, BGP, MSDP etc.
tenant object reference reference to Tenant
description string protocol instance description
tags multi-object reference list of references to tags defined in netbox
comments multiline string field for additional information about protocol with markdown support
contacts multi-object reference list of references to contacts defined in netbox
protocol_process multi-object reference list of references to protocol processes defined in netbox
custom_fields any any additional custom fields defined by user

Protocol instance WEB UI view can have multiple tabs referring to:

  • devices
  • interfaces
  • protocol peerings
  • contacts

Protocol Process Table

Protocols processes run on devices. Protocol processes on different devices can have different parameters, hence the need to have this table:

Field Name Field Type Description
id integer protocol_process database identifier
name string Protocol process name
device object reference reference to a single device this process running on
protocol_instance object reference Reference to Protocol Instance
protocol_interface multi-object reference list of references to protocol_interfaces defined in netbox
protocol_peering multi-object reference list of references to peerings defined in netbox, refer to "Protocol Peerings" for more details
router-id object reference reference to IP address representing router identifier for the process
vrf object reference reference to VRF defined in Netbox
description string protocol process description
tags multi-object reference list of references to tags defined in netbox
comments multiline string field for additional information about protocol process with markdown support
custom_fields any any additional custom fields defined by user

Protocol Interface Table

Many protocols enabled on individual interfaces, hence the need for dedicated table to keep track of all the interfaces participating in given protocol instance using this table:

Field Name Field Type Description
id integer protocol_interface database identifier
interface object reference reference to device interface defined in Netbox
protocol_process object reference Reference to Protocol process
protocol_instance object reference Reference to Protocol Instance
metric integer Protocol metric vaue if applicable
keepalive_timer integer Protocol keepalive interval timer
holddown_timer integer Protocol holddown interval timer
authentication_type selection string One of: MD5, SHA1, SHA2 etc.
priority integer Protocol interface priority
description string protocol interface description
tags multi-object reference list of references to tags defined in netbox
comments multiline string field for additional information about protocol interface with markdown support
custom_fields any any additional custom fields defined by user

Protocol Peering

Many protocol use peerings to establish exchange of information, as such this table needed:

Field Name Field Type Description
id integer protocol_peering database identifier
name string Protocol peering name
protocol_process object reference Reference to Protocol process
protocol_instance object reference Reference to Protocol Instance
keepalive_timer integer Protocol peering keepalive interval timer
holddown_timer integer Protocol peering holddown interval timer
authentication_type selection string One of: MD5, SHA1, SHA2 etc.
source_ip object reference reference to IP defined in Netbox
destination_ip object reference reference to IP defined in Netbox
description string protocol peering description
tags multi-object reference list of references to tags defined in netbox
comments multiline string field for additional information about protocol peering with markdown support
custom_fields any any additional custom fields defined by user

External dependencies

None that I am aware of.

Originally created by @dmulyalin on GitHub (Apr 21, 2024). ### NetBox version v3.7.5 ### Feature type New functionality ### Proposed functionality Add support to document network protocols in Netbox. Proposed approach would allow to model protocols that we run in the Networks, including but not limited to: - OSPFv2/OSPFv3 - ISIS - BGP - RIP - EIGRP - PCEP - MSDP - mLDP - LLDP - CDP - PIM - IGMPv2/IGMPv3 - STP - MSTP - RSTP - BFD - LDP - RSVP - REP - SyncE - PTP - Ethernet CFM - LISP ### Use case Network Protocols is what makes Networks work the way they intended to. Support to document network protocols can become a major milestone in Netbox evolution and give birth to a vast amount of productive use cases. The goal is not to document network routing, the goal is to document Network Protocols, their administrative boundaries, devices they are running on, interfaces participating in protocol and protocol peerings. Few use case examples: 1. Service Provider runs MPLS Network and would like to document network devices and interfaces that have LDP and RSVP enabled making sure all interfaces participating in MPLS have correct configuration applied. 2. Enterprise recently designed IP multicast architecture for their network and would like to model PIM and IGMP protocol in their source of truth to drive network configuration provisioning. 3. Decision been made by IT department to roll out BFD across their WAN infrastructure, they would like to document BFD enabled interfaces and timers in their Source of Truth. 4. ISIS enabled in the core of the Service Provider network with OSPF running on aggregation and access layers, capturing devices running these protocols and keeping track of interface metrics would help to deprecate the spreadsheets Ops teem been maintaining for 99 years. 5. New customers are onboarded regularly by MSP, each running a set of protocols such as IGP, BGP, BFD, PIM. Modeling network protocols in the SoT would help MSP NOC to facilitate troubleshooting efforts as automation can be created to verify protocols state based on the SoT records. I understand this is a big ask, but the upside of this being implemented in Netbox is really exciting. I am happy to assist wherever I can. ### Database changes Network Protocols from the perspective of documentation practicality can be broken down into four major components: - Protocol Instance - represents protocol administrative boundary - Protocol Processes - represents a process running on an individual device - Protocol Interfaces - a set of interfaces that protocol enabled on - Protocol Peerings - connections or sessions used by protocol to exchange information Proposed approach would allow to model any network protocol that can be described using above components. Above components can be represented in WEB UI navigation pane as such: ``` "Network Protocols" |____"Instances" |____"Devices" |____"Interfaces" |____"Peerings" ``` **Protocol Instance Table** Protocol Instance represents a set of devices that collectively participate in a protocol under same administrative boundary. For example, all OSPF enabled devices that form same routing domain would be a single protocol instance of OSPF. There are could be multiple instances of same protocol type running on same set of devices, which is accounted for by this approach. For BGP because it can have only single process on the device, protocol instance would map to BGP ASN. For STP, protocol instance would correspond to a set of devices that share interconnected L2 domains. For BFD, protocol instance would simply represent a collection of devices that share same protocol parameters and administered by same team. As such this table needed to represent protocol instance: | Field Name | Field Type | Description | | ------------- |-------------| -----| | id | integer | protocol_instance database identifier | | name | string| Protocol Instance name | | type | selection string | protocol type, one of supported protocols: ISIS, OSPF, RIP, BGP, MSDP etc. | | tenant | object reference | reference to Tenant | | description | string | protocol instance description | | tags | multi-object reference | list of references to tags defined in netbox | | comments | multiline string | field for additional information about protocol with markdown support | | contacts | multi-object reference | list of references to contacts defined in netbox | | protocol_process | multi-object reference | list of references to protocol processes defined in netbox | | custom_fields | any | any additional custom fields defined by user | Protocol instance WEB UI view can have multiple tabs referring to: - devices - interfaces - protocol peerings - contacts **Protocol Process Table** Protocols processes run on devices. Protocol processes on different devices can have different parameters, hence the need to have this table: | Field Name | Field Type | Description | | ------------- |-------------| -----| | id | integer | protocol_process database identifier | | name | string | Protocol process name | | device | object reference | reference to a single device this process running on | | protocol_instance | object reference | Reference to Protocol Instance | | protocol_interface | multi-object reference | list of references to protocol_interfaces defined in netbox | | protocol_peering | multi-object reference | list of references to peerings defined in netbox, refer to "Protocol Peerings" for more details | | router-id | object reference | reference to IP address representing router identifier for the process | | vrf | object reference | reference to VRF defined in Netbox | | description | string | protocol process description | | tags | multi-object reference | list of references to tags defined in netbox | | comments | multiline string | field for additional information about protocol process with markdown support | | custom_fields | any | any additional custom fields defined by user | **Protocol Interface Table** Many protocols enabled on individual interfaces, hence the need for dedicated table to keep track of all the interfaces participating in given protocol instance using this table: | Field Name | Field Type | Description | | ------------- |-------------| -----| | id | integer | protocol_interface database identifier | | interface | object reference | reference to device interface defined in Netbox | | protocol_process | object reference | Reference to Protocol process| | protocol_instance | object reference | Reference to Protocol Instance | | metric | integer | Protocol metric vaue if applicable | | keepalive_timer | integer | Protocol keepalive interval timer | | holddown_timer | integer | Protocol holddown interval timer | | authentication_type | selection string | One of: MD5, SHA1, SHA2 etc. | | priority | integer | Protocol interface priority | | description | string | protocol interface description | | tags | multi-object reference | list of references to tags defined in netbox | | comments | multiline string | field for additional information about protocol interface with markdown support | | custom_fields | any | any additional custom fields defined by user | **Protocol Peering** Many protocol use peerings to establish exchange of information, as such this table needed: | Field Name | Field Type | Description | | ------------- |-------------| -----| | id | integer | protocol_peering database identifier | | name | string | Protocol peering name | | protocol_process | object reference | Reference to Protocol process| | protocol_instance | object reference | Reference to Protocol Instance | | keepalive_timer | integer | Protocol peering keepalive interval timer | | holddown_timer | integer | Protocol peering holddown interval timer | | authentication_type | selection string | One of: MD5, SHA1, SHA2 etc. | | source_ip | object reference | reference to IP defined in Netbox | | destination_ip | object reference | reference to IP defined in Netbox | | description | string | protocol peering description | | tags | multi-object reference | list of references to tags defined in netbox | | comments | multiline string | field for additional information about protocol peering with markdown support | | custom_fields | any | any additional custom fields defined by user | ### External dependencies None that I am aware of.
adam added the type: featurestatus: under review labels 2025-12-29 20:50:47 +01:00
adam closed this issue 2025-12-29 20:50:48 +01:00
adam commented 2025-12-29 20:50:48 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Apr 23, 2024):

Thanks for the thoroughly reasoned feature request. No doubt there will be more conversation here soon, but in the near term I wonder if you've considered how much of this vision could be realized in a plugin. That's likely to come up as the team reviews this issue in more depth.

@jeffgdotorg commented on GitHub (Apr 23, 2024): Thanks for the thoroughly reasoned feature request. No doubt there will be more conversation here soon, but in the near term I wonder if you've considered how much of this vision could be realized in a plugin. That's likely to come up as the team reviews this issue in more depth.
adam commented 2025-12-29 20:50:49 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Apr 24, 2024):

While I agree that this functionality can be implemented using plugin, my thinking around plugins is that if proposed feature is niche, narrow and would benefit only a subset of Netbox' users, plugin is the best way to go.

"Network Protocols" feature is on the other side of the spectrum - it is an extreme example of general purpose functionality that can be used to document and address vast amount of use cases. Literally every user of Netbox would benefit from this as every network uses network protocols. Documenting which currently have to resort to customization capabilities of Netbox such as custom fields or config contexts, which is ok, but it means each and every one of us has to re-invent the wheel over and over again, while making "Network Protocols" integral part of Netbox' functionality would provide uniform way of documenting this, streamlining user experience and bringing tangible benefits to networking community.

Proposed approach is open ended to accommodate variety of scenarios, but specific enough to ensure development efforts would provide attractive ROI for the Netbox' Team.

@jeremystretch what would be your opinion on this?

Was wondering, is there a way to poll Netbox users to vote for the feature to see if anybody but me interested in this? Maybe Twitter?

@dmulyalin commented on GitHub (Apr 24, 2024): While I agree that this functionality can be implemented using plugin, my thinking around plugins is that if proposed feature is niche, narrow and would benefit only a subset of Netbox' users, plugin is the best way to go. "Network Protocols" feature is on the other side of the spectrum - it is an extreme example of general purpose functionality that can be used to document and address vast amount of use cases. Literally every user of Netbox would benefit from this as every network uses network protocols. Documenting which currently have to resort to customization capabilities of Netbox such as custom fields or config contexts, which is ok, but it means each and every one of us has to re-invent the wheel over and over again, while making "Network Protocols" integral part of Netbox' functionality would provide uniform way of documenting this, streamlining user experience and bringing tangible benefits to networking community. Proposed approach is open ended to accommodate variety of scenarios, but specific enough to ensure development efforts would provide attractive ROI for the Netbox' Team. @jeremystretch what would be your opinion on this? Was wondering, is there a way to poll Netbox users to vote for the feature to see if anybody but me interested in this? Maybe Twitter?
adam commented 2025-12-29 20:50:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 24, 2024):

@dmulyalin it makes little sense to me to model two dozen largely unrelated protocols using a general-purpose mechanism. There's a lot more to modeling these technologies in a useful manner beyond just recording protocol semantics. There's an entire plugin just for BGP, for instance. Experience tells me that attempting to bundle these all into a single set of generic models will not yield sufficient value to justify the effort.

@jeremystretch commented on GitHub (Apr 24, 2024): @dmulyalin it makes little sense to me to model two dozen largely unrelated protocols using a general-purpose mechanism. There's a lot more to modeling these technologies in a useful manner beyond just recording protocol semantics. There's an entire [plugin](https://github.com/netbox-community/netbox-bgp) just for BGP, for instance. Experience tells me that attempting to bundle these all into a single set of generic models will not yield sufficient value to justify the effort.
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 status: under review 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#9509
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?