This discussion is locked

Ask the Expert: LAN Switching

Unanswered Question
Mar 9th, 2012

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. 

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.8 (6 ratings)
johnnylingo Fri, 03/09/2012 - 20:49

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 Sun, 03/11/2012 - 19:16

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 Sun, 03/11/2012 - 17:46

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.

Peter Paluch Mon, 03/12/2012 - 01:54

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 Mon, 03/12/2012 - 15:41

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 Tue, 03/13/2012 - 00:21

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 Tue, 03/13/2012 - 10:24

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 Wed, 03/14/2012 - 11:26

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 Wed, 03/14/2012 - 17:54

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 Tue, 03/13/2012 - 17:37

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 Tue, 03/13/2012 - 19:20

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 Tue, 03/13/2012 - 20:04

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 Wed, 03/14/2012 - 08:20

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

QFX527518 Wed, 03/14/2012 - 18:17



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.



Matthew Blanshard Wed, 03/14/2012 - 18:20

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

-Matt

Matthew Blanshard Thu, 03/15/2012 - 09:52

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

johnnylingo Tue, 03/13/2012 - 19:38

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.

Matthew Blanshard Tue, 03/13/2012 - 19:42

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

Peter Paluch Wed, 03/14/2012 - 11:29

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

Matthew Blanshard Wed, 03/14/2012 - 11:45

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

DriJones01 Wed, 03/14/2012 - 14:32

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?

Matthew Blanshard Wed, 03/14/2012 - 18:22

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

DriJones01 Thu, 03/15/2012 - 16:33

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?

Matthew Blanshard Thu, 03/15/2012 - 17:40

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.

hobbe Thu, 03/15/2012 - 05:25

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

Matthew Blanshard Thu, 03/15/2012 - 09:53

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

hobbe Fri, 03/16/2012 - 00:55

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

Matthew Blanshard Fri, 03/16/2012 - 18:42

I am pretty sure it is because of the fact that 4500 doesn't support MPLS and only routes IP.  On the 6500/Nexus they do MPLS so can route non-ip traffic. 

-Matt

QFX527518 Wed, 03/21/2012 - 19:57

i can't open case.

if change the cat6500 to cat 4507R0,and the ios is cat4500-entservices-mz.122-31.sga2..bin,all the vm can work normal.so,i think the cat6500 and the ios have some different int the IEEE802.3.

JohnPete868 Sat, 03/17/2012 - 07:17

Hi Matt,

I would really apperciate any advise on this.

https://supportforums.cisco.com/message/3589591#3589591

I've already posted this question on the lan and switching board.

Hi,

We have a 4 site network all linked in with leased lines. Two of the sites have MS Network Load Balancer which have a unicast IP address but when the switch does a arp the NLB send out a multicast mac. We were not able to ping these NLB before, I found out that I needed to add a static entry in the L3 device which solved the problem.

Recently, the network has been running extremely slow and a network output shows of tcp re-transmission packets, different mac-address associated with different ip address and a extremely large amount of 'TCP Segment of a reassembled PDU' , some T'CP Acked lost segment, TCP out of order and TCP DUP ACK.

We have crossed checked the devices ip and mac address to the output and some packets do not match.

In addition to this we are seeing large amounts multicast traffic on the network which is sent to the NLB, which can only be noticed by the multicast mac address as the ip address is a class c. What I find strange is, all the multicast, tcp errors traffic is sent to the NLB, when surely only the NLB should be sending multicast traffic as it would be replying to ARP request?

The multicast packets have a souce of a class a, b, or c ip address but we can only see that there are multicast as this is determined by the mac-address.

For the network load balances, should all the L2 and L3 devices directly connected to the NLB have a static ARP entry in its CAM?

Also, having a static entry in the directly connected switch, enable the directly connected switch to send out the NLB mac address when other switch request the Mac address for the NLB?

Would appreciate any throughts.

Matthew Blanshard Mon, 03/19/2012 - 09:12

Hello John,

On Cisco devices that are doing the layer-3 routing you will need to use a static ARP entry for Microsoft NLB nodes running in multicast mode.  Since this is a violation of the 802.3 ethernet RFC Cisco has chosen to implement strict adeherence to this standard and not allow dynamic ARP entries to work for this. 

