refactor: update containerlab provider to use frr kind for frr device…

[Muddyblack]

…s and bump version to 0.80.0

[jbemmel]

This needs to change too for the new frr kind, Containerlab has something built-in for it

[jbemmel]

I understood there is a special containerlab release version for this image

[Muddyblack]

It does add ssh and stuff I will test if it is really required or not.
I mean its nice to have anyways all my frr images are built with ssh and iperf3 and some other stuff

[Muddyblack]

It already worked without the clab image before but needed before pausing restarting a node to manually run write memory and then run vtysh -f /etc/frr/frr.conf.

[Muddyblack]

So I tested it with a plain frr 10.7.1 no containerlab-frr and if using the frr kind and doing a containerlab save all worked .

same for the extras.frr.daemons

Node	Daemons running	Memory
extras.frr.daemons: [ospfd]	mgmtd, ospfd, staticd, watchfrr, zebra	18.8 MiB
default (no selection)	all 19	73.2 MiB

[Muddyblack]

As far as I understand this clab frr image is just so you can run their normal clab stuff like ssh admin@<node> as they usually support ssh jump for any kind.

Without that then only docker exec shell variant works...

Since netlab configures all using the docker shell anyways we do not really care no?

The other thing I honestly have no knowledge about seems to be the netlab_mgmt_vrf for clab? but netlab handles this already I think.

[ipspace]

As far as I understand this clab frr image is just so you can run their normal clab stuff like ssh admin@<node> as they usually support ssh jump for any kind.

Correct.

Since netlab configures all using the docker shell anyways we do not really care no?

Also correct.

The other thing I honestly have no knowledge about seems to be the netlab_mgmt_vrf for clab? but netlab handles this already I think.

Also correct.

[ipspace]

There are three things to unpack here:

• Change minimum containerlab version to 0.80.0 -- no problem there, submit those changes as a separate PR
• Use kind: frr for frr device -- the significant change is the daemons file which netlab is already managing to start only the required daemons. Going to the frr kind would be a step back (from the resource consumption perspective) as they start all daemons by default (which is the only way to make FRR containers usable without extra tweaks).
• Use containerlab-specific FRR container image, which adds SSH daemon.

While I have no problem supporting frr kind for FRR, it currently adds no value for scenarios where netlab is building the complete device configs. It's only useful if someone adds new protocols manually (and doesn't care about memory utilization). The absolute minimum we'd need is to deal with both options, remove mapping bind for the daemons file in a device quirk if frr kind is used, and generate a warning if someone specifies required FRR daemons with the frr kind.

For the moment, we might want to add frr kind support, document the differences in caveats (or even create a separate FRR document), but keep linux as the default.

Finally, the FRR container with the SSH daemon. I would document what tweaks have to be put in place to use it, or maybe we can install them in a device quirk if someone sets (for example) frr.ssh: true node flag.

[Muddyblack]

So the extras.frr.daemons setting would not work correctly (if doing a mapping of it to the current approach) is that what you mean or the way you want it to for netlab.

[Muddyblack]

So with netlab initial using linux kind does erstore the configs right for the netlab node restart issue I have opened I think I could add such then if wanted?

Also if running manually write memory the configuration on restart is also automatically back using linux kind not having to rerun vtysh -f /etc/frr/frr.conf.

[Muddyblack]

So maybe do the mapping stuff for the extras.frr.daemons as an extra PR?

see

So I tested it with a plain frr 10.7.1 no containerlab-frr and if using the frr kind and doing a containerlab save all worked .

same for the extras.frr.daemons
Node Daemons running Memory
extras.frr.daemons: [ospfd] mgmtd, ospfd, staticd, watchfrr, zebra 18.8 MiB
default (no selection) all 19 73.2 MiB

[ipspace]

So with netlab initial using linux kind does erstore the configs right for the netlab node restart issue I have opened I think I could add such then if wanted?

And you should have started with this bit of information. It's always nice to know there are reasons (and what they are) behind the proposed changes.

However, do keep in mind that the only thing restored after the container restart is the FRR config. No data-plane feature (apart from IP addresses) is restored, thus no VLANs, VRFs, LAG, or VXLAN. It's better than nothing, but it still deserves a huge caveat.

[ipspace]

So maybe do the mapping stuff for the extras.frr.daemons as an extra PR?

How about you submit the "new containerlab version" PR first (see above), and in the meantime let me think about the way to do kind: frr with minimum impact (or at least with fallback mechanisms and caveats).

[sdargoeuves]

Finally, the FRR container with the SSH daemon. I would document what tweaks have to be put in place to use it, or maybe we can install them in a device quirk if someone sets (for example) frr.ssh: true node flag.

I haven't played much with frr but when I do, I use this config-snippets so I can ssh to the frr device:

#!/bin/bash
echo "nameserver 1.1.1.1" > /etc/resolv.conf
ip vrf exec mgmt apk update && ip vrf exec mgmt apk add openssh
ssh-keygen -A
grep -qxF '/usr/bin/vtysh' /etc/shells || echo '/usr/bin/vtysh' >> /etc/shells
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication yes/' /etc/ssh/sshd_config
adduser -D -s /usr/bin/vtysh admin 2>/dev/null || true
echo "admin:admin" | chpasswd
addgroup admin frrvty 2>/dev/null || true
addgroup admin frr 2>/dev/null || true
ip vrf exec mgmt /usr/sbin/sshd

Is this the sort of config that should happen if the user sets ffr.ssh: true?

[ipspace]

Is this the sort of config that should happen if the user sets ffr.ssh: true?

Thanks a million.

I was thinking more about "if someone chose the container with SSH server, we can tweak the parameters so they connect via ssh", but I'm sure your code will come handy. It's just that I don't want to download/install SSH every time an FRR container is started.