Skip to content
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

Open
ipspace opened this issue Oct 27, 2024 · 5 comments
Open

Extend the node 'role' parameter to include bridges #1447

ipspace opened this issue Oct 27, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@ipspace
Copy link
Owner

ipspace commented Oct 27, 2024

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 #1433 (comment)

@ipspace
Copy link
Owner Author

ipspace commented Oct 27, 2024

@DanPartelly Do you want to work on the core functionality or should I do that and you'll fix the templates?

@ipspace ipspace added the enhancement New feature or request label Oct 27, 2024
@DanPartelly
Copy link
Collaborator

DanPartelly commented Oct 27, 2024

@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.

@ipspace
Copy link
Owner Author

ipspace commented Oct 27, 2024

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.

@DanPartelly
Copy link
Collaborator

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.

@ipspace ipspace added 1.9.2 and removed 1.9.2 labels Oct 30, 2024
@ipspace
Copy link
Owner Author

ipspace commented Oct 31, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants