I hvae a pair of 4507Rs with HSRP working for about 15 VLANs with a 2-port etherchannel between them. I'm seeing some odd Unicast flooding issues and I'm curious as to WHY it's happening.
Here's the scenario:
Host A physically connected to 4507-1 onVLAN 102 (4507-1 is HSRP active, 4507-2 is HSRP standby) sends a frame to a host B physically connected to 4507-2 on Vlan 59 (4507-2 is HSRP active, 4507-1 is HSRP standby), the frame should be routed by 4507-1 and sent across the port-channel to the other switch and delivered. Instead of the packet being switched to the other switch, it's being flooded through VLAN 59 as an unknown unicast (i think), because the MAC address of Host B is not listed in the CAM of 4507-1. I don't have anything special configured on the trunk between the switches that would block this learning. No filtering at Layer 3. I see this scenario happening quite a bit with pretty much every VLAN combination, and I don't understand why. Could this be an issue on the host? or on the switch? is there a part of the config that could be looked at? I have 4507-1 SPT root for all VLANs except for 2, vlan 59 and vlan 800 (VoIP)
Is there some intracacy I don't know about regarding this type of setup?
Interesting issue. I've got a couple of questions - can you answer them for me?
Could you please describe in more detail how are the two 4500 switches interconnected? Is it a simple trunk (on a Port-channel) with all VLANs allowed on it, and the VLANs existing identically on both switches?
How do you know the frame is flooded - have you discovered that the frame is indeed delivered to inappropriate ports?
Also, is the Host B actually active? Does it respond so that switches can learn its MAC?
Is the MAC address of the Host B present in the ARP table of the 4507-1?
Is there enough free space in the CAM of your switches?
I have noted that your 4507 switches are both HSRP Active in different VLANs. Now I am thinking about a strange scenario: Host A sends packet to Host B. The gateway is 4507-1, so it receives the frame and reroutes it to the VLAN where the Host B resides. The 4507-1 asks for the MAC address of the Host B via ARP and after receiving it, it encapsulates the packet into a frame once again and tries to send it. For some obscure reason, the MAC address is now known in the ARP table but it has not been stored in the MAC table yet so the frame is flooded. Now, when the Host B replies, it sends its packet to the 4507-2 because it is the Active HSRP router in its VLAN, thereby not even giving a chance to the 4507-1 to learn its MAC address again. The 4507-2 reroutes the packet to the VLAN where the Host A resides, and potentially, the same process results in the frame to the Host A being flooded as well. The MAC address learning and storage into the CAM is actually much slower than I originally thought. Multiple frames may be flooded before the CAM is programmed with the new learned MAC.
Can this be the cause? You'd need to verify that by sniffing and watching the contents of the MAC and ARP closely. Also, watch out for duplicate connections of a single host to the same network (using, say, two NICs). Common operating systems do not cope with this situation very well and often cause spectacular problems, like answering to the ARP for one of its address using the MAC of the second NIC, and similar monstruosities.
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...