"arp: moved from to" -> howto stop them?

How to stop these ARP messages on my FreeBSD 8.2 server?
Code:
# tail -f /var/log/messages
Apr  9 16:41:18 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:18 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
Apr  9 16:41:22 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:22 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
Apr  9 16:41:28 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:28 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
Apr  9 16:41:41 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:41 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
Apr  9 16:41:45 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:45 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
Apr  9 16:41:51 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:67:1b to 00:06:5b:f7:65:1c on em0
Apr  9 16:41:51 bsd kernel: arp: 192.168.1.87 moved from 00:06:5b:f7:65:1c to 00:06:5b:f7:67:1b on em0
 
You should have a net.link.ether.inet.log_arp_movements sysctl; change it with [cmd=]# sysctl net.link.ether.inet.log_arp_movements=0[/cmd] If this works for you, don't forget to put it in /boot/loader.conf.
 
novemberico said:
You should have a net.link.ether.inet.log_arp_movements sysctl; change it with
Code:
# sysctl net.link.ether.inet.log_arp_movements=0
If this works for you, don't forget to put it in /boot/loader.conf.

Thanks, I've done that, restarted the server, but it still doesn't work. BTW, what should I put in /boot/loader.conf?
 
This happens if you have one or more interfaces on the same subnet.
 
Not necessarily. It also happens on a DHCP network where people sometimes try to set their IP address (or re-use their lease, or add a second device) by hand. I see it on a bridging firewall with DHCP clients on the inside.

Code:
arp: xx.xx.198.233 moved from ..:0c:f6:c5:bb:.. to ..:f1:a1:f6:29:.. on em1
arp: xx.xx.142.114 moved from ..:07:54:7b:9c:.. to ..:cd:60:a9:36:.. on em1
arp: xx.xx.142.114 moved from ..:cd:60:a9:36:.. to ..:07:54:7b:9c:.. on em1
arp: xx.xx.198.198 moved from ..:e4:00:22:9c:.. to ..:0c:f6:c5:bb:.. on em1
 
Agreed, but the MAC addresses are too close for comfort ;)
 
Guess, could be some sort an ARP poisoning, your DHCP client manually add or change MAC/IP, load balancing/interfaces bonding somewhere, or if both interfaces belong to your host, put them in the same network segment with the same subnet.
Doesn't have enough information to pinpoint :(
 
Another reason for the MAC address to change is using bonjour capable devices with a bonjour sleep proxy on the network. When the device goes to sleep, the sleep proxy (which is now responding on behalf of the sleeping machine) sends out a gratuitous ARP so that devices which try to contact the sleeping machine actually hit the sleep proxy (when then wakes the destination).
Sleep proxies are devices like Airport Express/Extreme and Apple TVs (low power, always on).
 
All of the changes logged in the original post happened in 33 seconds, so if it is a sleep proxy it is a broken one.

I say, identify the problem. Something is misconfigured, somewhere. Who is 192.168.1.87? Was this address assigned by DHCP and/or a (rogue) manual assignment? Are 00:06:5b:F7:65:1c and 00:06:5b:F7:67:1b two NICs in one machine, or in separate boxen? BTW - OUI 00:06:5b belongs to Dell Computer Corp.

My Cisco SGE2000P switches will let me query the address tables in the switch stack and identify the unit/port that a MAC address is connected through. Then I could find the box if the labels are good enough, or disconnect the port and see who screams :). Maybe you have switches that can do a similar trick...
 
Perhaps the machine is running as guest on a Hypervisor which has a trunk to the network.
Depending on the LB Method I'm seeing this also in my environment.
 
Back
Top