Ability to assign a VRF to a BGP Session

[VEEC023]

In service provider environments, it's common for BGP sessions to operate within a specific VRF context. However, the Netbox BGP Plugin currently does not support assigning a VRF to a BGP Session.

We've been working around this limitation by using a custom field, but this approach is not ideal — especially when modeling larger and more complex network scenarios. Ideally, VRF assignment should be a native attribute of a BGP Session, similar to how it's handled for interfaces in NetBox.

This enhancement would allow for more accurate representation of real-world routing setups, where sessions may need to be configured in different routing contexts based on their assigned VRFs.

Would be great to see this considered for future development!

Thanks!

[jwbensley]

This probably needs more thought. The IP address a BGP session is assigned to already supports being assigned to a VRF in NetBox. IPs in NetBox can be assigned to an interface. Interfaces can also already be assigned to a VRF. If VRF is added to BGP sessions is well, then it becomes possible for the BGP session, IP address, and interface, to be in three different VRFs.

There is probably a bigger question here to address about how stuff is mapped to VRFs in NetBox in general.

At $dayjob we set the VRF on the interface only. On network devices, it is really the interface that sits in the VRF. IPs aren't actually in a VRF on a network device; the IP is configured on an interface and whatever VRF the interface is configured in is where the IP ends up.

I think that makes sense for IP addresses and for interfaces. For BGP sessions, to avoid adding the custom field like you did, and to avoid allowing the BGP to be in a different VRF than the IP address or interface; we look at the IP the BGP session is bound to, and then the interface the IP is bound to. Whatever VRF that interface is in, is the VRF the BGP session goes into.

I'm not saying we do it the best way, I'm simply saying there is more than one way to do this; just adding a VRF field to the BGP session might not be the best way, because as I said, there will then be three places the VRF can bet set and they can (and will!) come out of sync with each other.

[dmulyalinvs]

@jwbensley this is use case we need as well, BGP sessions always belong to a VRF either global or custom, and in device configuration BGP sessions configured inside of the VRF.

Adding BGP session reference to VRF

• more accurate BGP sessions modeling in accordance with devices configuration
• BGP sessions filtering will be possible on a per-vrf basis
• BGP session uniqueness constraint can take into account VRF placement, since it is possible to have multiple BGP sessions with same ASN and IP in different VRFs
• IPAM -> VRF view can be updated to display related BGP sessions

[jwbensley]

I would love to see these the features @dmulyalinvs mentioned. Perhaps this BGP plugin can implement this by looking up the VRF of the interface the BGP session is configured on?