Proposal to change default loopback and router_id address pools

[ssasso]

Right now, the default addressing for loopbacks and router_id are:

loopback:
  ipv4: 10.0.0.0/24
router_id:
  ipv4: 10.0.0.0/24
  prefix: 32

Since it seems that all the containerlab containers based on vrnetlab (https://containerlab.dev/manual/vrnetlab/) use 10.0.0.0/24 as internal subnet, this will cause some problems to people not reading the "caveats" documentation (i.e., https://netlab.tools/caveats/#juniper-vmx-in-containerlab).
Additionally, having to manually set a new pool every time a new lab config is created is error prone and annoying ;)

For that reason I propose to change the default loopback/router_id addressing schema to:

loopback:
  ipv4: 10.255.0.0/24
router_id:
  ipv4: 10.255.0.0/24
  prefix: 32
vrf_loopback:
  ipv4: 10.255.1.0/24
  prefix: 32

(changed also the vrf_loopback pool for consistency)

[ipspace]

Well, I love using 10.0.0.0/24 for loopbacks -- that results in the shortest possible addresses if one tries to stay within the RFC 1925 address range. Also, why should we "penalize" everyone else just because someone else (also) "squatted" on that prefix.

We could add clab.vrnetlab flag to device data and then test the potential address pool overlap in providers/clab.py (probably in augment_node_data).

[jbemmel]

It's not "all" the containerlab based vrnet VMs, it's only Juniper vMX. Nokia SR OS VMs work fine (for example)

I would suggest to implement a quirk for juniper devices (in devices/junos.py device_quirks), which warns about the overlap (errors out)

(I agree it's annoying, but my solution is to never use Junos devices... ;)

[ssasso]

@jbemmel are you sure?

I see: https://github.com/hellt/vrnetlab/blob/b254006f2b8bb4d5ddea5e2d699f266e430750a4/sros/docker/launch.py#L1003

[jbemmel]

Good find, but that's a qemu 'user' mode networking device (see https://wiki.qemu.org/Documentation/Networking#How_to_create_a_network_backend.3F) on a line card VM - which only gets instantiated for 'distributed' configurations, and isn't visible outside the container (or even inside - I cannot find it)

The default is 10.0.2.0/24, I can propose to remove the 10.0.0.0/24 just to avoid confusion - but I have never had issues with overlap

[ssasso]

I guess on SR OS by default management interface is on a separate vrf... Also in Juniper vMX and vSRX with vrnetlab it's on a dedicated management VRF, but IMHO it leads to user confusion.

[jbemmel]

Looks like it: https://github.com/hellt/vrnetlab/blob/b254006f2b8bb4d5ddea5e2d699f266e430750a4/vmx/docker/launch.py#L204

[ssasso]

that was a PR I did, in fact ;)
(both for vMX and vSRX)

[jbemmel]

FYI - I submitted a PR to remove the reference to 10.0.0.0/24: hellt/vrnetlab#123

I think the same might apply for vmx