SpanTree Problem

[Mohamed Sobair]

Hi All,

I had faced a strange problem on one of our layer-2 switches.

Here is the case:

we have four layer-2 vlan switches in operation. all runs with spantree MST.

The MST configurations are similarly the same. but unfortionately one of our switches goes down along with customers.

After connectivity restored, I loged into the switch and here is the log output:

Apr 9 11:22:22: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer

vlan id 999 on GigabitEthernet0/1 VLAN62.

Apr 9 11:22:22: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet0/1 on MS

T00. Inconsistent local vlan.

what does this mean? and how I can resolve this issue next time?

Thanks,

Sobier

[Jon Marshall]

Hi Sobier

Check that the native vlan configured on both ends of the trunk are the same. From the cisco IOS error doc:

=============================================

%SPANTREE-2-RECV_PVID_ERR : Received BPDU with inconsistent peer vlan id [dec] on [chars] [chars].

Explanation The specified interface has received an SSTP BPDU that is tagged with a VLAN ID that does not match the VLAN ID on which the BPDU was received. This condition occurs when the native VLAN is not consistently configured on both ends of a 802.1Q trunk.

Recommended Action Verify that the configuration of the native VLAN ID is consistent on the interfaces on each end of the 802.1Q trunk connection. Once this inconsistency is corrected, spanning tree will automatically unblock the interfaces as appropriate.

=============================================

HTH

Jon

[Mohamed Sobair]

Hi Jon,

I didnt configure Native Vlan on both ends of interfaces that operates as a trunk. so the Native will be the default which is 1.

what could be else the cause of this?

Thanks,

[Jon Marshall]

Hi

Have you actually checked what the native vlan is for each end of the trunk ie.

sh interface trunk

Might be worht having a look. Apologies if you have already done it.

HTH

Jon

[Mohamed Sobair]

Hi,

No prblms..

I alredy done this , and it was as I said its native Vlan 1.

[Francois Tallet]

Looks weird... The message is a mix of PVST and MST. In MST, there is no PVID check because BPDUs are only sent untagged on the native vlan. Can you tell us a little bit more about the circumstance of the problem? Are you doing some tunneling, some vlan translation, PVST-simulation (interaction between MST and PVST -> a show spanning-tree detail would help there)? Where you changing the configuration? What did you do to "restore connectivity"? Can you recreate, etc...

Thanks and regards,

Francois

[Mohamed Sobair]

Hi Francois,

I am not doing tunneling.

Simply the setup as follows:

We have four 3560-G cisco switches, all Operating purely as layer-2 Vlans. MST is configured cause we are providing customers (ISP's layer-2 connectivity) and layer-3 config usually done between Customer & ISP.

We are configuring Multiple Vlans around 1200 Vlan ID, so we did configure it with MST protocol.

The Four Switches have identical MST regions and instances (Configuration). The problem occured suddenly and switch restored automatically. By the way this is not the first time, we noticed this issue on different intervals specifically this port on the switch from the VLan ID: 62. Could be from the customer side?

Awaiting feedback,

[Francois Tallet]

Hi Sobier,

MST only sends a single BPDU per port, untagged. This BPDU is an IEEE standard and does not include any vlan information. The problem you are getting can only occur by receiving a Cisco proprietary PVST BPDU that includes the ID of the instance that originated it (and if there is a mismatch between the vlan ID of origin and the vlan ID of reception, as some other already said, this PVID inconsistency error is generated).

A Cisco MST switch can send PVST BPDUs when doing what we call "PVST simulation". This mode is only entered when you are first receiving a PVST BPDU. So basically, I have the feeling that your problem comes down to some PVST BPDUs being injected somewhere in your network.

If this is a customer port, then the customer must address this, or you must avoid running STP with them (by configuring BPDU filter on the port -> of course, that requires that this customer is not redundantly connected, or you may need to tunnel their BPDUs throughout your core).

If the port is internal to your network and only connected with a point-to-point link to an MST port, then, considering that there is no tunneling configuration issue that could magically introduce a PVST BPDU in there, I would rather tend to think this is a bug. That would sound like a big one, and I've never heard of this problem before.

Regards,

Francois