Unicast traffic from hosts with static IPs

Brian Slattery · ‎01-28-2010

I have an issue that I and my colleagues have been trying to figure out.

We have three Catalyst 4500 series switches in service, and they are all configured with DAI (which includes/requires DHCP snooping). While doing some sample sniffs on our VLANs, we found that there were more than a few instances of unicast traffic being sent out as broadcast.

After analyzing things further, we determined a few things:

1. The traffic was involving devices that have statically assigned IP addresses

2. Obviously, there was no DHCP snooping binding entry for the corresponding host on the switch it is connected to

3. There are ARP table entries for the hosts on all three switches, but the hosts’ MAC table entries are only on the switch they are connected to

For some reason I’m getting this impression that there is some correlation between the propagation of the MAC table entries and the DHCP snooping. However, I have no solid basis to confidently say that DHCP and DHCP snooping are the reasons why the layer 2 information is propagating. It does seem to be somewhat obvious to resolve, but there HAVE to be some others out there who have this same kind of scenario.

Any and all counsel on this will be greatly appreciated.

Brian Slattery · ‎02-01-2010

Anybody?

Somebody?

Nobody?

Still plugging away with this, but really would like to touch base with others who have implemented security measures and come across this sort of issue (a few static hosts with mostly DHCP, with DAI and DHCP snooping)...

Again, any and all assistance will be greatly appreciated.

Brian Slattery · ‎02-03-2010

OK, an update....

Continuing to investigate this and found that this is NOT limited to hosts with a static IP address. It appears that this might be an IOS code issue.

All three 4500 series switches are running v12.2(53)SG.

Is anyone else out there with 4500 series boxes experiencing this same kind of issue?

mlund · ‎02-08-2010

Hi Brian

When You say Unicast is send as broadcast, I assume You mean Unicast ip address is sent as a layer2 broadcast frame.

If that is the issue You may have run into the unicast flooding problem that is described in this link

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml

/Mikael

Brian Slattery · ‎02-09-2010

Mikael,

Yes, we're seeing the traffic being broadcast out on all ports for that VLAN on the other switches that the host is not connected to. I did refer to the link/document you've provided, but we've been able to rule out two of the three potential causes. We're not experiencing any "flapping" on the spanning tree (we have things set up weighted a specific way, so there shouldn't be many changes in topology for our primary data networks). The forwarding table(s) are not overflowed, and (as already mentioned) it appears that the MAC/CAM information is not propagating amongst the switches as it should be.

I'm still checking things to make sure I've ruled out the asymetrical routing as the cause, but it doesn't appear that it is the issue (but stay tuned). We are believing that this may be a code issue with IOS as we are seeing some other "oddball" things on these switches. But if anyone else can offer insight, please don't hesitate...

Thanks for your help!

mlund · ‎02-10-2010

Hi Brian

Have You tryed what the document suggest with asymetric routing. To configure the "arp-timeout" and the "cam-aging timeout" to be the same value. Default values is 300 seconds for cam-aging and 14400 seconds for arp-timeout. Because this is the most common reason for flooding. Also its a very quick configuration to do. There are three different solutions to this.

1 configure arp time out to be 300 seconds. This will generate quite a lot of arp queries.

2 configure the cam aging to be 14400 sconds. This can lead to a huge cam-table

3 configure both values to something in between.

/Mikael