Introduction
ARP flapping is a process in which two or more MAC addresses repeatedly alternate for a single IPv4 address on a network. This causes continuous reprogramming at the switch ASIC processor level, resulting in network instability. This guide describes the most common causes of ARP flapping, detection methods, and protection mechanisms.
What is ARP and how does it work?
ARP (Address Resolution Protocol) translates IP addresses into MAC addresses within a local network. Without it, devices would know where a packet a packet’s destination but would be unable to deliver it to the correct network interface.
When a device wants to communicate with another IP address on the same network, it sends a broadcast query to the entire segment: “Who has IP address [xxx.xxx.x.x]?” The owner of the IP address responds directly and includes its MAC address to specify where the data should be delivered. The requesting device stores this response in its ARP table for subsequent communication, eliminating the need for repeated queries.
What is ARP flapping?
ARP flapping occurs when two or more MAC addresses repeatedly alternate for a single IP address on a network. Each MAC address change forces the switch ASIC tables to reprogram. As a result, the switch cannot reliably determine which port traffic should be forwarded to. If these changes occur at short intervals, they can cause brief connectivity outages, packet loss and overall network instability.
A single IP address should always be associated with only one MAC address. Even virtual IP addresses do not use multiple MAC addresses simultaneously; instead, high-availability technologies typically share a single virtual MAC. Repeated alternation between MAC addresses therefore usually indicates a configuration error, a network loop or another network-related issue.
Causes of ARP flapping
ARP flapping can be caused by configuration errors as well as intentional malicious actions on the network. You may encounter the following issues.
Duplicate IP address
The most common cause is assigning the same IP address on two different devices or interfaces with different MAC addresses. Both devices then respond to ARP requests, causing inconsistent mapping entries.
To resolve this issue, identify all devices within the VLAN that use the affected IP address and remove any duplicates. We recommend checking ARP tables on devices, performing a network scan (IP scan), or using an IP conflict detection tool.
Incorrect bonding configuration
With an incorrectly configured bonding setup, traffic using the same IP address may leave through multiple physical interfaces with different MAC addresses. The switch then sees the same IP address alternately coming from different ports and MAC addresses, which it identifies as ARP flapping.
To prevent this behaviour, the bonding configuration on the server and switch must match. The procedure for correctly configuring bonding (link aggregation) in MasterDC is described in the guide on using LACP technology.
ARP flux in Linux
Linux uses the weak host model, where IP addresses are not strictly bound to a specific interface. If a server has multiple network interfaces, an ARP request may arrive on a physical network interface such as eth0, while Linux responds via eth1, which has a different source MAC address. This behaviour is known as ARP flux. The switch then sees responses for the same IP address arriving from different MAC addresses and reports ARP flapping.
How to prevent ARP flux in the Linux kernel
The following procedure makes a permanent configuration change that remains in effect after a system restart. Configure the parameters on the interface connected to the network where ARP flux occurs – in the example below, this is eth0. Adjust the interface name according to your server’s actual configuration.
- Open the
/etc/sysctl.conffile. - Add the following lines:
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2 - Apply the changes using the command:
sysctl -p
Parameter details:
arp_ignore = 1– Linux responds to an ARP request only if the queried IP address is configured on the incoming interface. This prevents responses from being sent through an incorrect interface with a different MAC address.arp_announce = 2– When sending ARP requests, Linux always selects the source address that best matches the outgoing interface. This prevents the system from advertising the IP address of another interface.
ARP spoofing and ARP poisoning
If configuration-related causes have been ruled out and ARP flapping persists, it may be the result of a deliberate attack. An attacker on the local network repeatedly sends forged ARP replies claiming that the IP address of the default gateway or another critical server belongs to the attacker’s MAC address. This allows the attacker to execute a Man-in-the-Middle attack to eavesdrop on traffic, modify transmitted data or disrupt communication entirely.
A typical scenario involves a compromised virtual machine on the local network that sends spoofed ARP replies to intercept traffic from neighbouring servers within the same VLAN.
How to detect ARP flapping
You can display the current ARP table on a host using the following commands:
- Linux and macOS:
arp -na - Windows:
arp -a
If you want to capture MAC address alternation, run the command repeatedly at short intervals and compare the outputs. If you suspect a duplicate IP address is the cause, we also recommend performing a network scan or using an IP conflict detection tool.
Protection against ARP flapping
Measures to prevent ARP flapping can be implemented both at the network infrastructure level (if you manage your own switches as part of a Rack Housing service) and directly within the operating system of individual servers.
Protection at the network level
If you manage your own network devices (typically with the Rack Housing service), implementing network security features is the most effective way to prevent unauthorised changes to ARP tables. The following technologies actively verify the legitimacy of network traffic:
- Dynamic ARP Inspection (DAI): A security feature where the switch monitors passing ARP packets and compares them against a database of trusted IP-to-MAC bindings (typically created through DHCP snooping). If it detects an attempt to spoof an ARP reply from an unauthorised MAC address, the switch immediately drops the packet and logs the incident.
- Port Security (MAC Limiting): This feature limits the maximum number of unique MAC addresses that can communicate through a given switch port. It helps prevent situations where an unexpectedly large number of MAC addresses appear on a single port or where MAC addresses change too frequently.
Protection at the operating system level
Additional protection methods can be implemented directly within the server operating system. While correctly configuring sysctl parameters (see the ARP flux in Linux section above) helps prevent inconsistent ARP responses on the server side, the following methods are primarily intended to protect against misconfigurations on other devices or ARP spoofing attacks.
Active monitoring (arpwatch)
For long-term monitoring of ARP communication, the arpwatch utility is recommended. It continuously tracks IP-to-MAC address bindings and alerts to any changes. When configured correctly, it can automatically send email notifications about newly detected or modified ARP entries.
Filtering using the Linux firewall
In Linux, ARP traffic can also be filtered using firewall rules. This method allows only trusted IP-to-MAC address bindings and actively blocks spoofed ARP replies.
On older systems, ARP traffic filtering is typically performed using arptables, while modern systems generally utilise nftables.