An EX3400 VC (virtual chassis) is acting as a Layer2 device in the access layer and is connected to the distribution layer consisting through an AE LAG. Distribution layer is making use of MC-LAG. Spanning tree is configured on the links between the distribution MC-LAG peers and the access VC. The EX3400 VC is managed in-band only, through an IRB interface, this being the only Layer3 configured interface on the device.

The in-band management interface is flapping periodically (every second) and the following logs are continuously seen on the device:

Jan 21 10:30:57 switch mib2d[17019]: SNMP_TRAP_LINK_DOWN: ifIndex 100, ifAdminStatus up(1), ifOperStatus down(2), ifName irb.10

Jan 21 10:30:57 switch mib2d[17019]: SNMP_TRAP_LINK_UP: ifIndex 100, ifAdminStatus up(1), ifOperStatus up(1), ifName irb.10

Jan 21 10:30:58 switch mib2d[17019]: SNMP_TRAP_LINK_DOWN: ifIndex 100, ifAdminStatus up(1), ifOperStatus down(2), ifName irb.10

Jan 21 10:30:59 switch mib2d[17019]: SNMP_TRAP_LINK_UP: ifIndex 100, ifAdminStatus up(1), ifOperStatus up(1), ifName irb.10

On the VC setup, the underlying interface for irb is an aggregate, which is part of the vlan used for in-band management - ie. ae0, vlan 10 and irb.10. Two physical interfaces, ie xe-0/0/1 and xe-1/0/1, are part of ae0 and ae0 has 2 peers, connected in MC-LAG.

ie

xe-0/0/1 is connected to MC-LAG Peer1

xe-1/0/1 is connected to MC-LAG Peer2

In this case, ae0 will send bpdu packets through one interface and it is sending packets through xe-0/0/1 which is connected to Peer1. So, Peer1 is receiving the BPDUs and Peer2 is not receiving the BPDUs. Since Peer2 is not receiving the BPDUs it is considering itself as root bridge and it is sending proposal to VC. Now that VC has received inferior BPDU and it knows that there is some better info available for root bridge it is moving to BLK DESG state. As Peer1 is receiving BPDUs from ae0, it sends agreement BPDUs to ae0 and ae0 moves to FWD DESG state. And again Peer2, since it has not received BPDUs from ae0, it sends proposal to ae0 and ae0 moves to BLK DESG state and this goes on and on. Hence irb flaps are seen.

This behaviour is expected in this type of environment/topology.

a) In case of MC-LAG, STP is not required to prevent loop.

To avoid this flap situation, you can disable RSTP on ae0 and also on the MC-LAG peers' connecting interface - "set protocol rstp interface intf-ID disable"

b) Configure MC-LAG peers with the same RSTP system ID and bridge priority

For more information refer following document to use STP with MC-LAG and also refer to best practices section.

https://supportportal.juniper.net/s/article/EX-QFX-Troubleshooting-for-MC-LAG?language=en_US

Best Practices

https://www.juniper.net/documentation/us/en/software/junos/mc-lag/topics/concept/best-practices-usage-notes.html