Posted on September 1, 2020 7:56 am
 |  Asked by Nitesh Arbale
 |  132 views
RESOLVED
0
0
Print Friendly, PDF & Email

I have formed vPC over Nexus-9K and there is one arista downstream switch connected to vPC members like below. Port-channel between arista and vpc are in trunk mode and lacp is set to active-active on both (vPC & downstream SW) .

I have created vlan 20 on all 3 switches. But i can see two root bridge for vlan 20. One is CORE-NX-S1 & another is downstream arista sw. How is this possible.

Even if priority is same, only one should be root bridge comparing MAC address.

Also I tried disabling MST but it still appears.

But also i have enabled rstp mode in arista. Is it like they are not receiving each other BPDU’s which end up electing themselves as root bridges?

 

ACC-S1(config)#no spanning-tree mode mst

ACC-S1(config)#no spanning-tree vlan 20 root

ACC-S1(config)#sh spanning-tree vlan 20
Spanning tree instance for vlan 20
MST0
Spanning tree enabled protocol rstp
Root ID Priority 32768
Address 5000.00af.b20e
This bridge is the root

Bridge ID Priority 32768 (priority 32768 sys-id-ext 0)
Address 5000.00af.b20e
Hello Time 2.000 sec Max Age 20 sec Forward Delay 15 sec

Interface Role State Cost Prio.Nbr Type
—————- ———- ———- ——— ——– ——————–
Et11 designated discarding 2000 128.11 P2p
Po20 designated forwarding 1999 128.100 P2p

 

ACC-S1(config)#sh run | b Ethernet7
interface Ethernet7
description CORE-NX –Po20
switchport mode trunk
channel-group 20 mode active
!
interface Ethernet8
description CORE-NX –Po20
switchport mode trunk
channel-group 20 mode active
!

 

ACC-S1(config)#sh run | b Port-Channel20
interface Port-Channel20
switchport mode trunk
!

 

 

CORE-NX-S1# sh spanning-tree

VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 32768
Address 5000.00af.b20e
Cost 1
Port 4115 (port-channel20)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5005.0000.1b08
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Po1 Desg FWD 3 128.4096 (vPC peer-link) Network P2p
Po20 Root FWD 1 128.4115 (vPC) P2p
Eth1/1 Desg FWD 4 128.1 P2p
Eth1/4 Desg FWD 4 128.4 P2p
Eth1/5 Desg FWD 4 128.5 P2p
Eth1/6 Desg FWD 4 128.6 P2p
Eth1/8 Desg FWD 4 128.8 P2p
Eth1/9 Desg FWD 4 128.9 P2p
Eth1/10 Desg FWD 4 128.10 P2p
Eth1/11 Desg FWD 4 128.11 P2p
Eth1/12 Desg FWD 4 128.12 P2p
Eth1/13 Desg FWD 4 128.13 P2p
Eth1/14 Desg FWD 4 128.14 P2p
Eth1/15 Desg FWD 4 128.15 P2p
Eth1/16 Desg FWD 4 128.16 P2p
Eth1/17 Desg FWD 4 128.17 P2p

 

 

VLAN0020
Spanning tree enabled protocol rstp
Root ID Priority 32788
Address 5005.0000.1b08
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32788 (priority 32768 sys-id-ext 20)
Address 5005.0000.1b08
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Po1 Desg FWD 3 128.4096 (vPC peer-link) Network P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p

CORE-NX-S1#

 

 

CORE-NX-S1# sh run (unwanted output omitted)

vlan 1,20

vrf context management
vpc domain 1
role priority 10
peer-keepalive destination 192.168.10.2 source 192.168.10.1

 

interface port-channel1
description peer-link (eth1/2-3)
switchport mode trunk
spanning-tree port type network
vpc peer-link

 

interface port-channel20
description ACC-S1 –Po20
switchport mode trunk
vpc 20

 

interface Ethernet1/2
description peer-link
switchport mode trunk
channel-group 1 mode active

 

interface Ethernet1/3
description peer-link
switchport mode trunk
channel-group 1 mode active

 

interface Ethernet1/7
description ACC-S1 –Po20
switchport mode trunk
channel-group 20 mode active

 

 

CORE-NX-S2# sh spanning-tree vlan 20

