HP4000M flooding unicast traffic

[Jon Zeeff]

Do HP switches have an option
to disable the flooding
of unicast traffic when they
don't know which port to send
it to?

I find such an option important - we have some high bandwidth flows and we have
some other low (10 mbs) bw links. In no event do we want these high bw flows being sent to the slow links.
We don't find that flooding
is needed to discover the
correct port.

[Ardon]

Hi,

Yes, Cisco boxes have an option to drop unknown Unicast which would otherwise be flooded. In the ProCurve Switches 4000M/8000M there is an option called "Eaves Drop Prevention" that will the same. In other words. Any Frame with a Destination MAC different from the attached MAC will e dropped. Mind you that this of course does not apply to Layer 2 Multicast and Broadcast.

Thanks, Ardon

[Ron Kinner]

I just had a similar case on Cisco 6500 and I solved the problem so I thought I would post here just in case someone else has the problem.

We have a backup process that runs on a central server and stores the backups on a tape drive. Because it was causing major traffic jams through the gateway router, a second router was installed just for the use of the backup traffic.

Shortly after this was done the bottlenecks became worse. MRTG showed that the backup traffic was being sent to all ports on the central 6500 switch. (The backup traffic was on a 100 full duplex link to a powerful server and our link to the Internet is only 10 half so it was totally useless during backups.) After checking the source of the traffic for viruses and finding nothing, I finally hooked up a computer running snort directly to a port on the 6500. This proved the unicast backup traffic was being sent to all ports. I pinged the backup gateway and the problem went away for a while.

I poked around and found that the traffic was being sent to the correct gateway address but the returns were coming back over the old router. This meant that the switch never saw any new traffic from the new gateway so after the ARP table timeout it erased the original MAC entry (created when the system being backed up ARP'd for the backup router's MAC) and then had no idea where to send the traffic so started sending it to all ports. Correcting the route on the other end so traffic was returned the same way it came fixed the problem.


Ron

[nwengineer]

Ardon, 

Good morning! I found your posting today, which matches issue i have right now in the network. I'm wondering what's your test result with 3Com and Cisco switch regarding this unicast flooding issue. And any solution to resolve this? 

Thank you!