Add support for "Network Protocols"

[dmulyalin]

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.

[jeffgdotorg]

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.

[dmulyalin]

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?

[jeremystretch]

@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.