02-23-2012 01:38 AM
02-23-2012 01:46 AM
What type of Brocade switches do you have?
What version are you running on?
Do you have specified a dedicated Root bridge by configuring a priority on one of the switches?
Why are you using Single STP, but not single RSTP/802.1w or even PerVlan RSTP?
Any special cause for this?
02-23-2012 02:53 AM
two are ServerIron shipped with version 12.2.01bT403, whilst two are FastIron with Version:07.0.01T7f5. When redundant path between one FastIron and the ServerIron is enabled the ServerIron cpu usage goes up to 99%, however FastIron do not seems to be bothered much. I am really convinced that the timers and TCN I got are the key point, as well as the InDiscards on one of the ServerIron.
02-24-2012 06:19 AM
Pretty tough to say without knowing any configuration.
>>However I cannot see any topology change on this configuration
Well, from the perspective of STP it is a topology change when a port is changing STP state from learning to forwarding.
Except this port is configured as an edge port and there is no other STP switch connected to.
Have you used another port on the ServerIron for testing the same topology and redundant link?
is it the same behaviour, some debug message and same InDiscards?
02-24-2012 10:54 PM
thank you for your time.
Configuration is very simple, 10 VLANs, for each of them simple spannig-tree enabled, priority is correctly defined on all switches, as a matter of fact each recognize RB, RP and DP correctly. I would be very surprised if any issue in the configuration. I am suspecting some Hardware related issue on the ports. For what I know about InDiscards, those includes everything that is not considered as an InError, including internal lack of buffer space, (which should not be the case as there isnt practically traffic on the links) and VLAN unmatches, which is not the case either as VLANs are correctly configured in each switch. During troubleshooting I have been trying to see those topology changes, if any port goes from Listening to Learning to Forwarding but is not the case. Morover the debug output for the transitions does not report anything. What leaves me perplex and suspecting an HW issue is that one ServerIron seems sending those BPDU TCN (which I got from the debug and from the sending BPDU counters incrementing - this is a root port, should only receive BPDU) and at the opposite side the other ServerIron is incrementing InDiscards, which makes me suspect are those TCN notifications discarded). As a matter of fact the Root Bridge never receive those TCN and therefore those are sent constantly every Hello time. I plan to use different ports on both switches and see what happens. Is there any way to get hardware related issues from debug for a specific port, getting deeper than show statistics can give us?
02-27-2012 12:12 AM
If you change port then use port on other port group 1-12, 13-24 ... since 12 ports use the same packet-processor.
There might be a chance that the PP is corrupting packets, but there is a very low chance to see this with debugs.
To be sure what happenes in the uplink between SI and FI you would nee to put a TAP into the cable and do packet captures.
02-27-2012 12:45 AM
thanks for pointing out the port isse, I will take into consideration when I change the port on the SI. Is the PP issue common in your experience?
I will provide some feedback as soon as I am able to swap the cables.
02-27-2012 01:11 AM
thank you again for the answer. I forgot asking before, is there any way for detecting PP issues, any kind of debug command so similar that I could type on the boxes? I will post the results of the swap as soon as I get some results.
02-27-2012 01:27 AM
We have not yet been abale to detect PP issues with any debug&dm commands.
The only way was that stations conencted to the same port group experience communication issues and mostly we have seen corrupted packets in a packet capture.