search

srl-labs / containerlab

container-based networking labs
https://containerlab.dev
BSD 3-Clause "New" or "Revised" License
1.52k stars 261 forks source link

improve ceos configuration persistency logic #513

Closed hellt closed 3 years ago

hellt commented 3 years ago

arista ceos is a challenging platform when it comes to the management network addressing

the issue arises with the fact that ceos management interface can't be set to ipv4/6 address that is set by docker daemon on a linux interface. This forces clab to do extra work for ceos, such as:

  1. when the node first gets created we memorize which ipv4/6 address docker allocated to it
  2. we then stop the ceos node and generate a ceos config from a template knowing which IP addresses we need to put in there
  3. then we start the stopped ceos node and it boots with the correct IP addresses assigned

Now the next problem comes when we redeploy a lab with deploy -> destroy sequence. In that case the current logic of config persistency dictates that the ceos node will boot with a config that is already present in the clab-$labName folder for ceos node. But since docker assigns new addresses for a newly deployed lab, it might be that ceos node will get new management IP addresses allocated by the docker, and they will mismatch with the configuration that is saved in the config file.

It looks like have to implement additional logic here. If ceos nodes boot up and there is a config file in the lab directory present, we need to take this config file and replace the management interface configuration with the values that docker has assigned for this lab run, rather than blindly using the values that are there.

Considerations

Of course it is possible to do deploy --reconfigure and the nodes will not have any previous state, but that means that whatever the config was from the last lab deployment will be lost.

If the startup-config file is used, it has the most significant value and will be used always.

networkop commented 3 years ago

why would you not simply copy the file after ceos node is started? so intead of start -> stop -> start do start -> copy?

hellt commented 3 years ago

will ceos immediately apply the changes as I do them in startup-config file? Or do I also need to trigger the config reload? I think instead of a copy I can also do docker exec ... Cli <config ipv4/6>

networkop commented 3 years ago

I think you overestimate how fast ceos boots 😄 , if you place this file during the postDeploy action, ceos won't have time to get to the config parsing stage. If you don't want to rely on timers, you can place a bash script in /mnt/flash/rc.eos and make it wait for startup-config (or any other "sentinel" file) to be found before continuing to boot. The rc.eos is a special file that's guaranteed to run before the startup-config is processed. I used it previously to mount the startup config inside veos

hellt commented 3 years ago

this has been solved in #593 The new approach eliminates the troubles with ceos not being able to use the docker assigned IP in the following way:

  1. when ceos node first starts we generate a basic config from the ceos template without even configuring Ma0 IP address
  2. the IP address will be configured by scrapligo using docker exec connection in the postdeploy stage.
  3. this means that the ceos containers first starts, then containerlab w/scrapligo constantly tries to open CLI connection to it over docker exec PTY and once ceos is ready it configures the management address with the IPs we know docker assigned to it
  4. this means that it will work all the time regardless if a user has false IP addresses in startup config or not having them at all, it will always be configured correctly