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.

[julianze]

There is a plugin which models virtual-circuits:
https://github.com/vapor-ware/netbox-virtual-circuit-plugin

At the moment is this restricted to vlans, but could be a good start for l2vpn modeling.
That could maybe address #583 .

We are also want to model l2vpn/VPLS or xconnect/pseudowire (point-to-point) with netbox and the plugin´s seems the most useful base therefore.
If our internal plan is more specified we may fork or extend this plugin for this use case. Instead of only supporting vlans we have to add interfaces with vlan´s (as service instance in metro ethernet architecture) and support pushing/popping vlans for vlan manipulation.

Maybe there will be an native support in netbox:

!!! note NetBox currently models only physical circuits: those which have exactly two endpoints. It is common to layer virtualized constructs (virtual circuits) such as MPLS or EVPN tunnels on top of these, however NetBox does not yet support virtual circuit modeling.

[sleepinggenius2]

I don't mean to muddy the water on this specific subject, but I've been doing a lot of work recently in NetBox and have found a number of scenarios where it would be nice to have some form of virtual cross-connect within a device. I view this as an expansion on the way that connectivity is currently supported between front and rear ports and I believe that those existing cross-connects could be migrated to this new model as well. I have drawn out a few scenarios below, including a way to represent bridge groups, which I feel fall into this category.

Effectively, I would propose adding a new cross-connect model that would allow connecting interfaces and ports together, like we can with cables, but also including virtual interfaces. These would be internal to a device, there could be one or more per interface/port, and they would not interfere with connecting cables, which would still work the same as today. Each cross-connect would be point-to-point, optionally directional, and would have an optional near-end channel, far-end channel, and channel width. You can connect multiple cross-connects to an interface/port if the channel is null, otherwise the channel must be unique. Each cross-connect would also optionally have a label, just like cables today. The channels would preferably be defined beforehand, like positions are on rear ports today, but as a list of text values, instead of a 1-n range of numbers.

Most traces should work similarly to the way they do today for front/rear ports, just with named positions instead of numeric ones. I don't know enough about the current model for how to handle one-to-many scenarios, but they should be able to be handled in the same way as was going to be done for bridge groups. I've run into every one of the scenarios below so far and have been able to find workarounds using the existing front/rear ports model, but the traces/connections have been the biggest issue, because they show really weird values.

I just wanted to throw in my proposal now, as I feel like one model could be used to address a number of issues that have been raised. I would be happy to discuss my proposal further and am open to suggestions. Overall, I've been very appreciative of NetBox as a platform and the support from the community, so I would like to try to get more involved with helping to make it even better.

[jeremystretch]

I'm revisiting this issue in the course of working on #3979 (wireless networking), and I like the idea of being able to simply bridge one interface to another. This would allow us to define both bridge groups and one-to-one "cross connects" internal to a device.

For example, multiple physical interfaces (or subinterfaces) can be bridged a virtual bridge interface (e.g. br0) on a router to form a bridge group. We could also bridge one physical interface to another (e.g. eth0 to wlan0), as is common on devices such as wireless access points, especially for point-to-point wireless links.

This would enable following a traffic path beyond a terminating interface where a point-to-point bridge association has been identified. For example, we could trace an end-to-end path between routers connected via an intermediate point-to-point wireless link:

[router1] --- [panel1] --- [panel2] --- [AP1] - - - - - - - [AP2] --- [panel3] --- [panel4] --- [router2]

By bridging the wired and wireless interfaces on either AP, we could effect a trace across three CablePaths:

1. (router1, cable, panel1, cable, panel2 cable, AP1)
2. (AP1, wireless link, AP2)
3. (AP2, cable, panel3, cable, panel4, cable, router2)

These bridge associations would be unidirectional, such that traffic ingressing one interface must egress exactly one other interface. (It would not be possible to trace through a bridge group as doing so would involve L2 forwarding decisions.)

[jeremystretch]

@sleepinggenius2 it's an interesting proposal, though I'm not sure we'd be able to take on the degree of complexity it demands. I would note that that combiner and splitter scenarios are supported today, in the form of multi-position rear ports mapped to individual front ports, and the bridge scenario seems like it would be supported by my proposal above.

[sleepinggenius2]

You can skip to the last two paragraphs for the bulk of the implementation details for my counter proposal.

@sleepinggenius2 it's an interesting proposal, though I'm not sure we'd be able to take on the degree of complexity it demands. I would note that that combiner and splitter scenarios are supported today, in the form of multi-position rear ports mapped to individual front ports, and the bridge scenario seems like it would be supported by my proposal above.

I've run into some issues using that approach for splitters and combiners. Specifically, if you connect the rear ports on a 2x1 combiner and a 2x1 splitter, then tracing from port 1 on the combiner egresses port 1 on the splitter, but not port 2. If you chain multiple splitters and combiners together, then there is still at most only one path traced, sometimes none. I understand that the current implementation is not able to trace more than one path without external input. It seems that this is still required even if two paths ultimately re-converge. I've also see this issue in places where the forward path and return path do not match, since cables do not have directionality to them.

In this context, I could see how a splitter or combiner could be implemented as a bridge group, but it would be at L1 instead of L2, so would unfortunately need to use front/rear ports instead of interfaces, and thus could not be done with your current proposal.

