Bug 7143

Summary: Arp requests sent out with using bogus interface/ip pairings on multihomed hosts
Product: [Retired] Red Hat Linux Reporter: Ryan <edison>
Component: iprouteAssignee: Cristian Gafton <gafton>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-17 01:14:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ryan 1999-11-19 16:00:27 UTC
Lab configuration is as follows:

p3-500 dual machine running w\smp support

configured with 4 3comXXXX ethernet cards with the logical addresses of

10.0.0.1/16 (base)
10.1.0.1/16 (perflab)
10.2.0.1/16 (dev/int labs)
10.3.0.1/16 (annex lab)
10.4.0.1/16 (systest lab)

We have an L2TP network access system that was being tested, and an arp
request was made by the linux box for a dialup client to find the return
path (the lns ether address) to the l2tp/ppp client...

Working Scenario:
A client in perflab connects to the to the lns located at 10.1.0.163, and
gets the address of 10.1.100.1. A packet goes out from the client to
10.1.0.1, and to get the return address the linux box arps for 10.1.100.1
with the source address of 10.1.0.1, of which the 10.1.0.163 box replies
to the 10.1.0.1 with the approprate mac addy for the 10.1.100.1 client.

Non-Working Scenario:
A client in perflab connects to the lns located at 10.1.0.163, and gets
the address of 10.1.100.1. A packet goes out from the client to 10.2.0.1,
and to get the return address the linux box arps for 10.1.100.1 with the
source address of 10.2.0.1, (but on the appropriate physical interface
where the 10.1.0.1 resides). Of Which the 10.1.0.163 box ignores because
it's an arp request that is out of his netmask/broadcast domain.

The 10.1.0.163 box does the right thing by ignoring the arp request on the
wire for an address which is out of his appropriate broadcast range. The
linux box does the wrong thing by putting an arp request out on a physical
interface with a source address that does not match that physical
interfaces broadcast domain. Temp. fixes in the lab were to ping first the
10.1.0.1 address (adds the arp entry like in working scenario) and then go
out to the world, and the other is to set the netmask on the 10.1.0.163
box to a /8. and add static routes to each of the /16 nets to maintain
interlab communication. But this should be fixed, especially if more
people (which in the future I am sure will) plan to use linux
(specifically redhat) for lab routers, and test tools. I think that this
may fall on the wrong ears, and if so.. please forward this to the
caretakers of the code where this bug is located...

Comment 1 Cristian Gafton 2000-02-17 01:14:59 UTC
iproute is not part of  Red Hat Linux 4.2