Description

After removing the master switch in a virtual-chassis, the spanning-tree bridge-ID is not updated and keeps using the previous ID based in the old member mac address.

Symptoms

FPC0: 
Standalone root ID: 88:28:fb:63:de:03
FPC1
Standalone root ID: 88:28:fb:64:ba:03 
FPC2
Standalone root ID: 88:28:fb:63:e3:03 

(FPC0=Master|FPC1=backup|FPC2=LC) and the root-bridge is 4096.88:28:fb:63:de:03 

After removing FPC0, the root-bridge didn't change:

root@c06-36> show virtual-chassis status 
Nov 14 18:03:05

Preprovisioned Virtual Chassis
Virtual Chassis ID: 7b16.7d93.87c6
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
1 (FPC 1)  Prsnt    TC3122310748 ex4600-40f     129   Master*      N  VC   2  vcp-255/0/26
2 (FPC 2)  Prsnt    TC3122310106 ex4600-40f       0   Linecard     N  VC   1  vcp-255/0/26

{master:1}
root@c06-36> show spanning-tree bridge 
Nov 14 18:03:49
STP bridge parameters 
Routing instance name               : GLOBAL
Context ID                          : 0
Enabled protocol                    : MSTP

STP bridge parameters for CIST
  Root ID                           : 4096.88:28:fb:63:de:03
  CIST regional root                : 4096.88:28:fb:63:de:03
  CIST internal root cost           : 0
  Hello time                        : 2 seconds
  Maximum age                       : 20 seconds
  Forward delay                     : 15 seconds
  Number of topology changes        : 0
  Local parameters 
    Bridge ID                       : 4096.88:28:fb:63:de:03

STP bridge parameters for MSTI 1
  MSTI regional root                : 4097.88:28:fb:63:de:03
  Hello time                        : 2 seconds
  Maximum age                       : 20 seconds
  Forward delay                     : 15 seconds
  Number of topology changes        : 0
  Local parameters 
    Bridge ID                       : 4097.88:28:fb:63:de:03

 

Solution

This behavior is expected and it is seen because the value of stp_base_mac_address sysctl is used for STP bridge id. This is set to a mac address from master RE pool. This sysctl is stored in backed up kernel as well. 
Now when the master RE splits from VC, the new master RE will still hold stp_base_mac_address sysct set to older value. It takes few mins for chassisd to update the stp_base_mac_address to the mac address belonging to the current vc pool. 
However within this time l2cpd comes up in new master RE and reads the old sysctl value.

This is a day-1 behaviour.

Workaround is to restart l2cpd once VC is split. 

>restart l2cpd-service all-members

l2cpd is responsible for 
- STP, MVRP, LLDP/DCBX, L2PT.

STP: Reconvergence will happen. [This is anyway supposed to happen in this PR case as well, as bridge mac will get changed]
MVRP: Dynamic vlans learnt using MVRP will get deleted and then relearnt.
LLDP/DCBX: In local box, LLDP/DCBX membership will get relearnt. However in Peer, there may not be an impact, as neighborship will expire only after TTL of 120 sec.
L2PT: No impact



 

Modification History

2024-01-18 : Article Created