Given the proposed ability to create one-to-one associations between interfaces, my next question would be do we still need the separate front/rear port model? For pass-through panels, a front interface and rear interface could still be bridged together. For breakout panels, front interfaces could still be bridged one-to-one to rear sub-interfaces representing the previous concept of rear port positions. Similar logic to what we have today should still be usable to relate these new "sub-interfaces" on either end of a cable together in the same way as rear port positions. One big advantage is this could allow for arbitrarily named positions to match a user's needs. Using this model, I think we could also address #5798, assuming these "sub-interfaces" could be classified in a way that they could have both a parent and LAG interface applied to them, if needed. I actually ran into this issue recently with some Cisco 4x10G QSFP+ breakout optics, that if I made the TenGigE interfaces virtual, then I could associate them with their parent Optics interface, but then I couldn't use them as part of a LAG. I ultimately just set their type to Other, because I felt it was more important to represent them as part of a LAG and the parent relationship was represented well enough just in their name.

While the use of SONET technologies seems to be waning, I have certainly seen an increase in the use of WDM and OTN. Based on my proposal above, I think STS paths, WDM wavelengths, and OTN channels could all be represented using similar models. I know there have been a number of other issues raised over the years about at least WDM as well. Building on the concepts of the last paragraph, using a wavelength as the name on one of these potentially special sub-interfaces, you should be able to implement an OADM network to support WDM. Basically, the same as my drawings above, but the channels on the interfaces would be these sub-interfaces instead.

Counter-proposal starts here

So, I would add to your proposal a sub-interface type to represent a channel, which would be virtual, and a sub-interface type to represent a breakout interface, which can be added to a LAG, but cannot have a cable connected. These sub-interface types would be required to have a parent interface and a given parent interface could only have one type of sub-interface. I think a channel sub-interface should be able to have a breakout sub-interface as a parent and either can have a physical interface as a parent. I would also propose adding a new optional field for parent_position that would support a short string value. This field would be used to replace the previous rear port position when relating opposite ends of a cable for traces. All interfaces would then be be able to have one cross-connect connected to them, distinct from any cable connections, except for a special bridge type that can have multiple cross-connects connected to it. It would also be cool to be able to have cross-connects as part of a device template, but I wouldn't want that to hold up implementation. That could be required if also supporting the migration from the existing front/rear port paradigm to this new implementation.

In order to support breakout sub-interfaces having a channel sub-interface as a child, tracing would need to be able to keep track of a stack of positions that could change encapsulation throughout the trace. Tracing would still ingress a physical interface through a cable, like it does today. If the interface has sub-interfaces and we are tracing for a specific position that the interface does not have a sub-interface for, then we have an implementation decision to make. Option A would be to stop the trace at that point. Option B would be to continue tracing if there is a cross-connect from that physical interface to another interface. I think Option A would be correct for breakout sub-interfaces. Allowing Option B only for channel sub-interfaces would make it a lot easier to implement a common interface and an express interface for an OADM, while still being able to drop specific wavelengths, so that would get my vote, but I can understand where that might be confusing for some users. It would then take into account cross-connects. If the interface connects to a bridge interface, then tracing stops at the bridge interface. If the interface connects to another physical interface, then tracing continues through a cable connected to that interface. Otherwise, if we are not tracing for a specific position, then tracing stops there. If there is a sub-interface that matches the current position, then use it to continue tracing. If the sub-interface connects to a bridge interface, then stop the trace at the bridge interface. If the sub-interface connects to a physical interface, then tracing continues through a cable connected to that interface. If the sub-interface connects to another sub-interface, then pop the current position from the stack and push the new sub-interface's position onto the stack. Continue the trace up the sub-interface's hierarchy, pushing positions as needed until a physical interface is reached. Tracing continues through a cable connected to that interface. It would be cool to also show connections for sub-interfaces in the interfaces table by using their position to start the trace. I would be happy to flowchart and/or diagram this out, so that it might be easier to follow.

[jeremystretch]

@sleepinggenius2 It's an interesting idea but I'm afraid it's well outside the scope of this particular issue. I invite you to create a new feature request citing your use case and proposed implementation, and see what kind of interest it draws from the community. For now, we're focused just on bridging interfaces.

[sleepinggenius2]

@sleepinggenius2 It's an interesting idea but I'm afraid it's well outside the scope of this particular issue. I invite you to create a new feature request citing your use case and proposed implementation, and see what kind of interest it draws from the community. For now, we're focused just on bridging interfaces.

I have opened #7552, #7553, and #7554 for what I believe are the three principal components of my implementation. I included the ability to specify cross-connects as part of a device template within my proposal for #7554, but it would be really nice to have that as part of the scope for the implementation of this issue.

[BarbarossaTM]

Hi @jeremystretch, thanks for #7622!

I was under the impression that the scope of this contained adding an interface type "bridge" so it would be possible to denote that on interface is a bridge (group/domain) even if it were not to have and members (at first). At least this was my intention in #6170 and that's how I understood your summary above:

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

As far as I see in the code the #7622 does not include a new interface type. Could we please add this? With the current approach I don't see how people would be able to model bridges without any member interfaces in Netbox (which I have a lot as other parts of the automation / system put interfaces into the bridges dynamically).

We maybe want to think about a search filter as well, so only interfaces of type bridge can be selected for the bridge attribute.

Thanks

[jeremystretch]

I was under the impression that the scope of this contained adding an interface type "bridge"

With this implementation, there isn't really an effective difference between a "bridge" type and the existing "virtual" type.

With the current approach I don't see how people would be able to model bridges without any member interfaces in Netbox

Is the "virtual" type not sufficient for this?

[BarbarossaTM]

Is the "virtual" type not sufficient for this?

No because I cannot distinguish between an OpenVPN, Wireguard, vEth, macvlan, GRE, ..., and bridge interface that way as all of them are virtual and have to fall back to some guesstimation elsewhere which I really would like to get rid of as it requires the name to be like br-*. On Linux boxes this can be done somehow when sticking to this naming convention on vendor boxes this might be harder or impossible. Adding a new interface type would be an easy fix for this problem.

[jeremystretch]

Alrighty, sounds good.