ARP is Filled with IPs

RouterOS General
1

Hi,

Recently I observed both Mikrotiks in my workplace and home the ARP list are filled with IPs. I don’t remember seeing so many IPs when they were using RouterOS 6.

ChatGPT suggested these which I had followed:

  • turning off “Add ARP for Leases” in the DHCP server
  • turning off Dude (only my workplace mikrotik has the Dude feature)

But the next day the ARP is filled again. Is it something I should be concerned?

Thank you

henry

[admin@CGS10-1] > /ip arp print
Flags: H - DHCP, D - DYNAMIC; C - COMPLETE
Columns: ADDRESS, MAC-ADDRESS, INTERFACE, STATUS
 #    ADDRESS         MAC-ADDRESS        INTERFACE   STATUS   
 0 HC 192.168.1.10    :AD:34:39:83:71  bridge      permanent
 1 HC 192.168.1.59    :97:F6:3F:68:88  bridge      permanent
 2 HC 192.168.1.9     :4D:28:A2:50:55  bridge      permanent
 3 HC 192.168.1.58    :D5:47:82:33:30  bridge      permanent
 4 HC 192.168.1.252   :8B:B9:26:DB:7C  bridge      permanent
 5 D  192.168.1.55                     bridge      failed   
 6 D  192.168.1.74                     bridge      failed   
 7 HC 192.168.1.39    :70:EA:48:DE:C1  bridge      permanent
 8 D  192.168.1.79    :C8:0C:05:8B:93  bridge      failed   
 9 D  192.168.1.66                     bridge      failed   
10 D  192.168.1.83                     bridge      failed   
11 D  192.168.1.75                     bridge      failed   
12 D  192.168.1.82                     bridge      failed   
13 D  192.168.1.84                     bridge      failed   
14 D  192.168.1.85                     bridge      failed   
15 D  192.168.1.89                     bridge      failed   
16 D  192.168.1.90                     bridge      failed   
17 D  192.168.1.93                     bridge      failed   
18 DC 192.168.1.99    :41:D4:CB:84:F9  bridge      stale    
19 D  192.168.1.101                    bridge      failed   
20 D  192.168.1.100   :41:D4:CB:84:F9  bridge      failed   
21 D  192.168.1.102   :41:D4:CB:84:F9  bridge      failed   
22 HC 192.168.1.56    :EE:15:77:79:51  bridge      permanent
23 DC 192.168.1.108   :41:D4:CB:84:F9  bridge      stale    
24 D  192.168.1.107                    bridge      failed   
25 HC 192.168.1.118   :64:CF:E8:85:75  bridge      permanent
26 D  192.168.1.119                    bridge      failed   
27 D  172.17.1.2                       bridge      failed   
28 D  192.168.1.121                    bridge      failed   
29 DC 192.168.1.112   :41:D4:CB:84:F9  bridge      stale    
30 DC 192.168.1.122   :41:D4:CB:84:F9  bridge      stale    
31 HC 192.168.1.80    :F8:53:20:EC:01  bridge      permanent
32 D  192.168.1.129                    bridge      failed   
33 D  192.168.1.130                    bridge      failed   
34 DC 192.168.1.123   :41:D4:CB:84:F9  bridge      stale    
35 HC 192.168.1.52    :90:8A:4F:32:6B  bridge      permanent
36 D  192.168.1.131                    bridge      failed   
37 D  192.168.1.135                    bridge      failed   
40 D  192.168.1.116                    bridge      failed   
41 D  192.168.1.120                    bridge      failed   
47 HC 192.168.1.54    :FD:A1:0D:17:38  bridge      permanent
54 DC 192.168.1.134   :41:D4:CB:84:F9  bridge      stale    
56 D  192.168.1.132                    bridge      failed   
59 D  192.168.1.63                     bridge      failed   
60 HC 192.168.1.139   :41:D4:CB:84:F9  bridge      permanent
61 HC 192.168.1.51    :35:7B:F9:84:EF  bridge      permanent
62 HC 192.168.1.60    :A1:59:44:64:95  bridge      permanent
63 HC 192.168.1.53    :90:8A:53:C1:95  bridge      permanent
65 HC 192.168.1.253   :11:A5:81:21:F4  bridge      permanent
66 DC 192.168.1.50    :D0:03:AA:31:C6  bridge      stale
2

might be something or someone scanning the subnet

any netwatch scripts running or is a “tools > IP scan” running (frequently)?

3

Those entries with IP but without MAC address mean that some process on router is trying to communicate with those IP addresses but there are no machines with those addresses on your LAN (or they didn't reply).
That some process might either be some router's service. E.g. DHCP server which is checking availability of IP address before leasing it out ... but if the IP address is not in use, DHCP server would offer it to client and then client would reject it due to some reason ... and some reasons are legitimate. Or it could be routing engine (some dst NAT setting or some such).
IMO it's not a good sign if router (or any LAN device's for that matter) ARP table gets filled with invalid entries (with status failed), it does indicate something weird is going on. So I'd definitely investigate into this.

And yes, it does seem that ROS v7 doesn't remove stale and failed ARP entries any time soon, probably it depends on maximum size of ARP table and number of entries ... ROS might start removing unusable entries when table gets close to full.

4

Having entries in /ip/arp table means that it's router's IP stack doing it ... or that something external is targeting router's IP stack (and even then entries would contain some sort of MAC address, I don't think that any ethernet frame, sent over the wire, can have empty src MAC address field ... and ARP table would contain that MAC address).
If it was something external doing it and targeting random network devices, then those entries would not end up in /ip/arp table, but rather /interface/bridge/host table (or /interface/ethernet/switch/host table or both). And this table (or both as a matter of fact) don't contain IP (or IPv6) addresses since they are irrelevant in L2 context.

@gnulab if your LAN is IPv6-enabled, check also /ipv6/neighbor table ... it might contain some invalid entries as well.

5

What is the ARP setting on the bridge interface? Do you have it set to local-proxy-arp maybe?

On my interfaces, I always prefer to arp=reply-only whenever possible. Of course, using that setting then "Add ARP For Leases" must be turned on in the DHCP server, and most importantly, every device not using DHCP will have to have the ARP entries manually added to the ARP table first. But once that's done, issues like yours are avoided.

6

While setting arp=reply-only does avoid problems with ARP table filling up with unsolicited entries, it doesn't fix the underlying problem (if there is any). It only offsets it to another device (or multiple of them) ... which indeed might allow for easier detection of plaintiff.

It's worth reminding that this setting only works where either router is sole DHCP server in the network(s) or if there are only devices with static IP settings in network(s). The former might be very common in SOHO environments while the latter is very uncommon in modern times.

7

Off the back of this, I took a look at my ARP lists and found plenty of failed entries. But I recognised all the IP addresses. Something which might happen is to access the network with mobile phones which are set to use radomised MAC addresses, in which case, I would expect to see similar.

8

Could be. I can inagine seeing such ARP entry after device drops off network while router still wants to send it some data (e.g. because there were still open connections and internet side tried to send something) but MAC address got stale ... and ARP whohas procedure did not yield any result.
And yes, if device used randomized MAC addresses, it would receive a new IP address after reconnection ...