原文链接https://mellowd.co.uk/ccie/?tag=mstp


LET’S TAKE A LOOK AT SOME BPDUS

NOVEMBER 25, 2012 2 COMMENTS


Due to the limitations of my kit, I can’t test EVERYTHING I would like to. I need a spare ME3400 for that which I don’t have.

I’ll be using the following topology throughout this discussion:

All lines are in fact 2 links between each switch. What is a router doing there I hear you ask? Well there is a method to the madness here. All will be revealed!

I have a laptop connected to SW1 and spanned a port. This is to get some wireshark captures to see actual frames. This source will change throughout the blog in order to get specific frames.

SW1#sh run | begin monitor
monitor session 1 source interface Fa1/0/23
monitor session 1 destination interface Fa1/0/14 encapsulation replicate

I’ve turned off CDP, DTP, and VTP as I don’t want any noisy frames. I’m capturing this in Linux as my Windows driver is stripping off the vlan tag!

I’ve created 4 vlans: 10, 20, 30, 40.

Default spanning tree

Let’s keep the STP mode to the default. I’ve configured a bridge priority of 4096 on SW1.

Let’s take a look at the spanning-tree for vlan 10 on SW1:

SW1#sh span vlan 10 | include protocol
  Spanning tree enabled protocol ieee

The spanning tree enabled says protocol ieee. ieee what exactly? ieee 802.1d-1998 is the standard STP. ieee 802.1d-2004 is the standard RSTP. I guess we can assume that this is 802.1d-1998, but I don’t like to assume anything. Let’s take a look at bpdus sent from SW1 to SW2:

I can see 5 BPDUs sent from SW1 to SW2. Let’s dig deeper into the first:

This is a pvst+ bpdu. Wireshark tells us this straight away, but you can also work it out from the destination MAC address. i.e. this is NOT an ieee BPDU. Note that my switch is currently sending 5 of these. Each one is vlan tagged with the vlan belonging to the bpdu. I have 4 vlans configured (10, 20, 30, 40) so I get a tagged bpdu with each, and a tagged bpdu with vlan 1.
What about the fifth?

Well this IS an ieee BPDU. So really when you are running standard spanning-tree on a Cisco 3560/3750, you’re really sending BPDUs for both ieee and pvst+. But why? Well this is to allow a non-Cisco device to also play ball. PVST+ is Cisco proprietary. We can test this by bridging two interface on my router. You didn’t think we were actually going to route on that device did you?

Once we’ve bridged the routers interfaces running to SW1 and SW2, let’s take a look at the bpdu’s received on SW1 from R1. For this task I’ve changed the root bridge to R1.

The router {7200 running 12.4(15)T17} is only sending out ieee 802.1-1998 bpdus. These are untagged. SW1 shows that the link going off to R1 is the root.

Let’s add a subinterface on R1 tagged with vlan 10, and bridge that to see what happens. This is where things get interesting.
I now see 3 bpdus per cycle:

I see an untagged ieee bpdu. one tagged pvst+ frame for vlan 10, and finally one untagged pvst+ frame for vlan 1. Also to note is that the router does NOT add the vlan id value to it’s priority. Recall that if a switch is the root for vlan 20, and you set the priority to 4096, it actually adds 20 to 4096 to come up with a value of 4116.

SW1#sh span vlan 20 | include Root
  Root ID    Priority    4116

If we check the current root for vlan 10, we can see the priority is a flat 4096:

SW1#sh span vlan 10 | include Root
  Root ID    Priority    4096
Fa1/0/1             Root FWD 19        128.3    P2p

This means if you are running STP between a few routers and switches, and all their priorities all the same, then the routers will have lower priority and hence will become your root bridges. That is probably not what you want.

Rapid PVST+

Let’s change the mode to rapid-pvst on all switches. I’ve changed the priority of SW1 to zero. This time I see 6 bpdus sent from SW1 to SW2 per cycle. 5 tagged Rapid-PVST+ bpdus, 1 per vlan. This time I get a tagged rapid-pvst+ frame for vlan1.

I also have an untagged ieee frame. However this is ieee-802.1d-2004. You can see this from the protocol identifier version:

What about our router? Let’s take a look at the bpdus sent from SW1 to R1. SW1 is still sending 6 bpdus per cycle, but take a look at the difference for the bpdu sent for vlan 10 and vlan 20.
vlan 10

vlan 20

The bpdu sent to vlan 10 is using regular pvst+, while the bpdu sent to vlan 20 is rapid-pvst+
R1 has been sending regular pvst+ bpdus to SW1. SW1 recognises this and so knows the neighbour only supports that mode. I have not bridged vlan 20 on the router yet and so SW1 continues to send out rapid-pvst+ bpdus with that tag. The untagged ieee bpdu send from SW1 is also using the non-rapid bpdu.

You can see SW1 knows the device on port fa1/0/1 is a regular STP peer:

SW1#sh span vlan 10 | include Fa1/0/1
Fa1/0/1             Desg FWD 19        128.3    P2p Peer(STP)

Multiple Spanning Tree

Multiple spanning tree is quite different. First, it’s an ieee standard – 802.1s – It also uses ieee rapid-stp internally. Only a single BPDU is sent out per cycle. This bpdu is untagged and it also contains M record to show the name, revision, and a digest of the vlan-to-instance mapping. This allows the switches to determine whether or not they are part of the same MSTP region.

Please excuse the change of font, I had to open the capture on my Windows box in order to get the entire frame in a single shot.

Just to note, all bpdus sent to R1 are now sent as regular PVST+ tagged and ieee 802.1d-1998 format.

Conclusions

So why exactly does this all matter? It’s important to know which frames are tagged and which are not, especially if you’re going to be providing some kind of layer 2 service over your network. This becomes even more important if you are matching different customer’s traffic via vlan tag and not via an actual separate port. Another example would be if you were providing a selective QinQ service in which a single port can map different vlans to different S-vlan tags. Untagged traffic will not play nicely with this.

I’ll leave that discussion for another day though otherwise this post will never get finished. I do not have any handy kit on me to do selective QinQ, but I do have regular QinQ and EoMPLS (VLL/Pseudowire) which will be the basis to revisit this port in the future sometime.