Why is my server responding to arp requests from the wrong interface on Red Hat Enterprise Linux ?

Solution Verified - Updated 5 Dec 2025

Environment

Red Hat Enterprise Linux All version
Multiple network interfaces on different subnets

Issue

On a system with two NIC's, using arpwatch we observe the IP address changing over the network interfaces:

  arpwatch: new station 192.168.100.33 0:f:20:6b:b2:5arpwatch: new station 192.168.100.33 0:f:20:6b:b2:5
  arpwatch: changed ethernet address 192.168.100.33 0:f:20:6b:b2:4 (0:f:20:6b:b2:5)
  arpwatch: flip flop 192.168.100.33 0:f:20:6b:b2:5 (0:f:20:6b:b2:4)
  arpwatch: flip flop 192.168.100.33 0:f:20:6b:b2:4 (0:f:20:6b:b2:5)
  arpwatch: flip flop 192.168.100.33 0:f:20:6b:b2:5 (0:f:20:6b:b2:4)

Dummy interface replying to external arp and ping using one of the available NICs MAC address.

Resolution

Tune the arp networking settings so that network interfaces respond only to requests destined for its IP address, and not for IP addresses belonging to other NIC's on the host:
Implement source-based routing (ie: policy-based routing) to make sure that the net.ipv4.conf.*.arp_filter sysctl parameter change (implemented later on in these steps) works correctly; See the page How to make routing rules persistent, when I want packets to leave the same interface they came in? for source-based routing implementation steps
Add the following entries to /etc/sysctl.conf:
- Configure interfaces to reply only if the target IP address is local IP address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface:
```
net.ipv4.conf.all.arp_ignore = 2
net.ipv4.conf.default.arp_ignore = 2
```
- Configure interfaces to always use the best local address for this target. Ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host.
```
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
```
- Configure all interfaces to allow you to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered based on whether or not the kernel would route a packet from the ARP'd IP out that interface (this change also requires source-based routing to be deployed and functional):
```
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
```
Either synchronize the /etc/sysctl.conf changes with the running kernel with the sysctl -p command, or also enter in each /etc/sysctl.conf change manually into the running kernel with the command sysctl -w NAME=VALUE (replacing NAME and VALUE with the respective sysctl parameter name and its value from the instructions above)
Refer to /usr/share/doc/kernel-doc-<version>/Documentation/networking/ip-sysctl.txt for more information about these settings. There are other values that might be more appropriate for your environment.

Root Cause

Linux networking does not specifically tie IP addresses to MAC addresses by default. Any NIC can respond to any arp request for an IP address that belongs to the server.
- You can use the arp_ignore function to force network interfaces to only respond to arp requests for IP addresses that they host.

The arp behavior can be tweaked using sysctl values. Please see /usr/share/doc/kernel-doc-<kernel version>/Documentation/networking/ip-sysctl.txt from the kernel-doc package). See the most relevant for this issue:

arp_filter - BOOLEAN :

        0 - (default) The kernel can respond to arp requests with addresses from other
        interfaces. This may seem wrong but it usually makes sense, because it
        increases the chance of successful communication.  IP addresses are owned by 
        the complete host on Linux, not by particular interfaces. Only for more complex
        setups like load-balancing, does this behaviour cause problems.

        1 - Allows you to have multiple network interfaces on the same subnet, and have
        the ARPs for each interface be answered based on whether or not the kernel would
        route a packet from the ARP'd IP out that interface (therefore you must use
        source based routing for this to work). In other words it allows control of
        which cards (usually 1) will respond to an arp request.  

        arp_filter for the interface will be enabled if at least one of
        conf/{all,interface}/arp_filter is set to TRUE, it will be disabled otherwise.

arp_announce - INTEGER :

        Define different restriction levels for announcing the local source IP address
        from IP packets in ARP requests sent on interface:

        0 - (default) Use any local address, configured on any interface  

        1 - Try to avoid local addresses that are not in the target's subnet for this
        interface. This mode is useful when target hosts reachable via this interface
        require the source IP address in ARP requests to be part of their logical
        network configured on the receiving interface. When we generate the request
        we will check all our subnets that include the target IP and will preserve the
        source address if it is from such subnet. If there is no such subnet we select
        source address according to the rules for level 2.  

        2 - Always use the best local address for this target.  In this mode we ignore
        the source address in the IP packet and try to select local address that we
        prefer for talks with the target host. Such local address is selected by
        looking for primary IP addresses on all our subnets on the outgoing interface
        that include the target IP address. If no suitable local address is found we 
        select the first local address we have on the outgoing interface or on all
        other interfaces, with the hope we will receive reply for our request and even
        sometimes no matter the source IP address we announce.

        The max value from conf/{all,interface}/arp_announce is used.

        Increasing the restriction level gives more chance for receiving answer from
        the resolved target while decreasing the level announces more valid sender's
        information.

arp_ignore - INTEGER :

        Define different modes for sending replies in response to received ARP requests
        that resolve local target IP addresses:

        0 - (default): reply for any local target IP address, configured on any 
        interface

        1 - reply only if the target IP address is local address configured on the
        incoming interface

        2 - reply only if the target IP address is local address configured on the
        incoming interface and both with the sender's IP address are part from same
        subnet on this interface

        3 - do not reply for local addresses configured with scope host, only
        resolutions for global and link addresses are replied

        4-7 - reserved

        8 - do not reply for all local addresses

        The max value from conf/{all,interface}/arp_ignore is used when ARP request is
        received on the {interface}

Diagnostic Steps

ARP Cache and network interface configuration information is available in sosreport. If it's not, following steps can be followed to collect the same.

Collect network interface configuration information from concerned nodes (say Node1 and Node2) which are having connectivity problem.
```
  # ifconfig -a >Node1-ifconfig-a.txt 
```
Capture network traffic between Node1 and Node2. tcpdump -i interface_name output on console does not provide MAC addresses in transaction. So it's good to capture raw packets in a file for diagnosis.
- Start tcpdump in one terminal
```
  # tcpdump -nn -i Interface_Name -w Node1-tcpdump.pcap 
```
  -nn:This option does not resolve IP and port. so capture is fast.
  -w : This option write the packet data to file
From tcpdump output we can easily check the source and destination MAC and IP addresses, and check whether they are correct or wrong.

Start ping on Node1 (or Node2)

  # ping -c 10 <IP Address of peer node> > Node1-ping.txt

After ping returns, stop tcpdump running in other terminal by pressing Ctrl+C
Collect ARP cache information from both Node1 and Node2
```
   # cat /proc/net/arp >Node1-arp_cache.txt
```

From arp cache information and ifconfig output, we can check whether any IP and MAC address association is wrong or not.

If we find that ARP cache entry is wrong we can delete that using following command
```
   # arp -d <IP address in wrong entry>
```
Repeat above command if there are more than one wrong entry, one per each entry.
To correct the ARP cache entry we can use arping command to send gratuitous ARPs as follows
```
   # arping <peer IP>
```

SBR

Networking

Product(s)

Red Hat Enterprise Linux

Components

kernel

Category

Troubleshoot

Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.