netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.31k stars 2.6k forks source link

Cross-reference BGP ASN and Devices #17667

Closed dmulyalin closed 3 weeks ago

dmulyalin commented 1 month ago

NetBox version

v4.1.3

Feature type

Data model extension

Proposed functionality

BGP ASN rarely exist on its own and in most of the cases assigned to or used by devices, Netbox as of now does not have capability to capture what devices use what ASNs without relying on custom fields, adding multiref field to device to link ASNs it is using can help to improve Netbox ASN documentation capabilities.

Use case

Devices use ASN but currently Netbox does not have built in way to establish relationship between BGP ASN and devices apart from using custom fields, this use case is to introduce such a relationship and help network operators document what ASNs used by what devices.

Database changes

Device model need to be extended with asns many-to-many field with relevant UI additions.

External dependencies

None

jeremystretch commented 1 month ago

What specifically are you proposing? Assigning an ASN directly to a device would not suffice for moderately complex routing policies which advertise different AS numbers to different peers. IMO this falls entirely within the scope of BGP routing policy.

dmulyalin commented 1 month ago

I am proposing to link devices with ASNs similar to how we link device interfaces with VLANs, since ASNs used by devices and it is important to capture what devices use what ASN for various use cases - configuration rendering, network audit, troubleshooting to name a few.

cruse1977 commented 1 month ago

Is this not possible using netbox-bgp already ?

Omripresent commented 1 month ago

ASN assignments wouldn't specifically be a device only construct, in some cases it'll be assigned by VRF, in others to a virtual machine.

In https://github.com/DanSheps/netbox-routing plugin the model BGPRouter is meant to bridge that gap, but as it's not fully implemented yet I can't recommend it.

Netbox-BGP doesn't have that functionality, the ASN is associated to a given session and could vary across implementations.

I think the netbox-routing plugin implementation is the right way to go once BGP is implemented.

dmulyalin commented 1 month ago

To me ASN is no different to Vlan or IP address - neither of them exist on its own and always assigned to something, in most of the cases they assigned to and used by devices, physical or virtual, (to me) it is strange to not see built-in capability to link/assign ASN to anything but the site. I would expect I am not the only one who finds a need for such a functionality.

There are many ways to address it though - use custom fields, use custom plugins, it will work, but at the end of the day if many users do these customizations, maybe it is something worth to consider building into Netbox core itself.

I am of course by no means can speak for other users, but thought at least it would be good to raise this to get a feedback.

nickper commented 1 month ago

I can see the need for this. We currently only have 1 public ASN, but run different private ASN's on our Pods. A good way to register this is linking the ASN to the device.

one problem with this approach is that switches and servers often don't have ASNs assigned to them, and therefor have extra bloatware in there view because of this.

jeremystretch commented 4 weeks ago

Device model need to be extended with asns many-to-many field with relevant UI additions.

This was proposed in #8782, and was ultimately rejected because it is insufficient to support complex routing policy. However, I can see the value of a singular ForeignKey assignment of a device to a specific ASN indicating its "native" AS. This still does not address routing policy but it allows for the fundamental association of a device to an ASN.

dmulyalin commented 3 weeks ago

It does not give much value to reference device with single ASN only, in fact it will make things more cumbersome for those folks who configure devices to participate in multiple ASN, if this is the only direction you considering, think it is better to leave things where they are right now.