DHCP Snooping Error

c.fuller · ‎01-09-2009

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.

Roberto Salazar · ‎01-09-2009

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?

hope that helps.

c.fuller · ‎01-09-2009

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.

Roberto Salazar · ‎01-09-2009

Strange but the DHCP snooping did it's job by preventing assigning ip address to a non-existing mac-address.

Giuseppe Larosa · ‎01-09-2009

Hello Charles,

I agree and I would add the following note:

52-41-53-etc

this should'nt be a valid unicast MAC address having the lsb of MSB set to 1 this is a multicast MAC address (I/G bit set to 1) and so it should be filtered out the switches CAM tables.

I see some time errors of a multicast MAC address seen as source and if I look at the CAM table I never find them even if I see the log message and I look for them.

For this reason I think you couldn't find that MAC address.

And perhaps for this the DHCP snooping didn't block the request if it relies on CAM table.

Hope to help

Giuseppe