Ask the Expert: LAN Switching

ciscomoderator · ‎03-09-2012

With Matt Blanshard

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to ask your toughest layer 2 questions to two of the technical leaders of the San Jose LAN Switching team, Matt Blanshard. Learn more about Spanning Tree, VTP, Trunking, Resilient Ethernet Protocol, IGMP Snooping, Private VLANS, Q-in-Q Tunneling, QoS, various switching platforms including all desktop switches, Metro Ethernet switches, 4500 and 6500 switches, Blade Center switches, and Nexus 7000 switches.

Matt Blanshard began his Cisco career as an intern in 2007. He is now a technical leader at the Cisco Technical Assistance Center on the LAN Switching team. He holds a bachelor's degree from the University of Phoenix in computer science, and has CCNA certification.

Remember to use the rating system to let Matt know if you have received an adequate response.

Matt might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the discussion forum shortly after the event. This event lasts through March 23rd, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

johnnylingo · ‎03-09-2012

One of the dilemnas in switching right now is to use Rapid-PVST or MST as the Spanning-Tree Mode.

As we all know MST has the advantage of being an open standard, however Rapid-PVST requires less configuration.

What are other advantages / disadvantages of the two modes to consider?

Matthew Blanshard · ‎03-11-2012

Hello Johnny,

When it comes to a decision on using Rapid-PVST versus MST, there are a couple of things to consider. MST offers you several advantages, including the most advantageous one of being an IEEE standard that can work with multiple vendors. Another major advantage of using MST is scalability. MST scales out much better than Rapid-PVST. Rapid requires the sending out of BPDU's every 2 seconds on every trunk link for every vlan, while MST sends out only one BPDU on each trunk link irrespective of how many vlans are carried as long as the other connected switch is also running MST. If you look at the following document:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/overview.html#wp26366

You will see that with MST you can use up to 100,000 virtual ports (# of trunk ports * vlans carried) where as Rapid PVST is limited to 12,000. So on larger scaled out networks with a significant number of vlans MST is the way to go.

-Matt

dtmatola123 · ‎03-11-2012

I have to answer this question, please help me.

why trunk cannot be negotiated with both ends set to auto?

can you explain why? and how does it work,

also the no negotiate command, explain how does it disable dtp.

thank you for your answers.

Matthew Blanshard · ‎03-11-2012

Someone already beat me to this answer in the following thread.

https://supportforums.cisco.com/thread/2137092?tstart=0

-Matt

Peter Paluch · ‎03-12-2012

Hi Matt,

Nice to meet you here again! I hope you've been doing well.

I would like to continue the discussion about the PVST Simulation in Cisco's implementation of MSTP we've opened via e-mail but never had the opportunity to finish.

The primary point of the discussion was: under what exact circumstances the PVST Simulation Failure is declared? It is known that PVST_Inc(onsistent) ports appear in certain cases of MST/(R)PVST interoperation but the exact requirements to avoid these situations are not well documented.

I have had a discussion with Mr. Francois Tallet from Cisco, a really great and genuinely nice person, at Live! 2012 in London about this and from what he explained to me, I understand that the PVST Simulation will not declare an inconsistency if and only if one of these two alternative requirements are met:

Either the IST (= MSTI0) BPDU sent on a MST boundary port is superior to all (R)PVST BPDUs received on a MST boundary port
- This means that after the IST data is replicated to all (R)PVST BPDUs sent out the MST boundary port, the MST region becomes a root bridge for all VLANs in the (R)PVST region)
Or the IST BPDU sent on a MST boundary port is inferior to the (R)PVST BPDU for VLAN1 received on a MST port and at the same time, (R)PVST BPDUs for other VLANs received on a MST boundary port are identical or superior to the (R)PVST BDPU received for VLAN1
- This means that the root bridges for all VLANs are located in the PVST region, and even more, that the root bridges for VLANs 2-4094 (if existent) have numerically lower priorities than the root bridge for VLAN1

We had a limited time discussing this so there was no opportunity to go into gory details but I would like to ask you to review this and let me know if I got it correctly.

Thank you very much!

Best regards,

Peter

Matthew Blanshard · ‎03-12-2012

Hello Peter,

My understanding of MST matches what you have taken away from the conversation at Live! 2012 in London. If there's a mismatch between the vlans in the IST where the MSTP switch would be root for some vlans and not others then it will cause the simulation to fail. Either the MSTP switch must be root for all vlans or the pvst switches must be root for all vlans. Anything else will cause it to fail.

-Matt

Peter Paluch · ‎03-13-2012

Hello Matt,

Thank you for responding.

If there's a mismatch between the vlans in the IST where the MSTP switch  would be root for some vlans and not others then it will cause the  simulation to fail.

Umm... yes but you see, that is my point of contention: the "mismatch between the VLANs" is just a vague hint on the usual case in which the PVST Simulation declares an inconsistency, but it is not an exact enumeration of conditions to check for.

The IOS must obviously be doing a list of checks on received PVST BPDUs and if the BPDU fails the check then the PVST Simulation inconsistency is declared. However, that list is nowhere to be found or described. Compare it to, say, OSPF requirements to create an adjacency: you need the same area number, area type, netmask, same network, same authentication, same hello/dead intervals. It's very clear if you put it down this way. It would not be that clear if we just said - "the OSPF routers must be configured consistently". Sadly, this is exactly how the requirements for PVST Simulation are usually being publicly presented - in a form of vague recommendations, and it doesn't help at all when troubleshooting problems. My goal is to get a grasp of detailed, exhaustive, exact and authoritative list of conditions that have to be met to avoid PVST Simulation inconsistency.

To explain why I am not still completely satisfied: let us suppose that we want the PVST region to become the root bridge. I was aware of the requirement that if you want the PVST region to become the root then the PVST BPDUs must be superior to IST BPDUs but what I also thought was that these PVST BPDUs must be mutually identical. In other words, I thought that the PVST BPDUs for, say, VLAN 1, 2 and 3 (if there were only three VLANs) had to declare an identical Root Bridge ID. Note that with extended system ID, this requirement would be impossible to meet as each Root Bridge ID would be different, based on the embedded VLAN ID. That is what I also stated in many threads here on CSC because I simply didn't know better, and no one corrected me. Only after meeting Francois, he has explained to me that the situation is different: in reality, the Root Bridge IDs on different VLANs in the PVST region can differ but in that case, the priority of the root bridge in VLAN 1 must be higher than the priority of any other root bridge in other VLANs. That was something I totally didn't know and didn't expect - and I am still not certain if I got it right.

In the light of this, it is only natural to ask - is there yet something more I don't know about?

Best regards,

Peter

Matthew Blanshard · ‎03-13-2012

Hello Peter,

To answer your question I went digging into some engineering documents on how we have implemented MST/RSTP to be sure I gave you the most complete answer. Here's a summarization of what's in the document.

When an MST bridge receives a PVST+ BPDU on a port it sets the role to boundary and processes the Vlan 1 BPDU from the PVST+ cloud. Based off of the priority of that Vlan 1 BPDU it determines if the root will be the MST Switch via the IST, or out in the PVST+ cloud. If the port is set to designated then rootguard is enabled on the port.

Based off of this document I can conclude the following:

1) If the BPDU's received are inferior to the IST then the MST region becomes root and any superior BPDU received will cause rootguard to trip, blocking the port. If a vlan 1 superior BPDU is received then the root will be re-calculated.

2) If the BPDU's received are superior to the IST then the boundary port becomes the root port. Any non-vlan 1 inferior BPDU will cause the port to go into an inconsistent state and block the port.

Another way for it to fail is if the PVST+ switch does not allow vlan 1 on the port going to the MST switch. In this case since no vlan 1 BPDU is received on the MST boundary port the port will become designated and if any superior BPDU is received on any other vlan then it will trip rootguard.

Note that there is no mention of bridge-id here everything resolves around the priority of the BPDU's and whether they are inferior or superior. In all cases where I say inferior identical will also suffice as long as it's not a superior BPDU. You can have multiple different roots for the vlans in the PVST+ cloud as long as all vlans are superior to the IST on the MST switch.

These are all of the conditions listed in our engineering documents on how Cisco has implemented MST in our products, so I would consider this the complete list on conditions that can cause it to fail.

I hope this answers your question. If not please reply and I can clarify further.

-Matt

Peter Paluch · ‎03-14-2012

Hello Matt,

Thank you very much for putting so much effort into clarifying these issues! I am admittedly giving you a hard time But I may condense this later into a document posted somewhere here on CSC so I'd like to get it as precise as possible. Thanks for helping me out with this!

A couple of comments/questions.

If the port is set to designated then rootguard is enabled on the port.

I was not able to confirm this in the show spanning-tree interface detail output - no mention about activated RootGuard was displayed - but the guard may nevertheless be activated internally. Still, the only message logged by the switch is about PVST_Inc port, never about Root_Inc. But I agree, the RootGuard code may be reused in the PVST Simulation consistency checks.

2)  If the BPDU's received are superior to the IST then the boundary  port becomes the root port. Any non-vlan 1 inferior BPDU will cause the  port to go into an inconsistent state and block the port.

Ah, I see. According to my experiments, I would slightly rephrase the second statement: "Any non-VLAN 1 PVST+ BPDU that is inferior to the VLAN 1 PVST+ BPDU will cause the port to go into the PVST_Inc state and become blocked." The key difference here is clarifying to what shall the non-VLAN 1 BPDU be inferior to. Would you agree?

Note that there is no mention of bridge-id here everything resolves  around the priority of the BPDU's and whether they are inferior or  superior.

Hmmm... Yes, and surely, as the Root Bridge ID is the first element of the priority vector derived from a BPDU, difference in the Root Bridge ID immediately differentiates a superior BPDU from an inferior BPDU. But there is something unclear - if two PVST+ BPDUs arrived on a MST boundary port,

VLAN1 BPDU: RBID=1, RPC=100, SBID=1, SPID=1

VLAN2 BPDU: RBID=1, RPC=101, SBID=1, SPID=1

assuming that the IST BPDU is far inferior to VLAN1 BPDU (thereby making the PVST+ region a root bridge), would this combination of PVST+ BPDUs also cause a PVST Simulation Inconsistency? What would be the logic behind this? I can somewhat understand the logic that requires that if the PVST+ region is to be the root bridge, then the non-VLAN1 Root Bridge IDs must be equal or smaller than the VLAN1 Root Bridge - to make sure without storing any further state on the MST switch that the root bridges for those VLANs are also located in the PVST+ region. But what possible problem could arise if the VLAN2 BPDU was inferior to VLAN1 BPDU such as here? I cannot see any problem or inconsistency here: it's still clear that the root bridge for both VLANs is out there in the PVST+ region, and the role/state of the boundary port is nevertheless determined by the VLAN1 BPDUs only.

In all cases where I say inferior identical will also suffice as long as it's not a superior BPDU.

Now I believe you have yourself sub-consciously referred to the concept of the identical Root Bridge ID which I have been referring to all the time. How can two BPDUs, in any of the contexts we have referred to a pair of BPDUs here, be "identical", i.e. the same RBID, RPC, SBID, and SPID? That would definitely mean a looped BPDU, would it not?

Thank you very much for this ongoing discussion - I am definitely getting the details!

Best regards,

Peter

Matthew Blanshard · ‎03-14-2012

Hello Peter,

No issues at all with you giving me a hard time, I enjoy having a good discussion and the hard questions are the good ones

I was not able to confirm this in the show spanning-tree interface detail output - no mention about activated RootGuard was displayed - but the guard may nevertheless be activated internally. Still, the only message logged by the switch is about PVST_Inc port, never about Root_Inc. But I agree, the RootGuard code may be reused in the PVST Simulation consistency checks.

Yeah the output doesn't show up but it uses the rootguard functionality to perform this function. From what I have read of the 802.1s standard it controls the port state and so I am pretty sure we are bound to use their error message of inconsistant and not root inconsistant.

Ah, I see. According to my experiments, I would slightly rephrase the second statement: "Any non-VLAN 1 PVST+ BPDU that is inferior to the VLAN 1 PVST+ BPDU will cause the port to go into the PVST_Inc state and become blocked." The key difference here is clarifying to what shall the non-VLAN 1 BPDU be inferior to. Would you agree?

