Solved: IP DHCP snooping question

Siemens_SWP · ‎11-30-2009

Hi

We resently have a lot of log entrys in our switches regardig DHCP snooping. Like thise two:

007850: Nov 26 09:02:55.484 CET: %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPRELEASE, chaddr: 0016.4487.6527, MAC sa: 0017.422e.d204

007846: Nov 26 08:47:40.740 CET: %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPREQUEST, chaddr: 0016.4487.6527, MAC sa: 0017.422e.d204

What could cause this problem? The chaddr is the MAC of the wireless NIC and the MAC sa is the MAC of the "wired" NIC in the same machine.

Hope anyone can help.

Mikkel

Peter Paluch · ‎12-01-2009

Hello,

The switch logging message basically says that the MAC address of the client contained in the chaddr (client hardware address) field in the DHCP message does not match the source MAC address of the frame in which the DHCP message is encapsulated. In other words, the interface for which the DHCP message was created does not match the interface through which the message was actually transmitted.

Is it possible that both the wireless and wired NIC in this machine are connected to the same network? If so then this is an issue of your operating system running on the machine - probably it uses both NICs and the NIC that transmitted the DHCP message was just not the one for which the DHCP packet was created. Note that it is not advisable for an ordinary PC or workstation to be connected by multiple NICs to the same network, as the operating systems usually are not capable of using both NICs appropriately.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎12-01-2009

Hello,

The switch logging message basically says that the MAC address of the client contained in the chaddr (client hardware address) field in the DHCP message does not match the source MAC address of the frame in which the DHCP message is encapsulated. In other words, the interface for which the DHCP message was created does not match the interface through which the message was actually transmitted.

Is it possible that both the wireless and wired NIC in this machine are connected to the same network? If so then this is an issue of your operating system running on the machine - probably it uses both NICs and the NIC that transmitted the DHCP message was just not the one for which the DHCP packet was created. Note that it is not advisable for an ordinary PC or workstation to be connected by multiple NICs to the same network, as the operating systems usually are not capable of using both NICs appropriately.

Best regards,

Peter

marcaccini · ‎02-19-2012

Any recommendations on keeping the wireless NIC from begin active when the user's laptop is docked? We are currently using DELL Lattitude E6520's running Windows 7. I have found a few applications out there that will do this for a fee, but would ideally like to implement this without having to pay for a third party application. ( hard to justify a budget expense for 3,500 machines )

Ken Elliott · ‎08-20-2019

I too have had a similar issue though mine was pointing to an ATA device thus the wireless nic solution was not relevant to me:

My error logs were thus:

Aug 20 08:47:41: %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPDISCOVER, chaddr: f62b.ac74.f4bc, MAC sa: dceb.941c.6671

Of the two MAC addresses the 2nd one the MAC sa: was the address of the ATA......

I have so far been unable to locate the first MAC address but it doesn't seem to be present anywhere within my local network??

Any suggestions??????

Scott Plank · ‎03-10-2023

@Ken Elliott wrote:
I too have had a similar issue though mine was pointing to an ATA device thus the wireless nic solution was not relevant to me:
My error logs were thus:
Aug 20 08:47:41: %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPDISCOVER, chaddr: f62b.ac74.f4bc, MAC sa: dceb.941c.6671
Of the two MAC addresses the 2nd one the MAC sa: was the address of the ATA......

I have so far been unable to locate the first MAC address but it doesn't seem to be present anywhere within my local network??
Any suggestions??????

I realize this about 4 years old, but we just had a similar issue with an ATA 190. Like yours, the chaddr was not present anywhere as far as we could tell - when I tried to look up the vendor on Wireshark's OUI tool, there were no results, same as yours when I tried looking it up.

%DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop message because the chaddr doesn't match source mac, message type: DHCPDISCOVER, chaddr: 6eeb.19ff.367c, MAC sa: dceb.941d.370a

I shutdown the port that the ATA was on for about 5 minutes, removed the DHCP entry for the ATA on our DHCP server, and cleared the DHCP snooping entry on the switch. After turning the port back on, I am no longer getting the log messages. Time will tell if it stays that way. Perhaps this will help others seeing this same issue.