There is Catalyst 2950-LRE switch with 2 GigabitEthernet ports and 8 LRE ports. One of its gigabit ports (or both, they form an Etherchannel in this case) is connected with UTP to HP Procurve 2626 switch. This port (or ports) and HP switch form the uplink to the main LAN. After the Catalyst is turned on its gigabit port (or ports) goes up quickly but after some time it begin to flap with random interval (usually several times per day). As a result Catalyst and all its LRE users get disconnected from the main LAN. There is no any visible reason for these flaps nor I can see any correlation with any external events.
Upgrading IOS (I tried 12.1-11-YJ3, 12.1-11-YJ4, 12.1-19-EA1a) does not work. Replacing the cable does not work. Connecting the cable to another gigabit port causes this other port to start flapping. If both ports work together, the first one flaps and pulls down entire EtherChannel. In this case the messages appear int the event log that the port that has gone down and now is trying to go up has some different characteristics than another port and therefore can not be admitted back to Etherchannel (or somewhat about).
I did not write something special about gigabit ethernet ports to the config relying on the automatic negotiations. I also did not disable STP, nor CDP nor any other things that run by default and that probably are usually disabled by experienced Catalyst users (I am not the one - this my only Catalyst).
So, does anybody know what all this could be? Does some hardware is going to die? Or is this a known bug? Or perhaps I did not do something important that should be done?
I had similar problem last week with our LRE Switch (2950 series with IOS 12.0 ) and LRE port used to go down for every minute (flap link) . This is nothing to do with STP . I've changed the profile to Private one (lre-5 ) and it works fine. Looks like it's a bug or needs IOS upgrade .
It won't resolve my problem, since I use two aggregated 15LL LRE links and this is a minimum bandwidth the users can let me set - they are greedy for bandwidth. So I cannot switch to 5Mbit profile permanently but I will try to do this temporarily and see what will happen. Probably it will show the direction to think and let me find the solution.
By the way (h'm), haven't you a service contract with Cisco for your LRE equipment? I have not. But if you have you could open a case about this problem in Cisco TAC and the solution could be useful for both of us. Surely I understand this is somewhat impudent for my part to ask you for this so I in no way insist.
You mention that you've swapped cables, but didn't say whther the cables were hand-made or commercially produced.
Bad cables (improper / not to specification) will cause the symptoms you've described.
Try some new, purchased / commercial, decent quality Cat5e or Cat6. The panels (and any other cabling component in the path) must also be rated at Cat5e or Cat6. Cat5 may work, but it would need to be in good shape and pinned-out to EIA/TIA 568 spec.
The first cable I used was a Cat5 factory-made cable (to be more precise Cisco yellow ethernet cable). Though it is Cat5, not 5e or 6, I beleived it's good since I plugged it to 100-Mbit, not Gigabit port on Procurve side. Am I right? Or I nevertheless need a better cable?
The second one is also factory-made Cat5 but I cannot remember its origin.
Later I've re-plugged cables from 100Mbit to Gigabit port on ProCurve but had not seen any difference in Catalyst behavior - the interface flapped before and keeped flapping after.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...