Troubleshooting %STANDBY-3-DUPADDR in a big L2 network

[lap]

Hi all,

I am trying to find what is root cause of  %STANDBY-3-DUPADDR.

The network is as following:

Access layer: 100 switches (mix of 3560,2950,2960,3534XL,3548XL,2970,3550,3512XL) connected to each core switch.10 swith have singe connection to one of the core switch

Distribution core: 2  WS-C6509-E running  12.2(18)SXF11 with 3 modules  WS-X6748-SFP and SUP: WS-SUP720-3B

Spanning-tree: PVSTP+

VLAN are filtered manual with Trunk allowed

Number of VLANs: 75

Issue: %STANDBY-3-DUPADDR in log of both core reported from several VLANs at diferent time of the day and it is not the same time from day to day.

I guess  I am facing a STP issue so I made a complete drawing of the network to get an overview of which VLANs where allowed on with switch.

So my goal is to to filter the VLANs to a minimum on each trunk to reduce the number of STP instance as I guess som of these access switches cannot support that much.

For example I saw a C3560 with 412 instances of STP and MAX is 128. What would be the consequence of going over the MAX allowed? Actually it looks like the switch is declaring itself root for all the VLANS apart from 2 or 3. Can it be a consequence of exceeding the number of STP instance?

Please share your experince/ideas in order to solve this issue.

Best Regards

/Laurent

[lgijssel]

Hi Laurent,

I guess  I am facing a STP issue so I made a complete drawing of the network to get an overview of which VLANs where allowed on with switch. 

You are most likely correct here.

For example I saw a C3560 with 412 instances of STP and MAX is 128. What would be the consequence of going over the MAX allowed? Actually it looks like the switch is declaring itself root for all the VLANS apart from 2 or 3. Can it be a consequence of exceeding the number of STP instance?
Please share your experince/ideas in order to solve this issue. 

Good question. I have never tried actually but I presume the switch will run out of memory- or CPU resources.

A 3560 has 48 access ports at maximum so why would one need more than this number of vlans? Ok, I can think of a few scenario's but still I would say that 128 is more than enough. If not, you probably have a design problem. From what I read about your network, this is even more likely. Examples: running an old IOS on the core, many different models of switches, no uniform redundancy model, just to name the first three I noticed.

Still I think your first steps are appropriate. You should determine where you want the root of all vlans to reside; probably this is on the 6500 core. Then check on all switches to see if they agree on the root and correct those who have a different one.

Please note that you can also introduce STP problems by configuring which vlans are allowed on a trunk. Not allowing a vlan will also prevent bpdu's being sent over that link. In this way you can break the STP topology.

Perhaps the link below can serve as a first start for troubleshooting help:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800951ac.shtml

regards,

Leo

[lap]

Hi Leo,

Sorry for my late reply. It looks like the problem is solved and was du to a C2950 with had 64 STP instances (MAX allowed) and was running with 71 VLANS.

So I would like to know if somebody knows what is the exact behavior of a switch when MAX instance allowed is exceeded?

Regards,

Laurent

[glen.grant]

  I believe it runs the max and any further vlans will not have spanning tree running.  All that has to be done is to manually prune  the links leading to switches.   On both side just use the "switchport trunk allowed " command .  Lets face it a 2950 does not need 70 vlans on it .  If you are runing say 4 vlans on switch prune off everything else .Only  manually pruning will reduce the spanning tree instances on the switch.  This is specially critical on say the 2950's and any of the old 3500XL models  as they have limited instances of spanning available to them .  Yes this does add some configuration overhead but unless they plan on getting newer switches which don't run into the spanning tree restrictions it would be a good idea to do this and then see how the hsrp issue is .