Skip to content

ceos: allow wiring the management interface as a link - #3237

Open
philsphicas wants to merge 1 commit into
srl-labs:mainfrom
philsphicas:ceos-wire-eth0
Open

ceos: allow wiring the management interface as a link#3237
philsphicas wants to merge 1 commit into
srl-labs:mainfrom
philsphicas:ceos-wire-eth0

Conversation

@philsphicas

Copy link
Copy Markdown

Permit the cEOS management interface (eth0) to be used as a regular topology link when the node is detached from the containerlab management network with network-mode: none. This makes the management port behave like that of a physical switch: it can be cabled to a management host or an out-of-band management switch, and comes up unaddressed unless the link or startup-config provides an address, enabling realistic ZTP topologies.

The default behavior is unchanged: without network-mode: none the node keeps Management0 on the management network with its assigned address.

  • CheckInterfaceName allows an eth0 endpoint only with network-mode: none
  • the management gateway and auto-addressing are skipped when detached; the management address is sourced from the wired eth0 link instead, resolved independently per address family
  • a startup-config-provided management address is preserved when no address is otherwise derived
  • boot waits for a wired eth0 to be attached before EOS starts, so the management interface comes up from it

Permit the cEOS management interface (eth0) to be used as a regular
topology link when the node is detached from the containerlab
management network with network-mode: none. This makes the management
port behave like that of a physical switch: it can be cabled to a
management host or an out-of-band management switch, and comes up
unaddressed unless the link or startup-config provides an address,
enabling realistic ZTP topologies.

The default behavior is unchanged: without network-mode: none the node
keeps Management0 on the management network with its assigned address.

- CheckInterfaceName allows an eth0 endpoint only with network-mode: none
- the management gateway and auto-addressing are skipped when detached;
  the management address is sourced from the wired eth0 link instead,
  resolved independently per address family
- a startup-config-provided management address is preserved when no
  address is otherwise derived
- boot waits for a wired eth0 to be attached before EOS starts, so the
  management interface comes up from it
@ankudinov

Copy link
Copy Markdown
Contributor

Thank you @philsphicas
I'll test and review this PR soon. Referencing #3220 to track full discussion.

@ankudinov

Copy link
Copy Markdown
Contributor

@philsphicas Had no chance to review this PR before, but not abandoned it. Looks very solid at the first glance and even AI is happy. =) Great work!
I've tested your fork in my lab quickly and it works as expected.
However before I dig further - one usability question...
Imagine a lab:
image
Obviously the 2nd switch is not reachable directly as it's mgmt port is connected to the other switch. The only way to interact with it is using docker exec or building a functional OOB, etc.
While this looks very useful for digital twin, etc. I'm a bit concerned about users with limited container experience and would like to learn a bit more about your use case and how you interact with such devices in the lab?
Technically we have enough disclaimers in the docs already, but if possible make it very visible and add an example.
I'd also minimize references to ZTP. My personal opinion - testing ZTP on container is somewhat wrong (even if technically possible =) and pushes unprepared users to AppArmor adventure and other challenges.
This isn't too critical as docs look great already, but nice if this will be addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants