Enhancement: mgmt/bridge gateway IP can be user defined instead of picking 1st available

[dharmbhai]

So this is an enhancement request where in we have a clab as follows

topology documentation: 2 spines and 2 leafs with 3 hosts and 2 Border Leafs at each DC. Two DCs and Interconnected with 2 x Border Gateway Router instances

name: dcs prefix: "" mgmt: network: oob-mgmt ipv4_subnet: 10.10.186.192/26 bridge: oob-mgmt topology: kinds: ceos: image: ceos startup-config: startup-config.cfg linux: image: ubuntu nodes: SDC-L-SVC-1203: kind: ceos mgmt_ipv4: 10.10.186.197

Now the oob-mgmt is already a custom defined bridge with IP 10.10.186.196 but containerlab once it completes its deployment, reassigns the oob-mgmt bridge to .193 (1st available IP on the subnet) However, in my scenario, .193, .194 and .195 are already assigned to the phy router serving this VLAN So Please allow some attribute whereby we can specify what IP the bridge gets

OR Even better, since its custom bridge, Please let containerlab not tinker with IP assignment at all (if possible) Let the responsibility of assigning IP lie with end user

[hellt]

Hey

Run this command to download the patched containerlab version

docker run --rm -v $(pwd):/workspace ghcr.io/deislabs/oras:v0.11.1 pull ttl.sh/clab27dec:1d

this will download containerlab binary, you would need to do chmod a+x containerlab to run it

Then in your topo file use this

mgmt:
  <your config with network/ipv4/bridge>
  ipv4-gw: <gw-ipv4-addr>

this patch is not released yet

[hellt]

@dharmbhai I have added the ability to use the defined gw addr

can you repull the image with the same command and test it? Now you should be able to skip the gw address definition in your topo file, and containerlab will use whatever is defined for the bridge interface

[hellt]

done in #736

[dharmbhai]

Hi @hellt

1) The feature works as requested and designed As an additional enhancement, can we please log INFO[0001] message showing what we used for ipv4-gw, end user provided ip or from Unix detected IP address for ipv4-gw. I think it will help in debugging. Please ignore if you think otherwise.

Right now, This is what is logged when we run deploy

INFO[0000] Containerlab v0.0.0 started INFO[0000] Parsing & checking topology file: test.clab.yml INFO[0000] Creating lab directory: /home/aristaps/clab/test/clab-test INFO[0000] Creating container: ACE-CUA-LEAF01 INFO[0001] Running postdeploy actions for Arista cEOS 'ACE-CUA-LEAF01' node INFO[1312] Adding containerlab host entries to /etc/hosts file INFO[1312] 🎉 New containerlab version 0.22.0 is available! Release notes: https://containerlab.srlinux.dev/rn/0.22/ Run 'containerlab version upgrade' to upgrade or go check other installation options at https://containerlab.srlinux.dev/install/ +---+--------------------------+--------------+----------------+------+---------+------------------+--------------+ | # | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address | +---+--------------------------+--------------+----------------+------+---------+------------------+--------------+ | 1 | clab-test-ACE-CUA-LEAF01 | 8314530c67ba | ceos:4.26.2.1F | ceos | running | 10.10.186.193/26 | N/A | +---+--------------------------+--------------+----------------+------+---------+------------------+--------------+

Q2) What would happen when a) user provided a custom ipv4-gw and had different on unix ? --> containerlab will set custom ipv4-gw (no issues) AND b) then does a destroy, will we keep the custom ipv4-gw or will we remember the original unix ipv4 set on the bridge ?

Ans 2: It would retain the ip assigned via containerlab. There is no going back to original ip assigned to bridge.

[hellt]

Hi

user provided a custom ipv4-gw and had different on unix ?

the provided via topology file value will be used

will we keep the custom ipv4-gw or will we remember the original unix ipv4 set on the bridge ?

the value set initially during the deploy will stay