ipspace
Extend the node 'role' parameter to include bridges
We should have a mechanism to say 'if this device wants to be a bridge, let it be'. We will implement that with bridge value of the node role parameter.
Right now, the role parameter is used primarily with Linux-based devices to implement static routing versus loopback+control plane.
Extending the role parameter would have the following results:
- router -- default for non-Linux devices. The device gets a loopback interface and we expect it will figure out how to reach the rest of the network.
- host -- the device does not have a loopback interface. We assume it does not run routing protocols (although we can check that as well), so we have to configure static routes pointing to default gateway. We might also disable IP routing on devices that can do that.
- bridge -- we will not configure no switchport" on IOSvL2/EOS/NXOS. We might decide to extend that to functionality to Linux devices where we would connect everything into a single Linux bridge.
Finally, we should add roles to device definitions (default: [ router ]) and start checking the role values.
Originally posted by @ipspace in https://github.com/ipspace/netlab/issues/1433#issuecomment-2439627611
@DanPartelly Do you want to work on the core functionality or should I do that and you'll fix the templates?
@DanPartelly Do you want to work on the core functionality or should I do that and you'll fix the templates?
@ipspace depends how fast you want it done and if you have or not more important things to do. Ill use most of my free time next week to get a release of iouyap out and try to make mixed trunk modes work and re-test vlans on iol. Once that is out of the way, I can work on this.
OK, I'll do the core functionality (wanted to do it for a long while but lacked motivation ;) and might implement this on Arista or Linux just to have something to test.
Great. About motivation, I have to thank you and netlab anyway. Its so cool that it made me wanna work on things =)
OK, I'll do the core functionality (wanted to do it for a long while but lacked motivation ;) and might implement this on Arista or Linux just to have something to test.
Unfortunately, I forgot how complex this is. Not configuring "no switchport" on a link without a usable IP address is trivial, but what do you do with that bridged VLAN 1? You cannot connect it to anything else without the VLAN module, and even there you have to jump through the hoops defining VLAN 1 and making it native on other interfaces.
I will create a new branch and add developer documentation (effectively documenting my ideas) into it. I think that might work better than typing text in web forms.
In any case, I don't think it's realistic to expect this to be finished in 1.9.2 timeframe.