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.

Sign up for GitHub

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

Jump to bottom

[BUG] Arista EOS and Cisco IOSvL2 boot as unconfigured bridges #1825

Closed
ipspace opened this issue Jan 21, 2025 · 3 comments
Closed

[BUG] Arista EOS and Cisco IOSvL2 boot as unconfigured bridges #1825

ipspace opened this issue Jan 21, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@ipspace
Copy link
Owner

ipspace commented Jan 21, 2025

Arista EOS (at least cEOS) and Cisco IOSv layer-2 image boot as bridges with data-plane interfaces enabled and bridging untagged traffic. This could (depending on timing) cause leaking of control-plane traffic, for example IPv6 RA, resulting in stuff like #1821.

We should add an extra pre-initial (normalize ?) step to the initial configuration deployment (netlab initial). It should be executed before the initial module and ignore devices that do not have the corresponding templates.
@ipspace ipspace added the bug Something isn't working label Jan 21, 2025
ipspace added a commit that referenced this issue Jan 21, 2025
@ipspace
Another round of VRRP integration test tuning
237f564 
* Use FRR as the probe instead of EOS (avoids #1825)
* Requires a working IPv6 path (currently breaks IOSv L2)
* Makes IPv4 state transition errors non-fatal to make the
  VRRP implementations not compliant with RFC 9568 pass with
  a warning
@jbemmel
Copy link
Collaborator

jbemmel commented Jan 21, 2025 •
edited
Loading

For vEOS we could change https://netlab.tools/labs/eos/ and add

switchport default mode routed

For cEOS it is possible to insert that same command using a Containerlab feature: https://containerlab.dev/manual/kinds/ceos/#user-defined-config

i.e. override the default config Containerlab uses, and put a Netlab default config that is the same across vEOS and cEOS

For Cisco IOL we could do something similar: https://containerlab.dev/manual/kinds/cisco_iol/#partial-startup-configuration

ipspace added a commit that referenced this issue Jan 21, 2025
@ipspace
Implement 'normalize' configuration step (fixes #1825)
c4198b7 
The 'normalize' configuration step is executed before the 'initial'
step. It's triggered with the 'initial' tag (so it's always executed
together with 'initial' step) and uses an extra variable to signal
the deploy-module task list that it's OK if the template is missing
(as it would be for most devices).

The commit also includes the normalization templates for EOS and IOS
layer-2 images
@ipspace
Copy link
Owner Author

ipspace commented Jan 21, 2025

Thanks for the ideas but:

  • That would require that people rebuild their EOS boxes
  • It would require a complete rehaul of the clab.j2 template (or a bunch of dirty hacks, or extra binds)
  • It would still not solve the IOSv L2 problem.

Implementing the 'normalize' step was pretty easy, review request coming your way.

@jbemmel
Copy link
Collaborator

jbemmel commented Jan 21, 2025

One additional idea (for Containerlab instances): srl-labs/containerlab#2415

I would still consider those changes to the recommended startup config for VMs, without forcing people to rebuild existing ones

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jbemmel @ipspace