You are correct that you must not be inferior to the vlan 1 BPDU. I tested this in my lab and the results match up exactly. If I do this configuration it does not work:

c6504e#sh run | i spann

spanning-tree mode pvst

spanning-tree extend system-id

spanning-tree vlan 1-4094 priority 4096

This results in a pvst inconsistency since the vlan 100 bpdu's are inferior to the vlan 1 bpdu's. If I change the configuration to this then it works:

c6504e#sh run | i spann

spanning-tree mode pvst

spanning-tree extend system-id

spanning-tree vlan 1 priority 4096

spanning-tree vlan 2-4094 priority 0

Also to further support the multiple root bridge theory here's what I currently have setup in my lab:

6504 po1 -- po1 6506 - po100 -- po100 c5k

I have 6506 setup as the root for vlan 1 (priority 4096), and I have the c5k setup as root for the rest of the vlans (priority 0). This works just fine with no inconsistency. As long as the BPDU's are superior to the vlan 1 bpdu then it all works.

Hmmm... Yes, and surely, as the Root Bridge ID is the first element of the priority vector derived from a BPDU, difference in the Root Bridge ID immediately differentiates a superior BPDU from an inferior BPDU. But there is something unclear - if two PVST+ BPDUs arrived on a MST boundary port,

VLAN1 BPDU: RBID=1, RPC=100, SBID=1, SPID=1

VLAN2 BPDU: RBID=1, RPC=101, SBID=1, SPID=1

assuming that the IST BPDU is far inferior to VLAN1 BPDU (thereby making the PVST+ region a root bridge), would this combination of PVST+ BPDUs also cause a PVST Simulation Inconsistency? What would be the logic behind this? I can somewhat understand the logic that requires that if the PVST+ region is to be the root bridge, then the non-VLAN1 Root Bridge IDs must be equal or smaller than the VLAN1 Root Bridge - to make sure without storing any further state on the MST switch that the root bridges for those VLANs are also located in the PVST+ region. But what possible problem could arise if the VLAN2 BPDU was inferior to VLAN1 BPDU such as here? I cannot see any problem or inconsistency here: it's still clear that the root bridge for both VLANs is out there in the PVST+ region, and the role/state of the boundary port is nevertheless determined by the VLAN1 BPDUs only.

Yes this would cause the inconsistency. I need to dig more into why, because so far it's not fully clear as to the reason in the documentation I am reading. My lab confirms this result.

Now I believe you have yourself sub-consciously referred to the concept of the identical Root Bridge ID which I have been referring to all the time. How can two BPDUs, in any of the contexts we have referred to a pair of BPDUs here, be "identical", i.e. the same RBID, RPC, SBID, and SPID? That would definitely mean a looped BPDU, would it not?

You are correct. I think I used the word inferior and superior too many times in one sentence and my brain exploded . The only way you can truely get an identical BPDU back would be if you had our own BPDU looped back via a unidirectional link or some other method.

-Matt

QFX527518 · ‎03-13-2012

hi, the cat6500(C6sup22-psv-mz.121-26.e8.bin) have bug???in my lab,two VM have the same vlanid,and config not wrong,but,vm1 cant ping vm2 why???the the vm,the 6500 feature have some bug???

Matthew Blanshard · ‎03-13-2012

Hello,

There are bugs in any version of IOS. What is your topology for the VM's? How are they connected to the 6500? Can you provide some more details on this problem?

-Matt

QFX527518 · ‎03-13-2012

ibm Power7（1VIOS+3VM）---trunk--cat6500---trunk---ibm power7(1VIOS+3VM).all the vm belong the same vlan ,like 20,native vlan is 1.now,in the same Power7,vm1 can ping vm2and vm3. but,powr7(A)'vm cannt ping power7(B)'vm.vm's OS is aix.

Matthew Blanshard · ‎03-14-2012

Can you send the output of show interface trunk for the ports in question. What vlan are they in? Are the mac addresses learned on the respective ports? Does ARP complete on the VM's?

-Matt