Support for bridge group assignment

[jeremystretch]

NetBox version

v2.11.2

Feature type

Data model extension

Proposed functionality

Introduce support for modeling bridge group interface assignments. This was originally raised in #6170 as a new interface type, but it was quickly realized that a more robust approach would be needed. I see two options for implementation:

1. Add a bridge field to the Interface model to function similarly to the parent field, and use a "bridge" interface to correlate bridge members.
2. Add a new BridgeGroup model. All member interfaces (include an actual "bridge" interface, if present) would be assigned to this.

Either approach would also require the introduction of a new "bridge" interface type as proposed in #6170.

Use case

Implementing this will allow users to accurately model interfaces and subinterfaces which belong to a common L2 domain within a device/VM.

Database changes

TBD

External dependencies

No response

[BarbarossaTM]

How would the BridgeGroup approach work and how/where would one define a BridgeGroup? I assume a BridgeGroup would have a 1:1 relationship to a bridge interface an 1:n to member ports? Or am I totally off here to what you have in mind?

[jeremystretch]

Thinking about it further, #2 above probably doesn't make sense. I can't think of a situation where you would have multiple interfaces into a bridge group. It's probably sufficient to just create a bridge interface.

[sdktr]

A bridgegroup can be seen as a device -local L2 instance. We have devices that are modelled exactly like this. A bridgegroup is only mapped to a vlan-tag (incl. optionally untagged) on the physical interface level. I believe this is a common setup for service provider L2 access networks. See slide 27 from this Cisco Live presentation.

Am I confusing bridge groups with bridge domains here?

Another example of bridge groups are wireless access points that bridge a Dot11 radio subinterface to a GigEthernet subinterface. If I had to model these I would go for the new Parent relation:
Parent: BVI (virtual)
Child1: Dot11.10 (Access vlan 10)
Child2: GigEthernet0.10 (access vlan 10)

[DanSheps]

Going to tag this as needs milestone with the assumption on option 1 (bridge is tied to the bridge interface)

[howard-2020]

I'm an engineer for an ISP and we are starting to use Netbox. We would love to see a new model for bridge group or "L2VPN". A bridge domain can span across multiple routers and have multiple interfaces on each router, including virtual connections facing the core such as a MPLS pseudo-wire or an EVPN-EVI. In EVPN-IRB you can even have the same BVI Anycast Gateway across your EVPN L2 domain on all the routers.

For a model to work in our environment we would need the following elements:

• A new global data model to create a L2VPN (bridge-domains or point-to-point). You would need to record Name, Description, MTU, assign to a tenant, include comments, and allow custom fields.
• Point-to-point L2VPN would only allow two members while Bridge Domain would allow any amount.
• Ability to add any interface(L2 or L3) from any device as a member to the new data model and optionally select a vlan on that interface since some interfaces would be untagged.

Here is an bridge-domain example across three routers using MPLS:

Router01:

bridge-domain ACME_CUSTOMER_BD
  interface Bundle-Ether20.45   <---vlan 45
  interface BVI45               <---L3 routed interface
  !
  neighbor 2.2.2.2 pw-id 45     <---pseudo-wire ID for MPLS peering with R2
  neighbor 3.3.3.3 pw-id 45     <---pseudo-wire ID for MPLS peering with R3

Router02:

bridge-domain ACME_CUSTOMER_BD
  interface TenGigE0/1/0/2      <---untagged
  interface Bundle-Ether60.45   <---vlan 45
  !
  neighbor 1.1.1.1 pw-id 45     <---pseudo-wire ID for MPLS peering with R1

Router03:

bridge-domain ACME_CUSTOMER_BD
  interface TenGigE0/0/0/13      <---untagged
  interface Bundle-Ether60.45    <---vlan 45
  !
  neighbor 1.1.1.1 pw-id 45     <---pseudo-wire ID for MPLS peering with R1

For EVPN you would simply replace the neighbor statements with a single EVI command under each bridge domain which would contain an EVI ID.

We would need to create a L2VPN named "ACME_CUSTOMER_BD" and add all the interfaces above on all three routers. We could use the comments or custom field for the pseudo-wire ID (or in EVPN, the EVI ID). Then when the customer calls I can search by Tenant, Click on the L2VPN stats, and then quickly find all interfaces which are a part of the L2VPN.

I believe this would provide a simple way to create virtual circuits or networks. I don't know a good way to document the core facing elements(Pws, EVI, Tunnels) since technologies would vary across users of Netbox so I think it would be sufficient to document these via custom fields or comments.

[xkilian]

Isn't all this an overlap with the L2 overlay model? A device local bridge group makes sense, but for L2 domains distributed on multiple equipment is already covered.

[howard-2020]

I do not see where Netbox can do this today. When you say it is already covered - is that in a current release or planned for future? Please elaborate.