Unicast traffic from hosts with static IPs

Unanswered Question
Jan 28th, 2010
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Brian Slattery Mon, 02/01/2010 - 08:12
User Badges:

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 Wed, 02/03/2010 - 11:13
User Badges:

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?

Brian Slattery Tue, 02/09/2010 - 11:31
User Badges:

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 Wed, 02/10/2010 - 02:35
User Badges:
  • Silver, 250 points or more

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

Actions

This Discussion

Related Content