[Bug 26687] arp_ignore should default to 1

Tue Jun 12 04:04:01 UTC 2007

You have been subscribed to a public bug:

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.conf.all.arp_ignore" defaults to 0, in which an
  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.conf.all.arp_ignore=1"

  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.conf.all.arp_ignore=1"
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.conf.all.arp_ignore=1
by default.

** Affects: linux-source-2.6.15 (Ubuntu)
     Importance: Medium
         Status: Needs Info

-- 
arp_ignore should default to 1
https://bugs.launchpad.net/bugs/26687