Faster netlab up and create frr.conf as files?

[Muddyblack]

So netlab has the frr.ospvX Jinja files / it has to create at some point the configuration for those devices.
What I was wondering about is the idea for frr devices to create those configs as files (for clab in the clab_files directory)
and eventually bind them into the clab.yml file directly?

This would allow to just use clab up and have them instantly configured without needing later ansible configurations.
(Maybe I could have done my scripts better in searching for the frr.conf creation function in netlabs codebase and use it directly.)

Or just allow to create the config files only with an argument without destroying netlabs original workflow?
I think that could be useful.

Anyways I would still like to make the netlab up command become faster :D
Maybe we could discuss on that?

[ipspace]

So netlab has the frr.ospvX Jinja files / it has to create at some point the configuration for those devices. What I was wondering about is the idea for frr devices to create those configs as files (for clab in the clab_files directory) and eventually bind them into the clab.yml file directly?

This is how daemons (like bird or dnsmasq) work. One of these days I have to write a daemons documentation ;)

This would allow to just use clab up and have them instantly configured without needing later ansible configurations.

It would definitely work for control-plane daemons configured through FRR, but how do you currently set IP addresses on interfaces? I know I tried to use "ip address" commands in FRR and it did not end well (at least not when I was testing it). Other daemons might not even have the ip command available in the container, so we do initial configuration from the outside, using ip netns exec commands on the host to configure container networking features.

Also, there are tons of other data-plane features that FRR does not configure, so we have to use other Linux commands to get things like VLANs or VXLAN up and running.

Any ideas on how to solve these minor details? 😎

[Muddyblack]

I am slowly getting more and more into this codebase xD I rewrote my stuff now as a plugin much better ...
Thank you for this project really!
For netlab ansible-forks / parallelization also do not help ^-^

For the interface adressing I just have a frr.conf so similar way netlab uses.

But when I have again some more free time I will do research and look what options are there to get it faster in any way ...

[Muddyblack]

Also what about the idea to allow to split a lab across multiple servers?
Like it creates topology_server1.yml etc and automatic increments correctly the addressing ranges if some are defined.
So a person just copies that to the other server.
But here it is probably hard to determine which devices get placed on which server ... so just a thought for now

[ipspace]

I am slowly getting more and more into this codebase xD I rewrote my stuff now as a plugin much better

Nice ;))

For netlab ansible-forks / parallelization also do not help ^-^

No surprise there...

For the interface adressing I just have a frr.conf so similar way netlab uses.

Note to self:

It looks like it should be pretty easy to add an FRR daemon without the data-plane functionality (so no VLANs, VRFs, or VXLAN).

[ipspace]

Also what about the idea to allow to split a lab across multiple servers?

I was thinking about that, but never found the need to do so. Obviously, we could try to reuse Clabernetes (https://containerlab.dev/manual/clabernetes/quickstart/) but I'm guessing that would just add layers of bloatware (the K8S part) and you wouldn't be happy with how fast that would work.

Like it creates topology_server1.yml etc and automatic increments correctly the addressing ranges if some are defined. So a person just copies that to the other server.

That should be doable, and with properly set up port forwarding (at least for containers) even the overlapping address ranges should not be a problem. We would also have to set up VXLAN devices for the Linux bridges to have end-to-end connectivity though.

But here it is probably hard to determine which devices get placed on which server ... so just a thought for now

I would let the user do that, otherwise we're opening an NP-complete can of worms.

[Muddyblack]

I already tried c9s the generated configs are too big for kubernetes.
c9s would require:

a more appropriate fix for big scale topos would be for c9s to not only own the topology CR, but also handle individual Link and Node CRs - this is not implemented

-cite Roman Dodin

Ended up using vxlans