Do you have static mac address entries for the NIC's on the NLB cluster?  Nobody should be sending out packets sourced from the multicst cluster mac. 

-Matt

JohnPete868 Mon, 03/19/2012 - 13:44

Hi Matt,

Thank you for taking the time out to respond.

I have inserted a static arp on the default gateway of the NLB nodes. I have been advised to insert static mac address in the mac-address table on every switch on L2 aswell, is this needed as we have multi vendor network with over 35 switches. If it is then is there any feature which Cisco switches can help in?

The NLB Cluster is within a vmware switch and we could put static macs entries but I was thinking of placing them in the Cisco switch which is directly connected to the v switch and then the hosts?

It seems that a packet is send to the correct device but then another device with the same L3 address is responding, the packet is being dropped by the receiver and then the correct source is then sending a re-transmission tcp packet?

JohnPete868 Tue, 03/20/2012 - 11:20

Hi Mat,

Thank for your reply, I have read through this link and I have implemented the solution.

My concern was, I don't want to go around to every switch and add static mac entry some of which are non cisco switches. Is there any way where I can add a command in the cisco switches which then populates other devices which are directly or non directly connected?

Thanks

Matthew Blanshard Tue, 03/20/2012 - 19:17

Unfortunately there's no way to transfer the configuration down to the other switches.  If you can run the Microsoft NLB in igmp mode you can do away with the static MAC addresses since the Microsoft NLB server will send IGMP joins, allowing IGMP snooping to add dynamic entries to the switch.  Then all you would need is a static ARP and the rest would be dynamic.   This is the closest you can get to Microsoft NLB working dynamically. 

-Matt

johnnylingo Sat, 03/17/2012 - 12:32

Have a hardware related question, specifically on the 6500 and 4900M platforms.

What we've been seeing often with hardware failures is an ASIC going bad, for example ports 9,10,11,12 on a WS-X6716-10GE will fail but the other ports continue to work fine.  Usually this is clear in the logs by this message:

TestUnusedPortLoopback Port(s)[4] failed. System operation continues

However, we've seen a few cases where UDLD will disable a port for an unknown reason.  The "show module" command shows the module to be "Ok/Pass", so we replace cables and gbics and shut / no shut the port.  However, UDLD still re-disables the port.  Rebooting the module ultimately clears the problems.

My specific questions are:

  1. Other than "show module", is there any type of in-depth status report or diagnostic test we can do to look down at the hardware (specically ASIC level)? 
  2. On the 6500 w/ SUP720, there is the command "show platform hardware capacity fabric" will display utilization for each module, broken down with 2 x 20GB channels per module.  Is there an equivilent command on the 4900M?
  3. Better yet, is there way to break down utlization by ASIC?  We have a lot of WS-X6716-10GE and WS-X4908-10GE modules and are looking for an easy way to look at the oversubscription statistics so we can plan for future growth. 
Matthew Blanshard Tue, 03/20/2012 - 08:55

Hello Johnny,

Unfortunately this information is not publicly available.  If you private message me I can explain the process to get this information. 

For #2 you can use show fabric utilization to see the individual channels usage. Unfortunately there is no equivalent on the 4900M. 

-Matt

Carlos190 Mon, 03/19/2012 - 09:07

Hi,

Could you please explain about the use of vrf in Nexus, why is it necessary for issuing ping and traceroutes among others, and whether you know the reason why it was designed that way in Nexus.

Thanks

Matthew Blanshard Mon, 03/19/2012 - 10:10

Hello Carlos,

I am not following you.   VRF is not required for any interface except the management port.  For any other interface it works just the same as in IOS except for the subtle command differences. 

-Matt

zyang@cpg.org Mon, 03/19/2012 - 12:13

Hi Matthew,

CCNA newbie here.  Just wanted to ask a network design question..

Say you have 2 floors and each floor has 4 vlans on a layer3 switch.  They're all connected to a core layer3 switch.

My question is what is the best way of networking them?

Right now the company that I'm in has it set up where the gateways for each vlan is setup on the core switch.  And trunk links are setup connected to the core switch.  This is setup I think is ok, except when 2 users on different vlans on the same switch need to transfer files over, they will always use the trunk link.  Granted that this happens once in a while, still I don't think it's a good use of bandwidth when they can be routed internally on the switch. 

