Re: Spanning tree issues when adding VLANS

jbrit1969 · ‎07-13-2017

Hi,

I seem to be having an issue when adding VLANs to our core 4500-x stack and attached 3850 stack. Whenever I add I see these messages on the 4500's. In this case we added VLAN112 to the 4500 and then added it to the 3850

%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 112 on Port-channel2 VLAN1.
%SPANTREE-2-BLOCK_PVID_PEER: Blocking Port-channel2 on VLAN0112. Inconsistent peer vlan.
%SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel2 on VLAN0001. Inconsistent local vlan.
%SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel2 on VLAN0112. Port consistency restored.
%SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel2 on VLAN0001. Port consistency restored.

The 4500 config looks like this:

interface Port-channel2
description 3850a Uplink
switchport
switchport mode trunk

interface TenGigabitEthernet1/1/4
description 3850a Uplink
switchport mode trunk
channel-group 2 mode on
!
interface TenGigabitEthernet2/1/4
description 3850a Uplink
switchport mode trunk
channel-group 2 mode on
!

The 3850's Config:

interface Port-channel1
description 4500 Uplink (Po1)
switchport mode trunk

interface TenGigabitEthernet1/1/3
description 4500 Uplink
switchport mode trunk
auto qos trust
channel-group 1 mode on
service-policy input AutoQos-4.0-Trust-Cos-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
!
interface TenGigabitEthernet2/1/3
description 4500 Uplink
switchport mode trunk
auto qos trust
channel-group 1 mode on
service-policy input AutoQos-4.0-Trust-Cos-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
!
!

cofee · ‎07-13-2017

please check spanning tree calculation for both vlans on both switches and make sure there is no inconsistency there. You can also share the output from both switches.

Another thing would be to check the port channel. You have configured a static channel, it could be dangerous sometimes because it doesn't have built loop prevention mechanism like lacp or pagp. Make sure port Channel is up and have the right member ports. Spanning tree should be showing port channel to forward traffic and not the underlay physical ports in its calculation output.

jbrit1969 · ‎07-13-2017

Hi,

Here's the output from both switches:

On the 4500:

VLAN0001
 Spanning tree enabled protocol rstp
 Root ID Priority 8193
 Address 0008.e3ff.fc04
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

 Bridge ID Priority 8193 (priority 8192 sys-id-ext 1)
 Address 0008.e3ff.fc04
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Te1/1/12 Desg FWD 4 128.12 P2p
Te1/1/13 Desg FWD 4 128.13 P2p
Te1/2/7 Desg FWD 4 128.135 P2p
Po1 Desg FWD 2 128.2561 P2p
Po2 Desg FWD 1 128.2562 P2p
Po3 Desg FWD 1 128.2563 P2p
Po4 Desg FWD 4 128.2564 P2p
Po5 Desg FWD 4 128.2565 P2p

VLAN0112
 Spanning tree enabled protocol rstp
 Root ID Priority 8304
 Address 0008.e3ff.fc04
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 8304 (priority 8192 sys-id-ext 112)
 Address 0008.e3ff.fc04
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Te1/1/13 Desg FWD 4 128.13 P2p
Te2/2/3 Desg FWD 4 128.1411 P2p
Po1 Desg FWD 2 128.2561 P2p
Po2 Desg FWD 1 128.2562 P2p
Po3 Desg FWD 1 128.2563 P2p
Po4 Desg FWD 4 128.2564 P2p
Po5 Desg FWD 4 128.2565 P2p

On the 3850:

