arp_ignore should default to 1
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Ubuntu) |
Invalid
|
Medium
|
Unassigned | ||
Bug Description
When I switched from a 2.4 kernel installation of Gentoo to a 2.6 installation
of Ubuntu,
I had hoped this problem would be fixed in the default configuration, but it
seems it
hasn't been.
I have received the following notice from our network administrators:
Monitoring of our DHCP servers indicates the device specified in the
'Subject' header of this message is using DHCP in a way that's not
acceptable on the campus network.
It appears the device is running two (or more) simultaneous,
independent DHCP clients on the same physical interface. That is,
one device' network interface (e.g. an Ethernet interface or a
Wireless interface) identifed by a single hardware address) is
attempting to obtain multiple unique IP address leases at the same
time. (If left unresolved, the next time it happens OIT will disable
OIT Mobile IP Service for the device; if the interface involved is
wireless, we will also disable wireless service for the device.)
We don't support the use of DHCP in that mode; we lease a single IP
address (to a single hardware address) at one time.
Please reconfigure the device to only operate a single DHCP client
on the physical interface at a time.
It seems very similar to a notice they sent to me a year ago on my Gentoo system:
Monitoring of our DHCP servers indicates the device
'eetemad.student' has multiple interfaces on same subnet, gets
confused over which has which lease. It is misconfigured (or has
malfunctioning DHCP client software or OS).
The device is registered in the Host Database as having both an
Ethernet interface and a Wireless interface. (I will assume this
registration information is accurate.)
Both network interfaces have been simultaneously attached to the
campus network. Each interface obtains a lease on a unique IP
address via DHCP.
(This is all acceptable.) However, the device appears to get
confused about which leased IP address is associated with each
network interace. It responds to IP ARP Requests via one network
interface using the IP address assigned to the other network
interface. When both network interfaces are attached to *different*
campus IP subnets, we handle this by simply discarding the
erroneous traffic. It interferes with service to the customer's
device, but generally does not cause problems on the campus network.
But when both network interfaces are attached to the *same* campus
IP subnet, this causes more problems. This is the situation the
device was on Dec 2 7:30pm - Dec 3 12:40am. Both interfaces were
attached to Dormnet at that time. IP address 140.180.146.72 was
leased to interface 0:9:6b:2:5c:4d, and OIT Mobile IP Address
140.180.188.23 was leased to interface 0:5:3c:9:d0:4d. However,
interface 0:9:6b:2:5c:4d was simultaneously using both IP addresses
at the same time. This is because the device has been misconfigured
so both interfaces can be attached to the *same* IP subnet
simultaneously. Few, if any, operating systems are designed to
handle that situation; instead they can easily become confused
about which IP address to use with which interface.
The misconfiguration that most commonly results in this problem is
as follows:
* The device has both an Ethernet and a Wireless interface.
* The device is configured to try to make both interfaces active
simultaneously.
* The Ethernet interace is attached to a particular campus subnet
(e.g. subnet "foo").
* The Wireless interface is associated to a private Wireless
Access Point configured to function as a bridge, and that private
WAP is attached to campus subnet "foo". (This does not happen if
the Wireless interface is configured to only use OIT Wireless
Service, as OIT Wireless Access Points are attached to a campus
subnet that is not available any other way; there are no customer
Ethernet connections on that IP subnet.)
You need to configure the device so that it does not end up in
this situation. Any of the following solutions will work:
* Reconfigure the device so it does not use a private Wireless
Access Point, but instead uses only OIT Wireless Service.
* Reconfigure the device so that it it does not try to activate
more than one network interface simultaneously. Most operating
systems will allow you to define multiple "locations" or
"profiles", each containing a single active network interface.
Once defined, you can switch among each of these easily, as you
relocate the device.
* Convince the vendor of the operating systems and/or DHCP client
to improve the software to handle this situation. Few, if any,
operating systems are designed to handle this situation; this
approach is generally impractical.
Please correct the problem. If the problem persists, your network
access will be restricted or blocked.
For that problem, I contacted our Unix Group, and got the following
response:
i poked about the ipv4 layer a bit and found that arp requests will
generate an arp reply on an interface if that interface can route to
the requesting subnet. since you have both eth0 and eth1 on the same
subnet, arp resolution broadcasts meant for ip/eth1 could be handled by
eth0, ultimately assigning the same mac address to the two different ip
addresses at the remote computer (probably oit's scanner).
it turns out that someone committed a patch in the 2.4.25->2.4.26 time
frame to allow finer granularities of arp handling. you can get things
working by upgrading to a 2.4.26+ version of the kernel (or recent
2.6 series). after that, you'll just need to play with the arp_ignore
proc setting.
ie. "sysctl net.ipv4.
interface will send an arp reply for any target ip address from any
source (troublesome for us).
instead, set it to "1", which inserts a guard that guarantees that the
interface's ip address matches the target one in the arp request
packet:
"sysctl -w net.ipv4.
only one of the interfaces will be used though, since they share a subnet.
(after handling the broadcasted req through one interface, the kernel
doesn't seem to see the one from the second interface; i haven't dug
into why though.)
i tried it out with my computers under a similar environment, and it
seems to check out okay.
kevin ko
Once I set my computer to execute "sysctl -w net.ipv4.
on startup, everything worked ok and I got no further complaints from OIT
until I started using Ubuntu.
In conclusion, I think you should set sysctl -w net.ipv4.
by default.
| fantasai (fantasai) wrote | #1 |
| Carthik Sharma (carthik) wrote | #2 |
| fantasai (fantasai) wrote | #3 |
| Changed in linux-source-2.6.15: | |
| assignee: | nobody → ubuntu-kernel-team |
| status: | Needs Info → Confirmed |
| Launchpad Janitor (janitor) wrote This bug is now reported against the 'linux' package | #4 |
| Leann Ogasawara (leannogasawara) wrote | #5 |
| Launchpad Janitor (janitor) wrote Kernel team bugs | #6 |
| kernel-janitor (kernel-janitor) wrote | #7 |
| tags: | added: kj-triage |
| Changed in linux (Ubuntu): | |
| status: | Confirmed → Incomplete |
| Jeremy Foshee (jeremyfoshee) wrote | #8 |
| tags: | added: kj-expired |
| Changed in linux (Ubuntu): | |
| status: | Incomplete → Invalid |
Found a more complete email in the OIT records:
12/6/2005 11:22am
Monitoring of our DHCP servers indicates the device specified in the 'Subject'
header of this message is using DHCP in a way that's not acceptable on the
campus network.
It appears the device is running two (or more) simultaneous, independent DHCP
clients on the same physical interface. That is, one device' network interface
(e.g. an Ethernet interface or a Wireless interface) identifed by a single
hardware address) is attempting to obtain multiple unique IP address leases at
the same time.
We don't support the use of DHCP in that mode; we lease a single IP address (to
a single hardware address) at one time.
The customer needs to reconfigure the device to only operate a single DHCP
client on the physical interface at a time.
(Note that a device with multiple physical interfaces (e.g. an Ethernet
and a Wireless interface) may run a DHCP client instance on each interface
simultaneously. That's not a problem, as each interface has a unique
hardware address. But it's not OK to run multiple DHCP client instances
on the same physical interface.)
The particular problem caused by running multiple simultaneous DHCP clients on a
single hardware address is that the device's interface sometimes "steals" an
additional IP address (or addresses) when it uses use OIT Mobile IP Service.
(That is, when the interface is attached to the campus network outside its home
location. By "steals", we mean that the interface uses an IP address
not assigned for its use at the time.)
In more detail, what goes wrong is this: the first DHCP client running on this
physical interface comes up and requests a lease, and we award one. Then the
second DHCP client running on the same physical interface comes up and requests
a lease, so we cancel the first lease, and award a new one, because we only
support a single DHCP lease per hardware address at a time. (If a third DHCP
client comes up on the same physical interface and requests a lease, we cancel
the second one, and award a new one, and so forth.) However, the client's first
DHCP client is still using the first IP address leased, even though that lease
is no longer valid. When we try to assign that first IP address to another
customer, this causes a problem, as the same IP address may not be used by two
different devices at the same time.
This happens randomly when the device's physical interface is attached to a
network other than the device's home network, because in that situation, each
lease offer may be for a different dynamically-
attached to its home network, every offer is for the same statically-assigned IP
address. So the IP address the interface's other DHCP "steals" is just the
customer's statically-assigned IP address. The customer ends up harming no one
but him/herself.)
We have seen this particular customer's device do exactly this (steal
a second (or more) IP address this way) on Dec 5 while visiting equadnet.
There are many possible ways a customer may have misconfigured a device to run
multiple DHCP clients simultaneously on the same physical interface. One way (on
a Windows machine) may be to define mu...