Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Ask the Expert: LAN Switching

Read the bioWith 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. 

67 REPLIES
Bronze

Ask the Expert: LAN Switching

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?

Cisco Employee

Ask the Expert: LAN Switching

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

New Member

Ask the Expert: LAN Switching

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.

Cisco Employee

Ask the Expert: LAN Switching

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

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

-Matt

Cisco Employee

Ask the Expert: LAN Switching

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

Cisco Employee

Ask the Expert: LAN Switching

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

Cisco Employee

Ask the Expert: LAN Switching

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

Cisco Employee

Ask the Expert: LAN Switching

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

Cisco Employee

Ask the Expert: LAN Switching

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

Cisco Employee

Ask the Expert: LAN Switching

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

New Member

Ask the Expert: LAN Switching

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???

Cisco Employee

Ask the Expert: LAN Switching

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

New Member

Re: Ask the Expert: LAN Switching

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.

Cisco Employee

Ask the Expert: LAN Switching

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

New Member

Ask the Expert: LAN Switching

on the cat6500,can see the client's MAC,but a-client1 cant see b-client1's arp.now,if change client vlan id 87 to vlan 1,a-client1 can ping b-client1.

Cisco Employee

Ask the Expert: LAN Switching

Can you send the output of show int po3 trunk and show int po5 trunk?  Is VTP pruning turned on?

-Matt

New Member

Ask the Expert: LAN Switching

Cisco Employee

Ask the Expert: LAN Switching

This is going to require more in-depth troubleshooting then we can do here.  I would suggest opening up a TAC case and PM me the case number and I can grab it and work with you on it.

-Matt

Bronze

Ask the Expert: LAN Switching

Matt,

Thanks for the info on scalabiltiy with R-PVST vs. MST.  I was aware of the limitations with regards to the BPDUs, but having hard numbers helps a lot there, so thank you very much!

My other question might be more geared towards product mangers but perhaps you know the answer.  I noticed the Nexus 3000 switches do not support PAgP.  Is this is specific move just for the Nexus platform, or an indication of long-term support?  

To my knowlege, there are no real advantages of running PAgP over LACP, so it would make sense to phase out PAgP in new products, similar to what was done with ISL years ago.

Cisco Employee

Ask the Expert: LAN Switching

You hit the nail right on the head.  LACP is the preferred way to go and any new platforms coming out are unlikely to support PAGP in the future.  Since LACP is an IEEE standard it provides many advantages over PAGP in terms of interoperability. 

-Matt

Cisco Employee

Ask the Expert: LAN Switching

Hello Matt,

This is an interesting information. However, for 6500 VSS, the PAgP+ was recommended for active-active detection. At the time, I had the feeling that Cisco did not implement a similar functionality into LACP. So for VSS, are we stuck with PAgP+ or is the active-active detection already available with LACP as well?

Thank you!

Best regards,

Peter

Cisco Employee

Ask the Expert: LAN Switching

Hello Peter,

Unfortunately there is no dual active detection implemented into LACP.  If you can't implement PAgP+ via an older switch the alternative to PAgP+ is to use the fast hello method.  You can achieve the same level of response time with fast hello as you can wiht PAgP+ to a dual-active scenario.

-Matt

New Member

Ask the Expert: LAN Switching

Inherited an SMB network with a Catalyst 3650, some Express 500 switches and NEC DTerm IP phones running PoE. No passwords or documentation of config.

Took one of the spare 500 switches, reset to factory, and setup IP+Desktop smartports on the copper ports, added the Cisco-Voice VLAN.

Phones are powering, but not finding the Voice VLAN or DHCP server for the phones.

Is there a way to discover (Wireshark or otherwise) what VLAN I need on the 500 switch so that the IP phones will work sjhort of wiping everything and starting over?

Cisco Employee

Ask the Expert: LAN Switching

Hello Indy,

This is going to be a tough one.  Is there a way you can find out the vlan id on the phone?  On Cisco phones you can find out the voice vlan id on the network configuration screen.  Does the NEC phone offer something similar? Without that doing a wireshark is going to be difficult unless your PC supports vlan tagging on the NIC. 

-Matt

New Member

Ask the Expert: LAN Switching

Matt,

Found a way to get into the phone, and the configuration doesn't yield much other than the VLAN is 5.

Took a spare Catalyst 500 and added a VLAN ID=5.

In trying to configure a port to VLAN 5, the Cat 500 inists to keep the Cisco-Voice VLAN as the voice LAN. So .... recreated the Cisco-Voice VLAN as VLAN ID=5.

Is that the correct configuration that the Cat 500 is looking for?

Cisco Employee

Ask the Expert: LAN Switching

Yes that is exactly the info we were looking for.  It should work with the configuration you specified.

-Matt

Please excuse typos sent from my android phone.

Gold

Re: Ask the Expert: LAN Switching

Hi

I have a question about the mtu size.

This is not a question about what the mtu size is as much as a reflektion over why it is what it is.

If you set the MTU size of a 3750x fx you will have a max MTU size of 9198

System jumbo mtu 9198

Same with the 4500

That is all fine and well BUT

Why are the NEXUS and the 6500 max mtu size 9216 ?

How is this calculated ? where does the extra 18 come from and why ?

Thanx

/Hobbe

Cisco Employee

Ask the Expert: LAN Switching

Hello Hobbe,

The difference is due to the 18 byte ethernet header.  On the 6500 the 9216 includes the 18 byte ethernet header already, on the 4500 it does not, so it gets added afterwards.

-Matt

Gold

Re: Ask the Expert: LAN Switching

Thank you very much for the explanation.

You do not happen to know any references or reasons why they calculate that way ?

why not being consistant ?

/Hobbe

8827
Views
29
Helpful
67
Replies