Error in log: Detected conflict by arp response

RouterOS General
1

Hello! Please kindly explain, what means this error:
detected conflict by arp response for 192.168.x.x from ff:ff:ff:xx:xx:xx
I can see it repeatidly with different ip and mac addresses.

1 Like
2

In what context? Post exact log lines (with a few preceding lines) …

3

First example:

07:48:32 dhcp,info dhcp-server-VB-OF assigned 192.168.1.170 to 8C:16:45:B1:37:C7 
07:49:24 dhcp,info dhcp-server-VB-OF deassigned 192.168.1.209 from 94:DE:80:4C:4C:25 
07:49:25 dhcp,info dhcp-server-VB-OF deassigned 192.168.1.191 from 88:D7:F6:3C:4A:10 
07:49:30 dhcp,info dhcp-server-VB-OF assigned 192.168.1.202 to 10:7B:44:8F:2B:AA 
07:50:52 dhcp,info dhcp-server-VB-OF assigned 192.168.1.191 to 88:D7:F6:3C:4A:10 
07:51:23 dhcp,info dhcp-vlan30-guests assigned 192.168.30.237 to DC:72:9B:7F:99:F6 
07:53:13 dhcp,warning Detected conflict by ARP response for 192.168.1.220 from 00:17:C8:21:83:A4 
07:53:55 dhcp,info dhcp-vlan30-guests assigned 192.168.30.241 to 00:EC:0A:CB:23:14 
07:54:10 dhcp,warning Detected conflict by ARP response for 192.168.1.222 from 00:C0:EE:3A:99:FD

Second one:

11:30:53 dhcp,info dhcp-vlan30-guests deassigned 192.168.30.252 from 40:3F:8C:08:45:0F 
11:30:53 dhcp,info dhcp-vlan30-guests assigned 192.168.30.252 to 40:3F:8C:08:45:0F 
11:36:01 dhcp,info dhcp-server-VB-OF assigned 192.168.1.229 to 94:DE:80:95:AF:5C 
11:47:08 dhcp,info dhcp-server-VB-OF assigned 192.168.1.231 to DC:72:9B:7F:99:F6 
11:47:52 dhcp,info dhcp-server-VB-OF assigned 192.168.1.232 to 50:46:5D:53:22:53 
11:48:40 dhcp,warning Detected conflict by ARP response for 192.168.1.234 from 00:17:C8:3B:2D:14
4

When DHCP server sends DHCP offer, it first checks if address to be offered is actually in use (it uses ARP for that). And if it receives answer, then it offers another address. The same check is then performed by DHCP client …

Reasons for addresses to be occupied despites they should not be according to DHCP server’s tables, are numerous:

  • There’s more than one DHCP server running in same L2 (ethernet, VLAN) network offering leases from overlapping address pool
  • There’s a device configured with proxy-arp and acts for addresses which it should not
  • There are devices statically configured with addresses from within the pool
  • DHCP server restarted without properly writing out lease database
  • …

So you should try to find out the exact reason … MAC address of the offending device should give you a hint (you can get device vendor from MAC address, there are lookup services on the web … all 3 MACs seem to belong to various Kyocera devices, some printers/MFDs?).

5

