Anyone know what this DHCP Snooping error means? I have DHCP snooping configured on an access switch. The ports that are indicated in this error message are the uplink ports. Which are not blocked as our DHCP servers sit off the distribution layer of our network.
2009 Jan 09 11:47:02 est -05:00 %DHCPSNOOPING-5-PKTDROP:Packet dropped -- port 1/2 on vlan 728
2009 Jan 09 11:47:10 est -05:00 %DHCPSNOOPING-5-DESTNOTFOUND:DHCPOFFER: Could not find destination port. Destination MAC 52-41-53-20-30-63
I am not sure where that MAC address is coming from? Seems like a client requested DHCP, the DHCP Offer was initiated by DHCP server, however the switch does not have that MAC in it's CAM table.
Any thoughts? It does not appear that this message is pointing to an actual rogue DHCP server. Those packets would be blocked at the access ports and logged with the access port information.
IN that past the main reason for this is the mac address 52-41-53-20-30-63 is getting purged due to inactivity, not so much as the device is not talking but due to asymetrical path. The DHCP sends it's offer one way while the response or the regular traffic from this device takes another path. Usually you will see this when there is dual path to other network from the device with mac address 52-41-53-20-30-63. Rigid workaround is to set static cam entry on 1/2 but the main solution would be to determine the asymetric path/route and tyr to correct that.
you can further confirm that the device stops sending traffic to this switch by looking at trace route from the device with mac 52-41-53-20-30-63 and trace route from the destination. To further clarify:
A traceroute to B
B traceroute to A
Compare the next hop of each traceroute to see if the packet from A to B or any other host is actually taking an alternate path. The result of this would aged out the cam entry on the switch logging the message. There is no other performance issues other than this message, correct?
Thanks for the response. I ended up making some progress on this. I'll explain.
I could not find that MAC 52-41-53-etc anywhere on the access switch or in the router arp tables. So I could not even go the client to do traceroutes, etc to confirm asymetric paths.
So I ended up monitoring the DHCP server logs and sure enough a DHCP DISCOVER was coming in with that source MAC 52-41-53-etc. Luckily, a device name was listed in the log message.
So I checked for that device name in my DHCP lease pool for that subnet and sure enough I found a different MAC address and an associated IP listed with it. Using that MAC address I was able to locate the access port and disable. Once I did this the errors went away.
So the client did have a real mac and IP. However, it must have also had some rogue process on it that was sending out these DHCP DISCOVERS with that bogus MAC. Because the MAC was not in the switches CAM or DHCP binding tables, DHCP snooping dropped the DHCP OFFER packets upon their return to the access switch.
This makes sense correct? Thanks again for your suggestion.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...