-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend the node 'role' parameter to include bridges #1447
Comments
@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 =)
|
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. |
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:
Finally, we should add roles to device definitions (default:
[ router ]
) and start checking the role values.Originally posted by @ipspace in #1433 (comment)
The text was updated successfully, but these errors were encountered: