Closed 7oku closed 3 years ago
I can confirm omitting eth0 in the for loop works as expected.
int_calc ()
{
index=0
for i in $(ls -1v /sys/class/net/ | grep 'eth\|ens\|eno' | grep -v eth0); do
let index=index+1
done
MYINT=$index
}
I would consider eth0 to be always available and configured as a mgmt interface (like in cumulus linux as well), reachable through the docker net. So would there be any reason not ignoring it in the startup check?
Ah, I see. I think I know why this happens. Have a look at the entrypoint. This image accepts an optional integer argument telling it how many interfaces should it expect to be connected before doing ifreload -a
. See this example.
So I guess if you add an extra cmd: 2
field to the topology definition , it should work. Can you confirm?
This is why simply ignoring eth0
wouldn't work, because the default for that argument is 1
which means one extra interface.
I think I just need to update the topology definition.
Awesome, that alternative approach works, as long as you keep the integer in sync with the actual configured interfaces.
Would it be a good idea to have the loop in entrypoint.sh run over the /etc/network/interfaces
as well to determine the expected interfaces automatically?
Not a big deal, just trying to remove the manual intervention at a second place.
great! I think you could, potentially look into e/n/i but that would assume that they all are listed there. i.e. you can't define a subset because you're inevitable gonna miss some number of interfaces this way.
another option is to create a new kind
for host:ifreload
and, since clab knows exactly how many interfaces are expected to be connected, it can pass this number in the cmd
automatically. Should be a fairly small PR.
wdyt about either option?
in the first option you could turn it the other way saying each interface in e/n/i needs to be counted in the cmd argument, so if you miss one, it's gonna fail as well.
i'm new to containerlab (coming from CTD, looking for a docker approach and found your webpage) so i cannot estimate if a new kind in containerlab is worth it, however i just found there are already other linux kinds without the need for specifying the interface count explicitely. to me it seems that would be the best fit doing it the same way and go with option 2.
ok, so PR in containerlab is merged and two latest commits c8e000c and e6ab064 combine your suggestion with containerlab's metadata. So now the logic is as follows:
tested and it seems to be working. so I'll close the issue for now, feel free to re-open if you still see it.
Hi,
I'm trying to deploy the small sample lab with sw1 and h1 from https://github.com/srl-labs/containerlab/blob/master/lab-examples/cvx02/topo.clab.yml.
The host does not set the ip address at start.
After executing the entrypoint again, the ip address is set perfectly:
I'm not sure exactly what the issue is, but i assume entrypoint.sh waits for the amount of interfaces (one) which is fulfilled by eth0 already, so it is not waiting for eth1 to be connected before ifreload is triggered.