Bug 80934 - Incorrectly responding to ARP requests
Incorrectly responding to ARP requests
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-01-02 11:00 EST by Dave Johnson
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version: arptables_jf-0.0.7-0.3E
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-17 17:29:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Johnson 2003-01-02 11:00:53 EST
Description of problem:

When using AS 2.1 to serve http requests load balanced by IBM's WebSphere Edge
product, this patch was necessary:


What we saw was this behavior: the linux box was responding to an arp request
for an IP address that was configured as a virtual interface (lo:1). The router
would broadcast an arp for the IP, which physically belonged to the edge server,
and the linux box would reply, saying that it belonged to himself. Broadcast
arps were no longer responded to incorrectly after we applied the patch as
described here:


However, the linux boxes were still replying to directed arps with the incorrect
information, just as before. So we modified the patch so that it would not try
to determine whether the incoming packet was a broadcast arp or a directed arp.
This succeeded in stopping the linux boxes from replying to arp requests for any
IP that it did not own a physical interface for.
Comment 1 Arjan van de Ven 2003-01-02 11:15:44 EST
the hidden patch is absolutely wrong; and recompiled kernels aren't supported.
Use the netfilter arpfilter feature instead
Comment 2 Dave Johnson 2003-01-02 16:34:38 EST
Are the userspace tools capable of setting up such an ARP filter?  I am having
trouble finding any documentation or userspace code.  Thanks,
Comment 3 Arjan van de Ven 2003-01-02 16:38:52 EST
that's a question for the server os folks
Comment 4 Mike McLean 2003-02-14 15:00:32 EST
arpfilter will not solve this problem (why?: arp requests).  Use an iptables
transparent proxy instead.

*Don't* assign the vip to any interface or alias, instead use a rule like the
following on the real servers:

iptables -t nat -A PREROUTING -p tcp -d <VIP> --dport <vport> -j REDIRECT

You can vary the incantation to be more or less picky about which packets are
redirected to the host.  Basically the machine masquerades the packets to
itself.  Since the vip is never raised on an interface, there is no arp problem.
Comment 5 Mike McLean 2004-05-17 17:29:14 EDT
The latest arpfilter_jf (RHEA-2004:055-06) resolves this problem.  You
will need to use it to set up two rules: one to block incoming arp
requests for the hidden ip, and a second to mangle outgoing arp
requests that might use the hidden ip.

Example arptables rules:
% arptables -A IN -d $HIDDEN_IP -j DROP
% arptables -A OUT -s $HIDDEN_IP -j mangle --mangle-ip-s $PUBLIC_IP

Note You need to log in before you can comment on or make changes to this bug.