[c-nsp] Unicast storms

[Vincent De Keyzer]

Basically I have two answers now:
1. Eric points me to asymmetric traffic/routing and MAC/ARP timeouts
2. Stephen says "unicast storm-control" does not work properly by design (or
because of Microsoft, depending on which side you are on :)

Now, if anybody has successfully implemented "unicast storm-control", and
only sees a few breaches from time to time, I'd be interested to hear this.

In the meanwhile, I'll investigate Eric's track, and let you know (might
eventually open a case at TAC with this).

Thanks

Vincent

> If you have HSRP enabled on layer-3 switches, make sure that the
> mac-address-table aging-time is set to 14400 seconds or better so that
> it will not age out before the ARP entry for any given host.
> 
> The problem with HSRP is that both the standby and active router can
> forward traffic into the VLAN, but only the HSRP active receives the
> return traffic.  There are many configurations where the only unicast
> traffic (which is required to populate the mac-address-table) the HSRP
> standby will receive from a host is the direct response to an ARP
> request every 4 hours.  With the default mac-aging time of 300 seconds,
> that means that your HSRP standby switch/router would potentially only
> have a valid layer-2 forwarding interface defined for 5 minutes after an
> ARP is completed to the host.   After 5 minutes, the router still
> maintains the ARP entry so it knows which MAC to address the traffic to,
> but when it gets sent to the layer-2 portion of the switch the
> mac-address-table interface mapping is gone so the switch is forced to
> flood the frame out to all interfaces on the VLAN.  This flooding will
> continue for the next 3 hours and 55 minutes until the HSRP standby
> router issues another ARP request for the host.