VLAN0020
Spanning tree enabled protocol rstp
Root ID Priority 32788
Address 5005.0000.1b08
Cost 3
Port 4096 (port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32788 (priority 32768 sys-id-ext 20)
Address 5007.0000.1b08
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Po1 Root FWD 3 128.4096 (vPC peer-link) Network P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p

 

 

 

CORE-NX-S2# sh vpc brief
Legend:
(*) – local vPC is down, forwarding via vPC peer-link

vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 1
Peer Gateway : Disabled
Dual-active excluded VLANs : –
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled

vPC Peer-link status
———————————————————————
id Port Status Active vlans
— —- —— ————————————————-
1 Po1 up 1,20

vPC status
—————————————————————————-
Id Port Status Consistency Reason Active vlans
— ———— —— ———– —— —————
20 Po20 up success success 1,20

 

Is there anything i need to add on arista ?

 

vlan20_root-bridge.jpegtopology vPC.jpegvpc.jpeg

 

Any suggestion would be appreciated. Thankyou

Nick

0
Posted by Alexis Dacquay
Answered on September 1, 2020 11:09 am

Hi Nitesh,
That topology should work.
As you guessed, you should be careful about STP.
Sorry but the pictures you attached are very low resolution, can you provide an external link for a high-resolution image, or add them as attachment rather than embed them?

To disable STP, you should configure:
spanning-tree mode none
as opposed to "no spanning-tree mst", which would only remove mst settings.

However, instead of disabling STP altogether I would recommend matching the STP mode if possible.
Note that MSTP is by standard backward compatible with RSTP, so it should work.
There could be problem inter-operating with Per-VLAN RSTP, but not RSTP. It it was the case, check interop details under the EOS manual, Spanning-Tree, Overview, MSTP-Rapid PVST+ interoperation, which at time of writing is there: https://www.arista.com/en/um-eos/eos-section-26-2-spanning-tree-overview#ww1152193
Just in case, check the interop status..

show spanning-tree bridge detail

Your diagram shows MLAG on the Arista switches, you MUST have identical VLAN and STP configuration on both, because only one becomes the active STP. Check for the active one with:
show mlag details

Note that on the Cisco side, the "switchport mode trunk" isn't necessary on the physical Ethernet interfaces, only on the port-channel because it's a Layer2 config, and all the L2 config goes on the L2 port (the LAG), the Ethernet interfaces are only physical in this context.

Likewise for the Arista EOS side, you should remove the "switchport mode trunk" from the physical interfaces. It's not active anyway, but it would keep the configs clearer and easier to spot possible misconfigs. The config is on the Port-channel so it's fine.

I am not sure what is going on, as a simple temporary troubleshooting step, would you be OK to configure the port as access on VLAN20 (will be native untagged), just to check the basics?

Do you have any global STP configs that might not appear under the interfaces?

Can you share your whole configs and maybe a show-tech from both sides?

Regards,
Alexis

0
Answered on September 1, 2020 11:22 am

Hi Nitesh,

Thanks for reaching out.

From the output snippets, I could see that this is an expected behavior and not an issue when you are running Rapid-PVST on cisco and RSTP/MSTP on Arista.

Here even though priority is same for both Nexus and Arista,  Arista would be Root Bridge in MST0 or other Instances since Arista's MAC address is lower than Nexus.

For vlan 1, Arista is the root bridge on both Arista and cisco because it sends IEEE BPDU on vlan 1.

For rest of the VLANs,  SSTP BPDU's generated by Cisco doesn't get processed on Arista's side as Arista is not running RPVST mode.So Arista would neither transmit PVST BPDU's.That's the reason why cisco is seeing Arista as Root Bridge in Vlan20 and would see itself as Root Bridge in other Vlans except for vlan 1.

You can validate this by running RPVST on Arista.

Thanks,

Bhavana.

0
Posted by Stuart Dayer
Answered on September 1, 2020 1:15 pm

Hi Team,

A nice explanation with examples are available on the link below.

https://www.arista.com/assets/data/pdf/Whitepapers/STPInteroperabilitywithCisco.pdf

https://eos.arista.com/eos-4-15-0f/mstp-pvst-inter-operation/

Basically

PVST devices only communicate with MST devices on vlan 1, unless MST PSVT interoperability is configured. Details available on the link below:
https://eos.arista.com/pvst-bpdus-as-data-plane-for-mst/

Rapid PVST

To interact properly with the Common Spanning Tree (CST), IEEE BPDUs are sent untagged to the reserved multicast MAC address of 0180.c200.0000.
These BPDUs are generated and processed in VLAN 1 irrespective of the native VLAN configuration.

For non-native VLANs, BPDU traffic is sent tagged with a special multicast MAC address of 0100.0ccc.cccd using a Shared Spanning Tree Protocol (SSTP) BPDU.

For the native VLAN, BPDUs are sent untagged. However, they are destined to the same special multicast MAC address as non-native VLANs i.e. 0100.0ccc.cccd.

MSTP

IEEE BPDUs are destined to the reserved multicast MAC address of 0180.c200.0000 carrying the information about the MST Region and instances as an extension in the form of MRecords. Hence, a single BPDU is used for backward compatibility with RSTP as well as CST and MSTP convergence.

This results in a tunneling effect in regards to BPDUs sent to 0100.0ccc.cccd through the MST region. The SSTP BPDUs destined for 0100.0ccc.cccd by the PVST devices are not understood by the switch running MST, so they are flooded as regular multicast traffic. This allows Rapid PVST BPDUs to cross through an MST region and be received by another switch running Rapid PVST on the other side, while still maintaining the ability to interact with the CST of an MST environment via IEEE standard BPDUs.

What this effectively means is that in the mixed MST / PVST topology, the MST device is able to determine who the RB is for vlan 1 only, by interacting with the PVST devices, as they both communicate with the same type of BPDU, the IEEE BPDU. However, as the PVST devices send tagged non-native and untagged native vlans to a special multicast MAC address of 0100.0ccc.cccd, using Shared Spanning Tree Protocol (SSTP) BPDU's, a mac address that the MST device does not understand, these SSTP BPDUs are effectively tunnelled across the MST region. The MST device is not able to participate in the spanning tree calculation for these other vlans as it does not understand the SSTP BDUs and thus floods these as multicast traffic.

So what we end up with is MST being root bridge for vlan 1, if the MST device has the lowest BID, while the PVST devices calculate the root bridge for the other vlans based on BID etc.

A solution to this is configuring MSTP PVST Interoperability on the Arista MST device.

MSTP PVST Interoperability
This feature facilitates environments where multiple STP flavors are deployed. It allows MSTP and PVST to interact, i.e. PVST BPDUs are consumed and transmitted by MSTP at the border. This interaction involves bi-directional BPDU translation occurring at MSTP PVST border ports – outgoing CIST BPDU is extrapolated as PVST BPDUs across various VLANs and incoming PVST topology change BPDU is mapped onto corresponding MSTI based on incoming VLAN. This feature is disabled by default and can be enabled by explicitly configuring the following command:
Switch(config)#spanning-tree mst pvst border

Hope this helps.

Post your Answer

You must be logged in to post an answer.