Unknown why mlag peerlink is not used

I am experimenting with creating an MLAG using GNS3.
I would like to know about the specifications regarding MLAG.

I have set up the MLAG so that under normal conditions it is bonded on the downlink to each Debian server.
Since the configuration is L2Flat, the backup-ip uses the management IP of the vrf MGMT on eth0.

Suppose that one of the links from each leaf switch to the server is down and I have to go through peerlink.

Left: Normal, Right: Impaired

My assumption was that debian12.4-1 and debian12.4-1 could communicate without problems via peerlink, but they cannot.
With my current setup, it seems that no traffic is passing between peerlink.
What is leaking?


  • leaf01(leaf02): Cumulus version 5.4.0
nv set system hostname leaf01(leaf02 is leaf02)
nv set interface eth0 ip address is
nv set interface bond1 bond member swp1
nv set interface bond2 bond member swp2
nv set interface bond1 bond mlag id 1
nv set interface bond2 bond mlag id 2
nv set interface bond1-2 bridge domain br_default 
nv set interface peerlink bond member swp5-6
nv set interface bond1-2 bond mode static
nv set bridge domain br_default vlan 200,500
nv set bridge domain br_default untagged 100
nv set mlag mac-address 44:38:39:BE:EF:AA
nv set mlag backup vrf mgmt(leaf02 is
nv set mlag peer-ip linklocal
nv config apply

other show status

cumulus@leaf01:mgmt:~$ nv show mlag
                operational            applied
--------------  ---------------------  -----------------
enable                                 on
debug                                  off
init-delay                             180
mac-address     44:38:39:be:ef:aa      44:38:39:BE:EF:AA
peer-ip         fe80::e31:9dff:fea9:5  linklocal
priority        32768                  32768
backup-active   True
local-id        0c:07:85:52:00:05
local-role      primary
peer-alive      True
peer-id         0c:31:9d:a9:00:05
peer-interface  peerlink.4094
peer-priority   32768
peer-role       secondary

cumulus@leaf01:mgmt:~$ nv show mlag consistency-checker global
Parameter            LocalValue           PeerValue            Conflict  Summary
------------------…  ------------------…  ------------------…  --------  -------
anycast-ip           -                    -                    -
bridge-priority      32768                32768                -
bridge-stp           on                   on                   -
bridge-type          vlan-aware           vlan-aware           -
clag-pkg-version     1.6.0-cl5.4.0u4      1.6.0-cl5.4.0u4      -
clag-protocol-vers…  1.6.0                1.6.0                -
peer-ip              fe80::e31:9dff:fea…  fe80::e31:9dff:fea…  -
peerlink-master      br_default           NOT-SYNCED           -
peerlink-mtu         9216                 9216                 -
peerlink-native-vl…  100                  100                  -
peerlink-vlans       100, 200, 500        100, 200, 500        -
redirect2-enable     yes                  yes                  -
system-mac           44:38:39:be:ef:aa    44:38:39:be:ef:aa    -

Thank you for your cooperation.

I think it would be telling here to identify what ‘nv show interface’ says from each switch. Often when working in the virtual environment, line protocol errors when a link is down are not propagated through to both sides of the link like they would be in a normal physical environment. I would go to each side of the virtual link which is intended to be “down” and manually turn each side down as my first starting point.
Note: Using an active bonding protocol such as LACP would catch this sort of failure.