Unicast Flooding issue

[juanluis]

Hi,

My customer seems to have unicast flooding in a segment of his network. There are 2 x 6509 with HSRP arquitecture, 2 x 4948, 2 x local director and 2950. The issue is that unicast traffic to a port in the 4948 switch is flooding to all port in that vlan and  switch, it cross local director and we can see it in 2950 ports whre thera are connected server within that vlan but with different IP address. I mean, it seems quite clear that we have unicast flooding.

I have some questions about this issue:

Simplified: 6509 --> 4948 --> local director --> 2950

- How can I be sure that I have a assymetric routing problem?

- I have used the command switchport block unicast in the port that connect the 4948 with the local director and the problem seems to be fixed (there is not unknown unicast traffic in 2950 already)

- Is that a good solution or It would be better upgrade version of 4948 or even 6509 and use other commands as

mls rate-limit layer2 unknown,

show mac-address-table unicast-flood

platform rate-limit layer2 unknown

- It is needed that I synchronize arp timeout and mac address table timeout getting down the arp timeout?

Thanks in advance

Regards,

Juan Luis.

-

[Richard Burts]

Juan Luis

A very good first step would be to synchronize the timeout of the arp table and the mac address table. The mismatch in timeout (with arp much longer than the mac address table) is a common cause of unicast flooding. So I would certainly suggest that you make this change. It may or may not fix the complete problem. But I would certainly start with this.

HTH

Rick

[juanluis]

OK, thanks

I will try it, but I will continue with the question in minnd: why the switch clear the  mac entry and is not able of refresh it.

And why here is involved the arp table of 6500?, the problem happen in the 4948 switch with devices in the same vlan, so they don´t need access to 6509 for nothing. I dont undestand.

If you could clarify the issue I would appreciate it.

Thanks in advance

regards,

Juan Luis.

[Richard Burts]

Juan Luis

I do not know enough about your network to say anything authoritative about whether you do or do not have assymetric routing. I can only say that assymetric routing is one common cause of unicast flooding. And that the use of HSRP on a layer 3 switch is one thing that can cause assymetric routing.

Let me suggest this scenario and you can tell us whether it might be close to your situation or not. Let us call the 6500s coreA and coreB. There are two paths from the core to the local director and the 2950. coreA goes through one 4948 to the local director and coreB goes through the other 4948 to the local director. The local director will generally use one of the paths to send traffic to the core and let us assume that it uses the path that goes to coreA. So it is sending traffic and the 4948 and coreA are seeing the source MAC address and refresh their mac address table. coreB and its 4948 are not seeing traffic from the local director and so their entry in the mac address table ages out. It is not refreshed because they are not seeing traffic from the local director. Now assume that a packet comes to the core to be routed to the local director. And assume that this packet comes to coreB. It will look for how to get to the local director. There is an entry in arp which points to the 4948 associated with coreB. But the mac address table does not have an entry for that mac. So it creates unicast flooding.

As for your question about why is the arp table of the 6500 involved I believe that the answer is that if you are doing layer 3 routing then you use the arp table of the layer 3 device which is doing the routing - and that is the 6500.

HTH

Rick