Unknown why mlag peerlink is not used

[infra13]

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?

config

• leaf01(leaf02): Cumulus version 5.4.0

nv set system hostname leaf01(leaf02 is leaf02)
nv set interface eth0 ip address 192.168.255.1/24(leaf02 is 192.168.255.2/24)
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 192.168.255.2 vrf mgmt(leaf02 is 192.168.255.1)
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]        192.168.255.2          192.168.255.2
backup-active   True
backup-reason
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.

[epulvino]

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.