Thanks! Its Kyocera devices with static addresses. Why I havent seen this errors in log before?.. I`ll try add them as exeptions.

6

If you can’t change addresses on Kyocera devices (to some addresses outside DHCP pool), then you can set up static leases for those MAC addresses … if you ever reconfigure Kyoceras to use DHCP for network configuration, they’ll keep same IP addresses.

Why you never saw those logs before? Could be that log settings changed to include additional info … or DHCP server started to check address availability (that check wasn’t part of initial DHCP specification) … or something completely different.

7

Resurrecting this thread because I have a similar unsolved problem.

13:59:46 dhcp,warning Detected conflict by ARP response for 10.1.0.67 from F8:B1:56:72:48:05
14:31:40 dhcp,warning Detected conflict by ARP response for 10.1.0.66 from F8:B1:56:72:48:05
14:57:10 dhcp,warning Detected conflict by ARP response for 10.1.0.65 from F8:B1:56:72:48:05
15:29:04 dhcp,warning Detected conflict by ARP response for 10.1.0.64 from F8:B1:56:72:48:05
16:00:57 dhcp,warning Detected conflict by ARP response for 10.1.0.63 from F8:B1:56:72:48:05
16:26:27 dhcp,warning Detected conflict by ARP response for 10.1.0.60 from F8:B1:56:72:48:05
16:58:21 dhcp,warning Detected conflict by ARP response for 10.1.0.59 from F8:B1:56:72:48:05
17:30:16 dhcp,warning Detected conflict by ARP response for 10.1.0.58 from F8:B1:56:72:48:05

This phanton mac address is picking down the IP list every 30 minutes. Has anyone ever seen a similar behavior?

A few odd facts:

Its a Dell switch, but the actual MAC is a few digits off from burned in MAC of the switch. Someone suggested it was MACs being issued at the port level but this idea never went anywhere.

The other symptom is the switch keeps getting kicked off of its IP to a new IP and its a mess to find the latest IP it gets.

What would cause such a pattern of behaviors?

8

What would cause such a pattern of behaviors?

There are many options:
-Some device using “Proxy ARP” function
-Hypervisor HOST/Guest-VM using “Proxy ARP” function
-Misconfigured machine “bridged ethernet card”
-Attacker ARP spoofing / Man-in-middle - Rough device
-Switching loop

9

I took the step of making whatever IP the switch had in the moment fixed. That has the result of stopping the barrage of IP conflicts and rolling IP addresses, but now the switch has largely disappeared from my network, though still switching.

/interface bridge host print

31 D E F8:B1:56:72:48:04 ether7 bridge1

I am stuck here trying to find the IP address. It should be 10.1.0.103 which is what I left it at, but it no longer responds to that address either by browser, or IP. Ping returns destination host unreachable. I tried to ping on the router as well and nothing.

How can I get to its current IP from the bridge host print statement?

10

Hello community, I recently had a Mikrotik dhcp warning, “Detected conflict by ARP response for ….” and the DHCP leases reporting “conflict” as status and MAC address is always 00:00:00:00:00:00.

My research points to it being ether a rogue DHCP server on the network, or proxy ARP device.

image
image1038Ă—515 113 KB

I tried these steps:

  1. Check for devices with static IPs: Look for any devices with manually configured static IP addresses that fall within the DHCP pool's range and remove the static configuration or exclude the IP from the DHCP scope.

  2. Examine the ARP table: Go to IP > ARP in your MikroTik router. Look for any IP addresses listed with a "00:00:00:00:00:00" MAC address and try to identify the conflicting device.

  3. Check for other DHCP servers: Ensure there isn't another DHCP server running on the same network that is competing for the same IP addresses.

  4. Clear ARP cache and reboot devices: If the issue is with a device that has a dynamic IP, try clearing its ARP cache and then rebooting it. You may also need to reboot the MikroTik router to clear any stale information.

  5. Inspect the DHCP server settings: On your MikroTik, enable "Conflict Detection" in your DHCP server settings if it's not already. Also, consider enabling "Add ARP For Leases" on the DHCP server and setting ARP mode to "reply-only" on your bridges to prevent the router from sending ARP queries and to ensure it only trusts its own ARP table.

  6. Use a packet capture: As a more advanced step, you can use a packet capture on the MikroTik and filter for udp port 67 or 68 to see what devices are actively requesting or responding on the DHCP ports.

I have tried searching using Wireshark and Torch to search for dhcp, bootp, udp 67 and 68, and not found any conclusive device that is broadcasting.

and updated the DHCP defconf settings to “Add ARP for Leases” and “Conflict Detection” options to checked.

On bridge set ARP setting to “reply-only” and DHCP Snooping is set to on.

This conflict only began two days ago, and is completely bogging up my dhcp system.

Any gurus feedback, ideas, experience is most welcome. Thank you.

11

I figured out a workaround for now. Wrote and scheduled a script that cleans up all status = conflict every 10 seconds. I still need to understand WHO the rogue dhcp server/device is with no mac ie 00:00:00:00:00:00.

I am open to suggestions how to determine this conflict anomaly from MAC 00:00:00:00:00:00. :slight_smile:

Here’s my script

":foreach i in=[/ip dhcp-server lease find status=conflict] do={
:if ([:len [/ip dhcp-server lease get $i mac-address]] = 0) do={
/ip dhcp-server lease remove $i;
}
}"

12

You might try to filter by ARP protocol (instead of UDP 67/68) to see if those conflicts are actually due to ARP discovery. Read Wireshark article about it.

1 Like
13

i blocked the mac address from the bridge and it worked for me

  1. Chain: input

  2. In-Bridge: Select your bridge (e.g., bridge20)

  3. Src. MAC Address: 18:FD:....... (the actual mac adress of the device)

  4. Action: drop