Add VRF to Routing Instance Model

[Jawny]

Environment

• Nautobot version: 2.0.3
• nautobot-bgp-models version: 2.3.1

Proposed Functionality

Add VRF to routing instance model and enforce routing instances be unique with (AS,VRF) pairs.

Use Case

Allows users to query a routing instance and get back VRF. Also since a VRF is a separate virtual routing instance on a device it make sense to have a mapping between Routing Instance <> VRF. The default routing instance can represent the default VRF and new ones created can be associated with some other VRF. This allows multiple peerings to be created with the same AS but with different VRFs.

[mzbroch]

Thanks for the PR! Could You share with me why existing AddressFamily model and VRF relation does not work for You? I'd like to understand what vendor we aim to model and their BGP configuration. Idea behind BGPRoutingInstance was to model a "bgp process" (literally a UNIX program/process running), assuming Unix-like platforms can have multiple deamons running.

[zsblevins]

This is for Cumulus routers, we have certain peerings that need to be established in multiple VRFs. The configuration appears as follows:

...
    vrf:
      default:                             # VRF name, default here
        router:
          bgp:
            address-family:
              ipv4-unicast:
                aggregate-route:
                  X.X.X.X/26:
                    route-map: AGGREGATE-ROUTE
                    summary-only: on
                enable: on
                redistribute:
                  connected:
                    enable: on
                    route-map: REDISTRIBUTE-CONNECTED
            enable: on
            neighbor:
              X.X.X.X:
                peer-group: OOB-SWITCH
                description: oobsw1
                type: numbered
                remote-as: 4266008000
              ...
            path-selection:
              multipath:
                aspath-ignore: on
            peer-group:
              ...
              OOB-SWITCH:
                address-family:
                  ipv4-unicast:
                    community-advertise: {}
                    policy:
                      inbound:
                        route-map: RM-OOBSW-IN
                      outbound:
                        route-map: RM-OOBSW-OUT
                    soft-reconfiguration: on
                  l2vpn-evpn:
                    enable: off
                bfd:
                  detect-multiplier: 3
                  enable: on
                  min-rx-interval: 300
                  min-tx-interval: 300
                password: <REDACTED>
              ...
      TO-TAN:  # VRF name, TO-TAN
        evpn:
          enable: on
          vni:
            '1000': {}
          vlan: 1000
        router:
          bgp:
            rd: X.X.X.X:1000
            address-family:
              ipv4-unicast:
                enable: on
                redistribute:
                  connected:
                    enable: on
                    route-map: REDISTRIBUTE-CONNECTED
                route-export:
                  to-evpn:
                    enable: on
            enable: on
            neighbor:
              X.X.X.X:                    # Distinct IP/interface from the peering in default
                peer-group: OOB-SWITCH
                description: oobsw1
                type: numbered
                remote-as: 4266008000
            ...
            peer-group:
              OOB-SWITCH:
                address-family:
                  ipv4-unicast:
                    community-advertise: {}
                    policy:
                      inbound:
                        route-map: RM-OOBSW-IN
                      outbound:
                        route-map: RM-OOBSW-OUT
                    soft-reconfiguration: on
                  l2vpn-evpn:
                    enable: off
                bfd:
                  detect-multiplier: 3
                  enable: on
                  min-rx-interval: 300
                  min-tx-interval: 300
                password: <REDACTED>
              ...
            route-export:
              to-evpn:
                route-target:
                  4266000000:1000: {}
            route-import:
              from-evpn:
                route-target:
                  4266000000:1000: {}

So we need to model peerings between this router and oobsw1 in the above example, the default VRF peering is established on the physical interface, and the TO-TAN peering is established on a sub-interface between the 2 in VLAN 1000. This is for EVPN.

[Jawny]

@mzbroch @glennmatthews Any chance you have some time to review these changes?

[glennmatthews]

Sorry for the delayed response - can this not be represented in the current model as it stands? Do the two different VRFs have different ASNs, or what part of this config specifically is not modelable at present?

[ryanheffernan]

Both VRFs are in the same AS. If they were different ASs then we could model them as seperate routing instances with their own peerings.

However, since they are in the same AS, can't model them as seperate routing instances currently, and have to create both peerings in the same instance. When we are building our configs based on this modelling, we need to get the BGP peers for each VRF from nautobot, and since the routing instance doesn't have a VRF association, the only way to do this is to query all endpoints in the instance and loop through each source interface to check whether it's associated with the VRF or not.

    bgp_routing_instances {
      status {
        name
      }
      autonomous_system {
        asn
      }
      endpoints {
        source_interface {
          name
          vrf {
            name
          }
        }

To me it logically makes sense that a VRF would be mapped to it's own routing instance, even if it shares an AS with another VRF on the same device, and that peers should be configured for the instance associated with that VRF. Then with this modelling the query of "give me all peers for this VRF" would be something like

  bgp_routing_instances(vrf: "VRF_NAME") {
      status {
        name
      }
      autonomous_system {
        asn
      }

[Jawny]

Hey @glennmatthews and @mzbroch, wanted to follow up again :)

[mzbroch]

Apologies for the delay. I've conducted a more in-depth analysis and would like to move forward toward resolving this. We'll have solutions ready soon.