Arista MLAG vs unstable STP

Before reloading an MLAG peer switch to perform an upgrade/downgrade, one of the key check-ups is to make sure the STP is restartable. Otherwise, traffic loss is expected. 

bn303.08:17:13(s1)#sh spanning-tree instance detail | grep rest

   Stp agent restartable                      :            False

Oct 19 08:16:15 bn303.aristanetworks.com Stp: %SPANTREE-6-STABLE_CHANGE: Stp state is now not stable

Oct 19 08:17:06 bn303.aristanetworks.com Stp: %SPANTREE-6-STABLE_CHANGE: Stp state is now stable

To find out which ports causing this issue, by using CLI - sh spanning-tree topology status detail, to search most recently changed ports, like

bn303.08:22:51(s1)#sh spanning-tree topology status detail | more

Topology: Cist

  Mapped Vlans: 1,4080-4087

  Cpu:                  forwarding (1 changes, last 7:40:20 ago)

  Ethernet8/16/1:       forwarding (3 changes, last 0:23:10 ago) <<<

  PeerEthernet8/16/1:   forwarding (3 changes, last 0:23:10 ago) <<<

The reason of unstable STP is because, the MLAG switch keeps receiving its own (actually from the active MLAG peer) BPDU and can't form an agreement. The solution can be either, shutting down the port or put it as no-switching port. 

20+ sec traffic seen during Mlag peer reload

https://eos.arista.com/mlag-issu/

The reason of such long period loss is most likely caused by STP flap or the STP is not stable before system reload. Another symptom is the output of "show hardware counter drop". If you see high # of drop due to dropVoqInPortNotVlanMember, it is likely the STP issue. 

Use these 2 commands to verify STP status:

bn303.14:47:42(config)#show mlag issu warnings
Stp is not restartable. Topology changes will occur during the upgrade
process.

bn303.14:49:21(config)#show spanning-tree bridge det | more
Stp Detailed Status:
   Stp agent restartable         :        False
   MST-PVST interoperation       :     Disabled

One of the reasons of unstable STP is, this switch receives its own BPDU on one port. That happens if both mlag peers have 1 port connected to same switch then form a loop. Even the STP kicks in and put the port in "discarding" mode, but this bouncing back BPDU still causing the STP unstable. 

In this case, use command - "show spanning topology status" to find those looped interfaces. 

bn302.14:49:44(config)#show spanning-tree topology status | more
Topology: Cist
  Mapped Vlans: 1
  Ethernet12/32/1:      forwarding
  Ethernet14/32/1:      forwarding
  PeerEthernet12/32/1:  discarding <<<<<< check this peer port
  Port-Channel2000:     forwarding

bn303.15:32:02(config)#tcpdump ver interface et12/32/1
....
15:32:21.036169 28:99:3a:84:8d:68 > 01:80:c2:00:00:00, 802.3, length 105: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1s, Rapid STP, CIST Flags [Proposal, Learn, Forward, Agreement], length 102
port-role Designated, CIST root-id 2000.46:4c:a8:a5:11:40, CIST ext-pathcost 0
CIST regional-root-id 2000.46:4c:a8:a5:11:40, CIST port-id 8789,
message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
v3len 64, MCID Name , rev 0,
digest 64b4d42c08d6bff5b647fc0be11d4ebb, CIST int-root-pathcost 0,
CIST bridge-id 2000.46:4c:a8:a5:11:40, CIST remaining-hops 20