Question on PVST+ spanning tree packets

[john.j.tobin]

I am having a problem with spanning tree protocol. Our root bridge is a 6500 running IOS verison 12.1.

The 6500 is running spanning tree mode PVST+. According to the doumentation I have found the switch should only send spanning tree BPDUs untagged for the native vlan and tagged packets for all other VLANS.

The following is from the Best Practices for Catalyst 6500/6000 Series and Catalyst 4500/4000 Series Switches Running

Cisco IOS Software:

PVST+ interoperates with 802.1q mono spanning tree. PVST+ interoperates with 802.1q-compliant switches on common STP through 802.1q trunking. Common spanning tree is on VLAN 1 by default (the native VLAN). One common spanning tree BPDU is transmitted or received with the IEEE standard bridge-group MAC address (01-80-c2-00-00-00, protocol type 0x010c) across 802.1q links. Common spanning tree can be rooted in the PVST or mono spanning tree region.

The following packet breakdown shows the 6500 is sending a PVST+ tagged packet which is tagged for Vlan 1, which is the native VLAN. This is causing a 802.1s bridge to learn the incorrect root path cost.

There are two Mono Spanning tree swithes between the 6500 and the 802.1s bridge. I believe the 802.1s bridge is listening to the PVST+ tagged packet rather than the untagged BPDU which is also being send by the upstream switch.

Has anyone seen any problems like this or know if the 6500 should be sending the spanning tagged packet on the native VLAN?

Thanks,

John Tobin

----------------------------- Frame ID: 2 -----------------------------

Frame arrived at 06/23 09:14:21.005058, Frame Status: (Good Frame)

Data Link Control (DLC):

Destination: 01000CCCCCCD [No Vendor Name. - CCCCCD] [01000CCCCCCD]

Source: 000163D43CCA [National Datacomm Corporation - D43CCA] [NDC D43CCA]

EtherType: 0x8100 (IEEE 802.1Q - Virtual LAN)

IEEE 802.1Q - Virtual Bridged Local Area Networks (IEEE 802.1Q):

Priority/CFI/VID: 0x0001

000. .... .... .... Priority Level: 0

...0 .... .... .... Canonical Format

.... 0000 0000 0001 VLan Identifier: 1 - Default PVID

Length: 50 bytes

IEEE 802.2 - Logical Link Control (IEEE 802.2):

DSAP: 0xAA (SNAP)

SSAP: 0xAA (SNAP)

Control Byte 1: 0x03

[milan.kulik]

Hi John,

I made some experiments with STP on trunks a year ago (used Cat4000s running CatOS) and the conclusions were:

1) There is Cisco PVST+ BPDU (dest. address 01:00:0C:CC:CC:CD) sent for each VLAN. The BPDU frame is untagged for the native VLAN, tagged for all other VLANs. (If VLAN1 is not native one, the VLAN1 BPDU is tagged.)

2) There is another IEEE BPDU (dest. address 01:80:C2:00:00:00) sent for VLAN1. This BPDU frame is sent untagged even if VLAN1 is not the native one.

If VLAN 1 has been cleared from the trunk, these BPDUs are not sent.

So the Commomn STP is always VLAN1 (or nothing if VLAN1 cleared from the trunk).

Your problem if probably following:

Your two Mono Spanning tree switches are receiving both IEEE BPDU (untagged) and Cisco (tagged) VLAN1 BPDUs.

They do understand IEEE BPDUs (well known dest. address 01:80:C2:00:00:00), so they work with them and forward them to your 802.1s bridge with root path cost increased.

They do not understand Cisco PVST+ BPDUs (unknown dest. address 01:00:0C:CC:CC:CD) so they simply flood them to all ports (including port connecting your 802.1s switch).

Finally, the 802.1s switch receives both IEEE and Cisco BPDUs for VLAN1. It understands both, so it chooses the BPDU with best root path cost (i.e. Cisco BPDU not modified by the Mono Spanning tree switches).

So root path cost is incorrect finally, but STP still works (no loops).

The same situation should be in all other VLANs which are counting the root path cost from Cisco BPDUs only (i.e. ignoring the Mono Spanning tree switches).

I'm afraid there is no solution for this topology. You can't modify only Cisco BPDUs - if you change any STP configuration, the change modifies both Cisco and IEEE BPDUs.

I think that having a network running PVTS+ <-> Mono STP <-> RSTP is something not covered by Cisco STP modes compatibility.

Regards,

Milan

[john.j.tobin]

Hi Milan,

Thanks for responding to my question.

There is one thing I do not understand. The packet I included in the original question was tagged for vlan 1, which is the native vlan on that trunk. In your message and the documentation it says the native vlan would see both IEEE and PVST+ packets, and that they would be untagged on the native vlan. Any idea why the PVST+ packet is being tagged by the 6500?

Am I missing sonething?

John

[milan.kulik]

Hi John,

I can imagine only three reasons:

1) If VLAN1 is not native on the trunk, IEEE frame would not be tagged and PVST+ frame would be tagged - doublecheck the config

2) You mihgt have configured ALL frames be tagged on the trunk including the native VLAN (I can't remember the command now, but I know some IOSes enable this option) - check the config again, check if are there any untagged frames on the trunk

3) IOS bug

Regards,

Milan