Bug 7143 - Arp requests sent out with using bogus interface/ip pairings on multihomed hosts
Arp requests sent out with using bogus interface/ip pairings on multihomed hosts
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: iproute (Show other bugs)
4.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-19 11:00 EST by Ryan
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-16 20:14:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ryan 1999-11-19 11:00:27 EST
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-16 20:14:59 EST
iproute is not part of  Red Hat Linux 4.2

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