xrv9k duplicated chassis macpool

[lpailhas]

Hey,

Since xvr9k are preinstalled during vrnetlab packaging, all xrv9k container based from this image have the same macpool used for Bundle interfaces and ipv6 link-local addresses associated to theses bundles. Probably other things are impacted.

This cause some issues, for exemple when two devices using the same bundle id between them, we have the same system ID, lag doesn't going up.

RP/0/RP0/CPU0:clab-confed#show lacp system-id
Tue Jul 23 16:59:18.735 UTC

Priority  MAC Address
--------  -----------------
  0x8000  00-14-f2-75-bb-20

RP/0/RP0/CPU0:clab-confed#admin
Tue Jul 23 16:53:29.880 UTC
clab connected from 192.0.0.4 using ssh on sysadmin-vm:0_RP0

sysadmin-vm:0_RP0# show macpool
Tue Jul  23 16:53:35.781 UTC+00:00
Rack Serial           Rack Num  Mac Base           Mac Count   Selected    Allocated
---------------------------------------------------------------------------------------
45267CE1714           0         00:14:f2:75:bb:1b  2048        true        1024

RP/0/RP0/CPU0:clab-xxx#show lacp bundle-ether 2002
Tue Jul 23 17:11:22.859 UTC
State: a - Port is marked as Aggregable.
       s - Port is Synchronized with peer.
       c - Port is marked as Collecting.
       d - Port is marked as Distributing.
       A - Device is in Active mode.
       F - Device requests PDUs from the peer at fast rate.
       D - Port is using default values for partner information.
       E - Information about partner has expired.

Bundle-Ether2002

  Port          (rate)  State    Port ID       Key    System ID
  --------------------  -------- ------------- ------ ------------------------
Local
  Gi0/0/0/1        30s  a---A--- 0x8000,0x0002 0x07d2 0x8000,00-14-f2-75-bb-20
   Partner         30s  a---A--- 0x8000,0x0002 0x07d2 0x8000,00-14-f2-75-bb-20

  Port                  Receive    Period Selection  Mux       A Churn P Churn
  --------------------  ---------- ------ ---------- --------- ------- -------
Local
  Gi0/0/0/1             Current    Slow   Unselect   Detached  Churn   Churn

I didn't found way to edit this mac pool post install... Issue detected in version 7.11.2.

[hellt]

Hi @lpailhas yeah, this is likely cause by the install step

I think you can remove the make.install make include from the make file.

@kaelemc, maybe we should document this and make it configurable (make INSTALL=false)

[kaelemc]

@lpailhas You should be able to use the mac-address command under the interface configuration I believe?

Another work around is to attach the launch.py and/or vrnetlab.py for each node, which in theory should dynamically generate different MACs for each node on boot.

name: dev
topology:
  nodes:
    xrv:
      kind: cisco_xrv9k
      image: vrnetlab/vr-xrv9k:7.7.1
      binds:
        - /path/to/vrnetlab/common/vrnetlab.py:/vrnetlab.py
        - /path/to/vrnetlab/xrv9k/docker/launch.py:/launch.py

Remember that removing the install step and rebuilding the image will mean your node boot times will greatly increase (around 10-20 minutes or more).

@hellt Yes I agree, we should add and document this to make it easier for users..

[kaelemc]

Nevermind, I misinterpreted the issue. My suggested fixes will not work. On each launch each node interface gets a randomly generated MAC address regardless. It just looks like the macpool is burnt in on install.

[kaelemc]

@lpailhas I'm unable to test, but if you try in admin mode

activate advanced
conf t 
virtual-macaddr-range 

and then perform reload you should be able to change the macpool. Although this would not be persistent and whenever the topology is recreated you'd have to perform this.

It might just be easier to follow @hellt suggestion.

[lpailhas]

@kaelemc, I tried you command and execute reload of all locations but this didn't work, i still have the same macpool for chassis 0.

I'm sad of this, preinstall was a big improvement for me...

[kaelemc]

Yes, it is a shame. Unfortunately I think this is just something that the xrv9k hard codes during the install process.

[hellt]

it looks like in #239 the installation step becomes an option. The readme has been updated

thanks @kaelemc

@lpailhas you may want to give it a go