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.
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.
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...
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
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...