Sup7L-E unicast flooding:ARP refreshes but MAC doesnot

Question

I have two 4507 switches configured HSRP, 45-1 is the active gateway of vlan2. Last week we found vlan2 was sufferring unicast flooding which was explainded by case#8 at this link
http://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html?referring_site=smartnavRD#t8. Then I changed the mac aging-time to 4 hours as the link suggests.
The problem seemed resolved. But after 20 hours, the problem reoccurred. I checked the ARP table and MAC table, the ARP entry of the IP address whitch caused the flooding updated 3 minutes ago. But there was no MAC entry for  the MAC address of this IP address!!! I pinged this IP address from 45-2 so the entry was established. After the weekend, I check the switches this morning, it reoccurred again.
In my opinion, the MAC entry must update as soon as the ARP entry updates,  then how could this happened again and again after the MAC aging-time was changed the same with ARP timeout?
Is there same case?Could anyone help?
The engines are SUP7L-E and the IOS is cat4500e-universalk9.SPA.03.04.00.SG.151-2.SG. TAC found no bugs by now.

Answer 1

I can't speak for other Cisco L3 devices at this point but the experience I am having shows that the ARP table entry is having the age reset to zero for every packet that passes through that MSFC destined for the host in question. When the table doesn't have an entry we can send a ping to that host from another host on a different VLAN. The MSFC will send an ARP request to which the destination host will reply. This will put an entry in the ARP table with an age of zero. It will also generally update the mac-address-table along the path we are concerned with. I can monitor the age of the ARP entry and before it ages out (4 hours by default) send another ping packet. At that point I can show the entry in the ARP table and it has reset the age back to zero.
In an HSRP configuration, if the standby HSRP MSFC is the one receiving the packet that is destined for the host he will refresh his ARP table entry from the ARP reply sent from the host and send the packet on its merry way. However, when the host replies to the packet itself he will send that packet to the active HSRP MSFC on the other switch and not to the standby HSRP MSFC. If you continue with the ping packets then the ARP table entry on the standby HSRP MSFC continuously gets reset to zero but the mac-address-table entry will eventually age out because that switch is never seeing any return traffic from the host.
I would agree with you that it should only reset with an ARP reply and I think that would be in accordance with RFC standards. That is not the behavior we are seeing however. We're continuing in the lab to test and observe to make sure we completely understand the behavior we are seeing but so far that seems to be the case.
Thanks,
Tyler