I have a pretty standard HSRP setup and can't get rid of one final problem: One of my 4908G-L3 switches keeps reporting it's own active IP address in an HSRP group as duplicate but it is not sourced by the MAC address associated with the HSRP process (as indicated in Cisco's troubleshooting documents). Rather, the source is one of my 3550-48 switches that is attached to the core through a distribution layer of 3508G switches. I have verified all core layer configurations; no such thing as a duplicate IP address. I also think that I have thoroughly configured and checked all STP settings on all distribution and access layer switches; still no improvement. Any ideas where else I can look or what I might have overlooked?
I already did. Note that this case is based on the observation that the layer 3 device receives its own HSRP hellos back on the same interface, as indicated by the source MAC address of 0000.0c07.ac19 (well-known HSRP). This is *not* the case in my situation - I receive a duplicate IP address report from a "real" third device (note the different sourced-by MAC address in my error message), which is the 3550-48 switch. How does this make it different? Thanks for your efforts; I appreciate your responses.
IOS (tm) L3 Switch/Router Software (CAT2948G-IN-M), Version 12.0(18)W5(22b) RELEASE SOFTWARE
Distribution switches (3508G):
IOS (tm) C3500XL Software (C3500XL-C3H2S-M), Version 12.0(5)WC3b, RELEASE SOFTWARE (fc1)
Access switches (3550):
IOS (tm) C3550 Software (C3550-I9Q3L2-M), Version 12.1(8)EA1c, RELEASE SOFTWARE (fc1)
Please note that we have three 4908G-L3 switches at diffrent locations as a Layer 3 core with full equipment and path redundancy, whereas both our distribution and access layers are Layer 2 only (still full equipment and path redundancy at distribution layer). While Cisco normally favors layer 3 functionality at the distribution and access layers these days, this is one of their sugegsted designs for extremely scalable and high-performance backbones as outlined in one of their design documents (can't find it on the new web site right now).
The problem has been resolved with the help of Cisco TAC. They traced it back to a bug in the IOS release initially delivered with my new 3550 switches (SMI). After upgrading all my 3550-series switches in the access layer to IOS (tm) C3550 Software (C3550-I9Q3L2-M), Version 12.1(11)EA1, the problem disappeared.
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...