ceos: allow wiring the management interface as a link

[philsphicas]

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]

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

[ankudinov]

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

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.

[ankudinov]

Let's merge and address documenting examples later. This is too useful to hold longer.
Thx @philsphicas

[philsphicas]

Sorry I let this linger. I can pick it up this weekend and get those conflicts resolved (and update the docs and examples). I was also having some (small) second thoughts about whether or not this is the best approach, and want to take one more look with fresh eyes.

Just wondering, did the INTF_MAP_ETH0=Management1 change land yet?

[ankudinov]

@philsphicas INTF_MAP_ETH0 is just out in 4.36.2F. I've tested that quickly and it works, however I think cLab post-deploy is not treating that correctly. I'll take a look and update the docs and whatever else required on cLab side. Stay tuned.