I was thinking a better way for this situation was that where the trunks are, you would assign IPs to the port and do the same for the core switch.  Then have the vlan gateways internally on the switch.  Although even if we do have a lot of users transfering data between each other, I don't think we will just change the network design.  Though we are going to be moving to a new building, and it is something to think about.

So which is a better method?  Given the same situation, how do most companies design their networks?  Is there a SOP (standard operating procedure) for something like this?

Thanks very much.

Matthew Blanshard Tue, 03/20/2012 - 08:56

Hello Zhi,

If it was my network I would use layer-3 interfaces and routing between the floor switches and the core switch.  There is no SOP for something and it really boils down to what you prefer

-Matt

Carlos190 Mon, 03/19/2012 - 12:18

Thanks for replying, I want to understand the reason why to issue a ping or traceroute from a Nexus has to include now the command vrf. Eg: ping x.x.x.x vrf management  - in the case of the network I work at.

mpugina63 Tue, 03/20/2012 - 09:54

I have a problem where I'm trying to add a switch at a remote location that I am connecting to over a VPN Tunnel to my main sites VTP domain. I have it configured correctly, but it won't join. Any ideas?

Main Site

VTP Version                     : running VTP1 (VTP2 capable)

Configuration Revision          : 192

Maximum VLANs supported locally : 1005

Number of existing VLANs        : 88

VTP Operating Mode              : Server

VTP Domain Name                 : vtp-ebiz

VTP Pruning Mode                : Disabled

VTP V2 Mode                     : Disabled

VTP Traps Generation            : Disabled

MD5 digest                      : 0xA8 0x13 0xA8 0x55 0x70 0xF0 0x96 0xAD

Configuration last modified by 10.1.1.2 at 3-13-12 16:47:09

Local updater ID is 10.1.1.2 on interface Vl1 (lowest numbered VLAN interface found)

Remote Site

VTP Version                     : 2

Configuration Revision          : 0

Maximum VLANs supported locally : 1005

Number of existing VLANs        : 16

VTP Operating Mode              : Client

VTP Domain Name                 : vtp-ebiz

VTP Pruning Mode                : Disabled

VTP V2 Mode                     : Disabled

VTP Traps Generation            : Disabled

MD5 digest                      : 0x8B 0xF5 0xD1 0x3C 0x6C 0x3D 0x38 0x33

Configuration last modified by 10.5.1.2 at 3-1-93 04:37:54

Matthew Blanshard Tue, 03/20/2012 - 10:01

VTP adverstisements only go out across trunk links.  Are these sites connected at layer 2?

-Matt

city.national Tue, 03/20/2012 - 10:33

Hey Matt...

  I would like to ask  you a general question about Trunking which everyone has a different answer for. The question is about how you configure the native vlan in a trunk port. Here are some of the answers:

  >> Do not configure native vlan. By the default, the switch uses Vlan1 for untagged packets even when Vlan1 is shutdown for many other different reasons

  >> Configure the native vlan using your data vlan so all untagged traffic goes thru it

  >> Configure the native vlan using a vlan that is not used anywhere else. In other words, configure a dumb vlan and use it as the native vlan

  Thanks RG-

Matthew Blanshard Tue, 03/20/2012 - 10:55

Hello RG,

This is another of those questions where everyone has an opinion . In my opinion there are two ways you can setup the native vlan.  You either use it for your management vlan, or you use it for nothing and let it be a dead vlan.  Either method is acceptable, but I wouldn't use it as a regular data vlan. 

-Matt

mpugina63 Tue, 03/20/2012 - 10:51

Matt,

Thanks for the reply, these site are connected via layer 3 tunnel. Is there anyway to make it work in that environment?

Thanks

Matthew Blanshard Tue, 03/20/2012 - 10:53

You would have to setup something like L2TPv3 to tunnel the L2 over the L3.  What kind of device is handling the tunnel?

-Matt

Actions

Login or Register to take actions

Related Content

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,725
4 7,083
5 6,742
Rank Username Points
165
82
70
69
55