Bug 80934 - Incorrectly responding to ARP requests
Summary: Incorrectly responding to ARP requests
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Larry Woodman
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-02 16:00 UTC by Dave Johnson
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version: arptables_jf-0.0.7-0.3E
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-05-17 21:29:14 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Dave Johnson 2003-01-02 16:00:53 UTC
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 16:15:44 UTC
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 21:34:38 UTC
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 21:38:52 UTC
that's a question for the server os folks

Comment 4 Mike McLean 2003-02-14 20:00:32 UTC
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 21:29:14 UTC
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.