VLAN0001
 Spanning tree enabled protocol rstp
 Root ID Priority 8193
 Address 0008.e3ff.fc04
 Cost 1
 Port 2027 (Port-channel1)
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
 Address c07b.bc35.a600
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/33 Desg FWD 4 128.33 P2p Edge
Gi1/0/35 Desg FWD 19 128.35 P2p Edge
Gi1/0/38 Desg FWD 19 128.38 P2p Edge
Gi1/0/42 Desg FWD 4 128.42 P2p
Gi1/0/47 Desg FWD 100 128.47 Shr Edge
Gi2/0/30 Desg FWD 4 128.94 P2p Edge
Po1 Root FWD 1 128.2027 P2p
Po2 Desg FWD 3 128.2028 P2p Peer(STP)
Po3 Desg FWD 3 128.2029 P2p Peer(STP)
Po6 Desg FWD 3 128.2032 P2p Peer(STP)
Po7 Desg FWD 3 128.2033 P2p Peer(STP)
Po8 Desg FWD 3 128.2034 P2p
Po9 Desg FWD 3 128.2035 P2p

VLAN0112
 Spanning tree enabled protocol rstp
 Root ID Priority 8304
 Address 0008.e3ff.fc04
 Cost 1
 Port 2027 (Port-channel1)
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

 Bridge ID Priority 32880 (priority 32768 sys-id-ext 112)
 Address c07b.bc35.a600
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300 secI

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 1 128.2027 P2p

The port channel is up and does have the correct members.

netsysconsultant · ‎07-13-2017

hello,

if you have on one interface of the port channel a unidirectionnal link problem (the interface will appear up on both sides, but BPDUs messages will be received only one side of this interface), it might cause such issue.

Enable udld on both switches "udld enable" if you have a unidirectional link problem, udld will put the port down, and you will have error messages. There is no risk if you enable udld on other links, for udld to works, both switches must be configured

Please let me know if this help

cofee · ‎07-14-2017

I didn't see anything wrong in the spanning tree output that would cause the issue you are having and you configuration looks fine. Can you check port channel and its members for any crc and input errors? it might be something physical like a bad cable.

jbrit1969 · ‎07-14-2017

No errors are showing on the port channel or members.

Today, I had to create some additional VLANs and saw the same errors in the logs, but for one of the VLANS I forgot to do a 'No Shutdown' on the VLAN interface on 4500, after I added the VLAN to the 3850 I went back to the 4500 and did a No Shutdown on the VLAN interface, checked the logs and there was no error message.

So, eventhough I don't know why we see the error messages, I guess from now on we will leave the VLAN interface on the 4500 shutdown until the VLAN has been created on the 3850.

School Tech · ‎08-07-2017

Are you still seeing this error? We've got a bunch of the 385012x48's and keep seeing similar inconsistency errors on our core side, either on a 4500, 3750 or 3850. On the 3850 access switch side, we see our management vlan go down for about 10 seconds at the same time the core is logging the BPDU errors:

%LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to down
%LINK-3-UPDOWN: Interface Vlan254, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan254, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to up

I have a TAC case open and so far we've tried 3.7.5, 16.3.3, and 16.5.1a and we've seen it on all of them.

It looks like it's related to https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc26787/?referring_site=bugquickviewredir , which was publicly available last week, but is now locked down. Maybe it's a good sign that a resolution is coming soon.

Basically it's a bug that the ten gig SFP interfaces randomly disconnect and reconnect with no way to stop the issue. During that blip, our cores were seeing weird BPDU's and complaining.

Pretty frustrating...

~chris · ‎08-08-2017

Hi,

I'm having same issue with code 3.6.7 running von cat3650/cat3850 switches on customer site.

I can reproduce the issue in my lab.

We have already opened a SR for this, since this issue is not seen previous to 3.6.7.

TAC is investigating and in contact with the development.

regards

~chris

moose.357 · ‎08-23-2017

Hi,

I just went through this with TAC last week, it's a new bug in 3.6.7.

Software bug CSCvf61452

The workaround in my case was to add the same VLANs to the 3850 member switch, as whats configured on the STP root switch.

Hope this helps.

will · ‎05-23-2020

If all other answers are coming up short, verify that the native vlan for the port-channel, or trunk is defined on both sides of the switch trunk link. for example:

vlan 999
name native

and that the spanning tree versions; i.e. rapid-pvst is the same on both sides.