ceos: support remapping and manual wiring of the management interface

[philsphicas]

Adds two opt-in management-interface options to the cEOS kind.

• MGMT_INTF: maN exposes the management interface as ManagementN (e.g. Management1) while still using the containerlab management network and its assigned address. Management1 is the management interface name used by vEOS and physical EOS switches, so startup-configs and automation written for those devices can be reused without renaming the management interface.
• With network-mode: none, the management interface can be wired as a regular link to another node — cabled directly to a management host, or to a management switch that aggregates several nodes' management ports. No management address is assigned unless the link (or startup-config) provides one, so the interface only comes up addressed when the wiring is actually in place.

The default is unchanged: without MGMT_INTF (or with eth0) the node keeps Management0 on the management network. Any non-maN value is passed through to cEOS with a warning. The legacy MAPETH0 flag (a no-op on current cEOS images) is dropped automatically when maN is used.

Docs: new Management interface section on the cEOS kind page.

Tested with arista_ceos:

• default (Management0 on the management network),
• MGMT_INTF: ma1 on the management network (usable Management1, reachability preserved),
• ma1 wired to a Linux node with network-mode: none (no auto address; address from the link).

Relates to #3037, #1469, #389, #2019.

[philsphicas]

Hi @hellt and @ankudinov - would appreciate your feedback on this when you get a chance. I know mgmt-interface naming has been discussed before (#3037 et al.), and I tried to address the concerns raised in those earlier discussions - it's explicit opt-in (MGMT_INTF: ma1 gives you Management1), the Management0 default is untouched, and the eth1_1 shorthand still works. It also lets you wire the mgmt interface as a real link with network-mode: none, which makes it possible to test ZTP in more interesting, realistic topologies. Open to changes.

[ankudinov]

@philsphicas Thank you for submitting this PR. Mgmt interfaces on cEOS-lab definitely need fixing.
We might be in the same event with @hellt this week and will try to find some time to discuss this.
I'd prefer to avoid Containerlab doing heavy lifting though and rely on cEOS-lab image:

1. interface map - that was always working, but requires a bit of work to be defined and mounted
2. INTF_MAP_ETH0=Management1 - this is the new env var we are planning to add to solve the problem. However it is not yet shipped.
   So, as a starting point it would be enough to document the new env variable when it's shipped.
   2nd step could be a deprecation warning for Ma0 as the default.
   3rd step - swap the default and document INTF_MAP_ETH0=Management0 as opt-out knob.

[philsphicas]

@ankudinov Thanks, that helps. Letting the image take care of the mapping definitely sounds like the best approach.

Two smaller things I'd still like to do, separately:

1. Allow wiring eth0 as a normal link (with network-mode: none). Right now the cEOS kind rejects eth0 as a link endpoint, while other platforms (linux/sros/6wind_vsr/fdio_vpp/veesix_osvbng) allow it. Any objection to a small PR for that?

2. Auto-generating the interface map. You said there might be appetite if it's opt-in. Is that still the case, or is the timeframe for the eth0-mapping so close that it's not worth it? For the opt-in I was thinking either a clab-side knob (e.g. mgmt-interface: Management1) or just honoring the future env var name so the same topology keeps working once the image supports it. Any preference?

[hellt]

we've discussed this with @ankudinov at the conference, and it seems we agree that ceos will handle the interface mapping of maN in the image itself;

the bits related to mapping of the maN interfaces with network-mode: none are good to be proposed as a standalone PR

[ankudinov]

@philsphicas
INTF_MAP_ETH0 is just around the corner and I'd definitely avoid adding interface map logic to the container lab. It's also an additional complexity that can be solved externally.
network-mode: none looks quite useful. Please make sure that you have all test case in place and short description for a lab topology to represent the use case and I'll test it as part of the review.
You can reduce the scope of this PR and rename it. But it could be easier to close this one and open another for network-mode: none only.

[philsphicas]

Hi @ankudinov and @hellt ... Thanks very much for the feedback! I created #3237 and will abandon this one.

My feelings on the new PR are slightly mixed. It maintains the invariant that eth0 is always ManagementX (whatever cEOS decides it should be), which is good, but it forces the user to patch it as eth0 (not maX), which is slightly less user-friendly.

Either way, we need to manually insert an interface - the other option is to insert it as maX (still letting cEOS do the mapping to ManagementX), but that is basically the original PR.

Unfortunately, I won't be able to work on it for a couple of weeks ... if you need to make edits, feel free, otherwise I will resume in the first week of July.

[hellt]

this begs the question if then we should wait for Ma1 to arrive first and then revisit this problem with a cleaner approach?

[philsphicas]

This is slightly orthogonal to the future change.

Once you do network mode none, eth0 is gone. To wire the management interface, we need to plumb a new interface.

The main question is: do you care what the interface is named at the OS level?

Creating it as eth0 (what the change does) is compatible with INTF_MAP_ETH0 and lets cEOS map correctly (to ManagementX) but you still reference it as eth0 in the links.

Creating the interface as ma0 (or ma1 etc.) still lets cEOS do the mapping, and allowing wiring as maX, but it violates the principle that "eth0 is always the management interface".