STP-2-DISPUTE_DETECTED

[abimadaro4462]

Hello,

I have two Nexus switches in a lab environment with a vPC configured, the down stream is connected to another switch (vPC) and the up stream is connected to firewalls working in active-standby mode with OSPF configured with vPC peer switches.

The topology looks like the below;

The configuration of vPC on both switches is as the below;

vpc domain 10
peer-switch
peer-keepalive destination 10.10.10.2 source 10.10.10.1 vrf vpcvrf
delay restore 60
peer-gateway
layer3 peer-router
auto-recovery
ip arp synchronize

interface port-channel1
vpc peer-link

interface port-channel2
vpc 1

Spanning tree configuration on both switches;

spanning-tree vlan 1,30,40 priority 24576
spanning-tree vlan 2-29,31-39,41-3967 priority 0
interface port-channel1
spanning-tree port type network

The issue is;

I'm getting this syslog message "STP-2-DISPUTE_DETECTED" when I'm reloading one of the vPC peers to figure out the behavior of the vPC in this case, and the behavior was receiving the mentioned syslog  message and a traffic disruption occur while forming the vPC with the peer switch.

Could you please advice if the configuration is correct? Any enhancement needs to be implemented? Is the topology correct?

Regards,

[Georg Pauwen]

Hello,

the official explanation is below. What is the output of:

show spanning-tree inconsistentports

%STP-2-DISPUTE_DETECTED: Dispute detected on port [chars] on [chars]. The spanning tree has detected a Dispute on this interface. The BPDU received from the peer is Inferior with designated role and state as learning and/or forwarding. Since this condition could be caused by an unidirectional link failure, the interface is put into blocking state and marked as disputed in order to prevent possible loops from being created.

Recommended Action: Issue the show spanning-tree inconsistentports command to review the list of interfaces with Dispute. Dispute is caused if the peer in not receiving the Superior BPDUs sent by this interface. That is why the peer continues to send its own Inferior BPDUs. Determine why devices connected to the listed ports are not receiving BPDUs. One reason could be a failure in the cable: if the link has a failure that makes it unidirectional (you can not transmit but you can receive) it should be replaced with a proper cable.

[abimadaro4462]

Hello,
Thanks for your reply, I came across this answer before, but since I'm in a lab environment I have nothing to do with cables and similar physical stuffs.
I'm trying to figure out if it's related to misconfiguration.

[paul driver]

Hello

Are you getting this error message when you've reloaded one of the switches or are you getting it when both witches are running - what port(s) are in dispute?

From Cisco CCO
%STP-2-DISPUTE_DETECTED:Dispute detected on port [chars] on [chars].The spanning tree has detected a Dispute on this interface. The BPDU received from  the peer is Inferior with designated role and state as     learning and/or forwarding. Since this  condition could be caused by an     unidirectional link failure, the interface is put into blocking state  and marked as disputed in order to prevent possible loops from being created.

Possible faulty cabling, native vlan mismatch?
Why do the Nxos switch with differing STP Bridge priority's why not have the cores the STP root for all vlans?
spanning-tree vlan 1 -4094 priority 0

Also i dont see you pruning off the vpc keep-alive vlan on the VPC peer Port-Channel trunk, as this keep-alive vlan should not traverse the peer link trunk or any trunk interconnect 

int port-channel 1
description VPC peer link
switchport trunk vlan allowed vlan except vlan X <-keepalive vlan>

Lastly make sure if you have a native vlan specified , its specified on both side of the trunks

[abimadaro4462]

Hello,
It happens during the boot of the reloaded vPC peer switch, it takes time to get stable. The ports that are in dispute are the one which connected to the downstream switch.
As for Keep-Alive VLAN, it's back to back connected, no VLAN is configured for this purpose.
Native VLAN is not yet configured actually.
I will try to configure the priority of STP the same for all VLANs on both vPC peers.

[Georg Pauwen]

Hello,

thanks for the additional information. So since it is a lab, the cabling is not the problem, apparently.

I assume the VPC switches are the root switches ?? Since the issue occurs on the ports to the downstream(non-VPC) switches, you might want to configure 'spanning-tree pseudo-information' on both VPC member switches.

VPC_S1(config)# spanning-tree pseudo-information

VPC_S1(config-pseudo)# vlan vlan-range designated priority 8192

VPC_S1(config-pseudo)# vlan vlan-range root priority 4096

VPC_S2(config)# spanning-tree pseudo-information

VPC_S2(config-pseudo)# vlan vlan-range designated priority 4096

VPC_S2(config-pseudo)# vlan vlan-range root priority 8192

[abimadaro4462]

Hello,
Sorry for late response, was busy with another issue.
I didn't yet read about this option, but the down stream switch is already configured in a vPC.

[paul driver]

Hello

---

@abimadaro4462 wrote:
Hello,
It happens during the boot of the reloaded vPC peer switch, it takes time to get stable. The ports that are in dispute are the one which connected to the downstream switch.

---

Possibley sounds like this is part of the peer switch/link coming back online and retaking the stp root role with synchronization which will temporary block all its non edge ports until the synchronization completes.

Can you confirm what stp port type is applied to the downsteam switch?

[abimadaro4462]

Hello,
Sorry for late response, you know it sounds that this might be the issue, the downstream ports are on default spanning tree configuration I didn't do any changes.

[n-kirillov]

Hi Abimadaro!

When you use vPC, the device use for switches the same special constructed STP BPDU MAC-address for forming STP adjacency (vPC domain appears as one device for connected STP Peers)

Then your reboot device, the STP adjacency reestablished, may be a MAC-addres of single device which not reloaded changed to normal.

May be this caused this error. I would try using the ethanalyzer.

Forming BPDU for vPC domain described in nice document -

https://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/211494-Use-of-Source-MAC-Address-Field-in-Spann.html