Multiaccess link on virtualized switch

[DanPartelly]

Not sure how valuable this would be. Ive been working on some narbik inspired labs. I worked with some multi access links, and once I got it working, it worked well. But what about having multi access links on a virtualised switch, for example on a iosvl2, in a succinct way. like [r1-r2-r3-sw1] [r4-r5-sw1], maybe coupled with the VLAN module ? Again, frankly, Im not sure its a worth having feature, hence a discussion first.

[jbemmel]

Too resource intensive imho, plain Linux bridge works great for this. People that want this can declare it explicitly in their topology

[DanPartelly]

Too resource intensive imho, plain Linux bridge works great for this. People that want this can declare it explicitly in their topology

Very true, it is resource intensive, but so is just about any virtualized device used with netlab. Id mention that this cost is a "dont pay for what you dont use" type.

The biggest boon netlab gave me is the ability to define labs in a pretty terse and compact format. And not bother typing or copy pasting saved configs. Generally speaking and strictly from my personal point of view , any feature which makes a lab specification less verbose is worth having.

[ipspace]

The biggest boon netlab gave me is the ability to define labs in a pretty terse and compact format.

Agreed ;)

Generally speaking and strictly from my personal point of view , any feature which makes a lab specification less verbose is worth having.

I hear you ;)) but any feature this specific has to be implemented in a plugin. Moving the "what should the plugin do" discussion to the bottom.

[ipspace]

If you want to do that, you can define the links within the vlans definition. They have to be P2P links though.

I was thinking about implementing a bridge functionality (plugin) that would automatically define access VLAN 1 on all ports of a node with role: bridge in case nothing else is defined there. You could then use a Linux container, or any regular network device to be the bridge.

Compared to builtin Linux bridges, you'd get more visibility, and you could use devices you're more familiar with (for example, IOSvL2). Performance would suck though.

[ipspace]

Oh, and of course the bridge plugin could rewrite multi-access links into hub-and-spoke topology going through a bridge, but I don't know what the benefits of that would be. If you want to apply a set of attributes to a number of links, you can always use link groups.

[ipspace]

@DanPartelly: How do you envision turning multi-access links into a hub-and-spoke topology? In particular:

• I see no other way but making that multi-access link a separate bridging domain (access VLAN)
• That bridging domain should have an independent VLAN ID, and would not be compatible with VLAN trunks. Alternatively, we could make the extra VLAN ID the native ID on that set of links.
• The extra VLAN should be internal to bridge to which it's connected.

Now for the fun part: what happens if you have two bridges connected to the same multi-access link? I'm guessing we should try to keep our sanity and declare that an unsupported topology.

Comments? Improvements? Suggestions? Anything else I've missed?

[DanPartelly]

This is how I envisioned it as well , except I never thought at the case of two bridges connected to the same link. Unsupported sounds sane.

As for improvements, I am far from having your expertise in networking, I lack your foresight here, so I default to your judgment. ideas might flow once I use a certain features and practically try topologies.

Btw, I tried your new netlab capture feature just now. It is a nice touch.