11-11-2007 08:18 PM - edited 03-03-2019 05:47 AM
Hi we are having regular spanning tree issues in our network.
On our config we do not have bpduguard configured from what I can see? Could this be an issue?
What can be done centrally on the core switches to remove this threat? Are their default configs that a wise network administrator would apply as standard?
HELP!
11-11-2007 09:22 PM
HI Mike [Pls Rate if HELPS]
Refer link below for examples and identify redundant links, root and backup root bridge etc..
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080136673.shtml#intro
Refer link for usage guidelines in implementing loopguard, bpdu guard etc..
A Cisco router will give you a warning when you configure PortFast:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION
%Portfast has been configured on FastEthernet0/5 but will only
have effect when the interface is in a non-trunking mode.
SW1(config-if)#
Not only will the switch warn you about the proper usage of PortFast, but you must put the port into access mode before PortFast will take effect.
But there is a chance - just a chance - that someone is going to manage to connect a switch to a port running Portfast. That could lead to two major problems, the first being the formation of a switching loop. Remember, the reason we have listening and learning modes is to help prevent switching loops. The next problem is that there could be a new root bridge elected - and it could be a switch that isn't even in your network!
BPDU Guard protects against this disastrous possibility. If any BPDU comes in on a port that's running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled. A port placed in err-disabled state must be reopened manually.
BPDU Guard is off on all ports by default, and is enabled as shown here:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree bpduguard enable
It's a good idea to enable BPDU Guard on any port you're running PortFast on. There's no cost in overhead, and it does prevent the possibility of a switch sending BPDUs into a port configured with PortFast - not to mention the possibility of a switch not under your control becoming a root switch to your network!
Refer link below for Understanding Spanning Tree Protocol:
Hope i am Informative and this HELPS.
PLS RATE if HELPS
Best Regards,
Guru Prasad R
11-12-2007 02:05 AM
What are the issues you are having? BPDU guard may or may not be an issue. What BPDU guard does is protect against unauthorised switches - If someone plugs a switch in, it takes the port down to protect spanning tree. It is nrmally a good thing.
It could be a problem if you have it configured on a port you expect to see a switch on though. DO NOT also configure BPDU Filter on the same port!
General good practice:
manually prune VLANS on trunks that they are not needed on.
Do not use VLAN1 for ANY data (not even a management subnet)
Consider UDLD
Use portfast on user ports, bot not on switch links
make sure you have forced appropriate spanning tree root bridges (I normally make Spanning Tree and HSRP mirror each other)
There re a number of other options available for consideration, but you need to understand them and their implications before just implementing them.
11-12-2007 05:31 AM
Thanks guys.
Had a STP loop in the early hours. Not the first time, but in the past i've isolated it to rogue netgear switches, which our first line guys had nicely attached around the place.
However this time there was no clear source, other than one of the core 4500 switches themselves.
Reloading the main switch cleared the issue but left me concerned that this could easily happen again.
PVST is enabled
BPDU Guard is disabled
BPDU Filter is disabled
Loop Guard is disabled
Portfast is enabled on all ports but as I say in this case I do not think a rogue switch was to blame.
One thing I noticed was that 2 of the switches had equal spanning-tree vlan x priority values? Could this be an issue?
What are the detrimental affects to implenting BPDU Guard and Loop Guard?
Like I say there is also no clear source to the problem this time. Any thoughts on how to trace or clues?
Mike
11-12-2007 06:24 AM
Also further info.
UDLD is disabled even on the trunk fibre ports? Would this be worthwhile?
I am also investigating the possibility of bugs within the IOS, but not sure where to look?
Running 12.2(25), 12.2(20r) and 2 versions of 12.1(12r) across the 4 switches.
11-12-2007 09:50 AM
Consider the Following:
1) Use the command ( #switchport mode host ) for your access ports.
This will automatically enable portfast and set the port to access mode.
2) Enable BPDU Guard on access ports, this will ensure that if you receive a BPDU the port will enter the err-disable state, and will shut down the port. (Ports with rogue switches will be shut down).
3) Enable Loop Guard on trunk-ports. STP depends in BPDUs to decide it's port role (designated or non-designated). If a non-designated port stops receiving BPDUs form the designated port, it will enter into the discarding>listening>forwarding. Since the other switch might still be in the forwarding mode, it will create a loop.
4) Enable aggressive mode UDLD.
5) Enable (#switchport mode trunk manually) , rather that allowing DTP to do the trunking for you. I've encountered in some occasions DTP flapping has been the cause for STP loops in some topologies.
That about sums it up.
Best Regards.
11-13-2007 08:19 AM
Hi,
What is your precise IOS version ? Wouldn't it be 12.2(25)EWA7 ?
Best regards,
Romain
11-13-2007 08:32 AM
Yes one of the versions is IOS 12.2(25)EWA7, RELEASE SOFTWARE!!!
How did you guess!!!??
Other versions of our switches are;
Version 12.1(20)EW2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
Version 12.1(20)EW2, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
Version 12.2(25)EWA7, RELEASE SOFTWARE (fc1)
12.2(20r)EW1
Version 12.2(25)EWA4, RELEASE SOFTWARE (fc1)
12.2(20r)EW1
Please get back to me on this one!
11-13-2007 08:47 AM
Hi,
Do not look further, you are just hitting one really severe bug.(I am pretty new in networking but it is the most severe I have seen). I met it with many customers.
Only this version is impacted so move quickly to 12.2(25)EWA9 for example.
The symptoms are :
- CPU increase
- spanning-tree loops
- unexpected UDLD messages
=> Only workaround is to restart the box
BUG ID = CSCsh25687
Best regards,
Romain
11-13-2007 09:07 AM
Hi thanks for the quick reply.
I have read the bug list but it makes no direct mention of spanning-tree?
I'm not saying an IOS upgrade wouldn't help its just i'd like to nail it for definite to a specific bug and version problem.
What problems and help did you find?
Mike
11-13-2007 09:25 AM
Hi,
Tunning your spanning-tree config would then help but I am sure your are hitting this bug after seeing it so much times with many customer.(And troubleshooting it during nights and nights with no result) The first symptoms (that makes all people believe in a spanning-tree loop) are the various "duplicate IP" messages your are seeing and then a high CPU increase on the box.
Best regards,
Romain
11-13-2007 01:27 PM
Do the following sh command to see if you have MULTIPLE mac adds hanging off any port on the switch.
Sh mac-ad tab
If you see any port with multiple mac adds, that's ur starting point. Check the config of that port, makle sure port fast is disable. Locate that user, and see why he is having a hub or another switch hanging off his network jack.
To be safe, enable secuirty limits on the switch interfaces with 2 mac add allowed max, use spanning-tree portfast bpduguard , & spanning-tree loopguard .
HTH.
Thx.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide