vPC between Nexus & arista

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

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.

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.