[c-nsp] Unicast storms

[Eric Spaeth]

Assume the following configuration:

D1     D2
|         |
S1---S2

D1 and D2 are upstream distribution routers, S1 and S2 are layer3 
switches so the links to D1 and D2 are routed.
Assume VLAN10 is trunked between S1 and S2, and end stations are present 
on VLAN10 on both S1 and S2.
HSRP is configured between S1 and S2, with S1 being the HSRP active.

Scenario:  Host (SOURCE) from somewhere in the network is talking to 
host (TARGET) directly connected to S1 VLAN10.   Both D1 and D2 have a 
learned route for that network.   Assume the traffic from SOURCE comes 
in via D2.

1) D2 forwards the traffic for TARGET to S2
2) S2 ARPs for TARGET, as it is a locally adjacent interface (VLAN10)
3) S2 learns that TARGET's MAC comes in via the trunk to S1.  S2's 
layer3 engine forwards the traffic to VLAN10, and the layer2 engine for 
VLAN10 forwards the traffic out the trunk to S1.
4) TARGET gets the traffic, forwards the response to SOURCE out to the 
gateway (S1) which forwards traffic out to D1 and the rest of the network
5) After 5 minutes, D2 continues to forward packets to S2, but S2 has 
not seen any traffic from TARGET so it floods the frames out to all 
members of VLAN10, including the trunk to S1.

If TARGET never talks to any of the other members of VLAN10 on S2, the 
only unicast traffic S2 will see from TARGET is the response to the ARP 
request.

That's the simplest scenario where this comes into play;  hang some 
workgroup switches off of S1 and S2 with spanning-tree breaking the loop 
in various places and that's where your other configurations come in.

-Eric

Pickett, McLean (OCTO) wrote:
> The switch will only timeout the mac table entry if the host has failed to
> generate a single valid frame over the timeout period. The switch will then
> broadcast the first frame destined to the host and re-learn the host mac
> based on its response.
>
> The ongoing broadcasts should only happen if the mac address in the router's
> cache is no longer valid and does not exist on the network.
>
> McLean
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric Spaeth
> Sent: Monday, July 02, 2007 1:04 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Unicast storms
>
> 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. 
>
> -Eric
>
> Vincent De Keyzer wrote:
>   
>> The configured treshhold is quite high (10% - that's 100 Mbps on GigE
>> ports!...).
>>
>>  
>>
>> I believe there is something wrong - where do I start troubleshooting
>>     
> this?
>   
>>   
>>     
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>