Our LAN is made up of two sites each with a 6500 and a 3750. All 4 devices are connected via fibre with the 3750s providing a redundant link should the primary link (6500-6500) fail. Diagrammatically it looks like a square.
We are running HSRP on the 6500s, and switches in critical departments are connected to both the 6500 and the 3750 so should either 6500 fail the other will take over and all traffic will pass through the 3750 to the other site and be routed by the 2nd 6500.
Everything had been working fine for months until all of a sudden we had a major network outage when all of our 2950s error disabled their uplinks to the 6500 causing a mad panic while we ran around reseting them.
As a result we have implemented error recovery on all compatible switches which is just as well because a few days ago we had the same problem, but on a smaller scale.
Inspecting the logs of the 6500 that is the primary HSRP router we found the following output.
Dec 12 05:37:49: %STANDBY-3-DUPADDR: Duplicate address 22.214.171.124 on Vlan61, sourced by 0000.0000.0000
Dec 12 05:38:42: %STANDBY-3-DUPADDR: Duplicate address 126.96.36.199 on Vlan61, sourced by 0000.0000.0000
Dec 12 05:40:07: %STANDBY-3-DUPADDR: Duplicate address 188.8.131.52 on Vlan88, sourced by 0000.0000.0000
When we do a 'show standby' we get the following output
Vlan88 - Group 0
Local state is Active, priority 110, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 2.086
Virtual IP address is 184.108.40.206 configured
Active router is local
Standby router is 220.127.116.11 expires in 8.772
Virtual mac address is 0000.0000.0000
Authentication text "xxx"
1 state changes, last state change 9w0d
IP redundancy name is "xxx" (default)
It seems strange that we get this duplicate ip address message, as if the backup router has lost connection to the primary and attempted to take over the primary role, but no recent state change has occurred.
Some where in the logs either in the 6500 or the 2950's in the log it should tell you why it errdisable the ports and you may be able to get an idea from there . If you have trunk links make sure the native vlan is the same on both ends . Make sure the hsrp timers are equal all the way around , better to leave as default . Look for any links that might have failed at the same time as the outage . Look for dirty links between devices . Check to see where the roots are for all your vlans and are they where thay are supposed to be . you certainly don't want a 2950 being the root .
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...