MAC learning and unicast flooding

[rtjensen4]

Hi all,

Strange situation.

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?

[andtoth · Accepted solution]

Hi,

Have a look at the following case study:

Case Study #8: Asymmetric Routing and HSRP (Excessive Flooding of Unicast Traffic in Network with Routers That Run HSRP)

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#t8

Andras

[rtjensen4]

Thanks Andras,

I think this is exactly what's happening. I put in the recommended fix, which is to increase the mac address-table aging time to 4 hours, so let's see how things go.

[Peter Paluch]

Hi,

Interesting issue. I've got a couple of questions - can you answer them for me?

1. 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?
2. How do you know the frame is flooded - have you discovered that the frame is indeed delivered to inappropriate ports?
3. Also, is the Host B actually active? Does it respond so that switches can learn its MAC?
4. Is the MAC address of the Host B present in the ARP table of the 4507-1?
5. 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.

Best regards,

Peter

[Peter Paluch]

Hello again,

Well, while I've been writing my overly lengthy reply, Andras has pointed us to the article that sums it up perfectly. Disregard my previous speculations, Andras hit the nail on its head!

Best regards,

Peter