Kernel Log "ARP moved from ... to ... on igb0"

[zoomzoom]

I assume I'm receiving hundreds of lines of the following in the kernel log due either to verbosity set to high, or something to do with utilizing static IPs/bug in WRT1900ac firmware.

Code:

FreeNAS kernel log messages:
> arp: 192.168.1.15 moved from xx:xx:xx:xx:xx:58 to xx:xx:xx:xx:xx:64 on igb0
> arp: 192.168.1.15 moved from xx:xx:xx:xx:xx:58 to 00:15:5d:12:a0:00 on igb0
> arp: 192.168.1.15 moved from xx:xx:xx:xx:xx:64 to 00:15:5d:12:a0:00 on igb0
> arp: 192.168.1.15 moved from 00:15:5d:12:a0:00 to xx:xx:xx:xx:xx:64 on igb0
...

AW18

• xx:xx:xx:xx:xx:58 (Ethernet)
• xx:xx:xx:xx:xx:64 (WiFi)
• 00:15:5d:12:a0:00 (virtual MAC for AW18's Hyper-V Ad Hoc vLAN)
  • This vLAN is not served by any DHCP server, has no gateway or DNS server, and a subnet of 192.168.100.100/30
  • This is utilized only to share data with VMs

Please Note​

• I utilize Sophos UTM for my WAN facing router (subent 192.168.1.1/26), with DHCP served by my WRT1900ac v1 (subnet 192.168.1.62/26)
  • The FreeNAS server is routed separately through both Sophos UTM (192.168.1.64/26, IP 192.168.1.101) and WRT1900ac (192.168.1.1/26, IP 192.168.1.20)
    • Subnet 192.168.1.1/26 is served via Sophos on eth0 - 1
    • Subnet 192.168.1.64/26 is served via Sophos only on eth2
    • WAN is connected via Sophos on eth3
  • WAN & LAN are bridged on the WRT1900ac, with it's input connection [WAN] receiving DNS from 192.168.1.1, and all devices connected to the WRT1900ac [LAN 1- 4] receiving DNS from 192.168.1.62)
• The WRT1900ac is running OpenWRT DD, which currently has a bug that causes all statically assigned IPs to be listed under Active DHCP Leases with a netmask of 32 instead of 26.
  • The network itself isn't affected and all addresses served have a netmask of 26 (it's simply the Active DHCP Leases list itself has a bug )

I have a hunch this bug in the firmware of the WRT1900ac may be the culprit, but wanted to ask to be sure.

 

[m0nkey_]

This is normal behavior of devices on a network. Devices may move from MAC to MAC, for example WiFi to Ethernet and visa versa (as you have already seen). Now there is a way to suppress these messages. Go to Tasks > Init/Shutdown Scripts > Add Init/Shutdown Script and set the following:

Type: Command
Command: sysctl net.link.ether.inet.log_arp_movements=0
When: Post Init

Once set, you will need to reboot. This will prevent FreeNAS from logging the ARP movements it sees.

 

[zoomzoom]

Thanks! =]

 

[cyberjock]

This is normal behavior of devices on a network. Devices may move from MAC to MAC, for example WiFi to Ethernet and visa versa (as you have already seen). Now there is a way to suppress these messages. Go to Tasks > Init/Shutdown Scripts > Add Init/Shutdown Script and set the following:

Once set, you will need to reboot. This will prevent FreeNAS from logging the ARP movements it sees.

Or just add the value to the WebGUI directly. There's no need to script this. Just add it from system -> tunables. That's what you really *should* be doing.

 

[zoomzoom]

Will do. Thanks! =]

 

[m0nkey_]

That's what you really *should* be doing.

I agree that's the way it should work. However, I've found with my experience, a couple of tuneable's, such as setting C state or log_arp_movements doesn't work as expected when doing it that way. Unless of course this was fixed in 9.10. I'm still using my settings from 9.3.

 

[c32767a]

This is normal behavior of devices on a network. Devices may move from MAC to MAC, for example WiFi to Ethernet and visa versa (as you have already seen). Now there is a way to suppress these messages. Go to Tasks > Init/Shutdown Scripts > Add Init/Shutdown Script and set the following:

Once set, you will need to reboot. This will prevent FreeNAS from logging the ARP movements it sees.

Note that this is the kernel reporting that it's learning a new ARP mapping for an existing IP/MAC in the arp table.
Now, that could be normal operations, due to DHCP assignments or whatever..
But if you're getting that messsage frequently, it's far more likely you have 2 devices on your network that are configured to use the same IP.
If something is assigning address that are already in use via DHCP, that could be a problem.

Muting the message will make the logs cleaner, but it may hide a potential problem.