http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/059600 2556/understandlni-CHP-28-SECT-4.

html

Responding from Multiple Interfaces

Linux has a rather unusual design: it considers an IP address as belonging to a host rather than an interface, even though administrators always assign IP addresses to particular interfaces. [*] This has impacts that some administrators complain about:
[*] Using the options described in the section "Tunable ARP Options," you can make Linux behave as if IP addresses belonged to the interfaces. For an interesting discussion of this design, including its advantages and disadvantages, you can refer to the (pretty long) thread "ARP responds on all devices" on the netdev mailing list, which is archived at http://oss.sgi.com/archives/netdev.

A Linux host replies to any ARP solicitation requests that specify a target IP address configured on any of its interfaces, even if the request was received on this host by a different interface. To make Linux behave as if addresses belong to interfaces, administrators can use the ARP_IGNORE feature described later in the section "/proc Options." Hosts can experience the ARP flux problem, in which the wrong interface becomes associated with an L3 address. This problem is described in the text that follows. Imagine you have a host with two NICs on the same LAN, and that another host sends an ARP request for one of the addresses. The request is received by both interfaces, as shown in Figure 28-5, and both interfaces reply.

Figure 28-5. The ARP flux problem

The host sending the solicitation therefore receives two replies to its request. One comes from the NIC with the correct L2 address (eth0) but the other bears the other NIC's address (eth1). Which address is entered by the correspondent in its ARP cache

depends on the order in which the requests happen to be received and the host's way of handing duplicate repliesin short, it's nondeterministic. The ARP flux problem can be solved with the features described in the section "Tunable ARP Options." kernel-3.2.fc16/linux-3.2.x86_64/Documentation/networking/ip-sysctl.txt arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface}

Zero-cost routes imply that the local machine will send an ARP request for each machine on the target network, since that network is accessible over the local le0 interface. Normally, a host will send an ARP request using the IP address of the designated router for the network; but in this case the router is the machine itself so it does the ARP for the destination IP address. Strange-looking ARP requests for IP addresses that shouldn't be on a particular network segment may be caused by a misplaced zero-cost route. Here's a corner case where proxy ARP once again comes to the rescue: While merging two IP networks together, you have some "old" machines that have no need to reach other systems on the same network, but have to use the single router that has an IP address on the "new" IP network. That is, router 201.2.14.100 has to handle packets from hosts 192.9.200.x, and you don't want to create zero-cost routes on every one of those machines. Using proxy ARP or a published ARP entry on one of the 201.2.14.x machines, create a "fake" IP address for the router on the 192.9.200.0 network, say, 192.9.200.100. Then insert an ARP entry using the MAC address of the router, so that ARP requests for IP address 192.9.200.100 are answered with the Ethernet address of your router, and packets will be delivered to the router from hosts on the 192.9.200.x network. Make sure those "old" machines put 192.9.200.100 in their /etc/defaultrouter files, or otherwise manually set up a route through the "fake" IP address. Note that this address won't appear in RIP packets or other routing information, so you'll have to use a route command, an entry in /etc/gateways, or a default route to point your old machines at the router of multiple personalities.

ARP_ANNOUNCE
This option controls which source IP addresses can be put in the ARP headers of solicitation requests, when the host generating the request offers multiple addresses. Table 28-1 lists the allowed levels and tells how the IP address is selected from the ones configured on the local system. The section "Solicitations" shows how ARP uses it. ARP_ANNOUNCE is handled in the arp_solicit function. Value 0 (Default) 1 2 Meaning Any local IP address is fine. If possible, pick an address that falls within the same subnet of the target address. If not possible, use level 2. Prefer primary addresses.

ARP_IGNORE
This option controls the criteria that determine whether to process ARPOP_REQUEST packets. Normally, all requests that can be handled by a host are processed. As explained in the section "Responding from Multiple Interfaces," IP addresses in Linux belong to the host, not to its interfaces. Because of that, an ARPOP_REQUEST will be processed by a host as long as the target IP address is configured on any of the interfaces, including the loopback interface.[*] In some cases, such as with LVS, that would be a problem. By configuring ARP_IGNORE properly, an administrator can solve the problem. See the LVS HOWTO for a detailed description of the problem and the possible solutions.
[*] 127.x.x.x addresses are an exception; ARP requests for them are never handled.

Figure 28-6 shows an example of virtual server configuration. The address by which the server is known to the world is shown as VIP, which is configured on an NIC on the virtual server and as the loopback address on the two real servers. All replies to requests for the address VIP should come from only the virtual server. But when the virtual server receives a request for the services it provides, it forwards it to one of the real servers using a welldefined selection algorithm. The receiving hosts accept the packets because they have VIP locally configured. Both real servers configure ARP_IGNORE on their eth0 interface so that they will not respond to ARPOP_REQUEST for the VIP address.

Figure 28-6. Example of scenario for the use of ARP_IGNORE

ARP_IGNORE

is handled in the

arp_process

function. Possible values are listed in Table 28-2.

Value 0 (Default) 1 2 3 4-7 8 >8

Meaning Reply for any local address. Reply only if the target IP is configured on the receiving interface. Like 1, but the source IP (sender's address) must belong to the same subnet as the target IP. Reply only if the scope of the target IP is not the local host (e.g., that address is not used to communicate with other hosts). Reserved. Do not reply. Unknown value; accept request.

ARP_FILTER
This option controls whether an interface should reply to an ingress ARPOP_REQUEST in scenarios where multiple NICs are connected to the same LAN and are configured on the same IP subnet. In this scenario, where each NIC receives a copy of the ARPOP_REQUEST, you want only one interface (chosen deterministically, not at random) to reply. This feature is useful mainly in networks where the IP source routing options are used. Let's take the example in Figure 28-7. When Host A tries to resolve the 10.0.0.1 IP address, both of Host B's interfaces receive the ARPOP_REQUEST. For both requests, Host B consults the routing table and replies only to the request that was received on the interface that would be used by Host B to reach the sender's IP address (10.0.0.3). Host B's routing table shows that the 10.0.0.3 address is reachable via both eth0 and eth1. However, we will see in Part VII that when multiple routes are available toward any given IP address, a routing lookup always returns the same one[*] (i.e., the first one that matches).
[*] Unless the kernel comes with support for multipath caching. That feature is described in Chapter 33.

When configured, ingress ARPOP_REQUEST packets are processed only if the kernel knows how to reach the sender's IP address, and if the device used to reach the sender's IP address is the same as the device where the request was received. Note that ARP filtering has nothing to do with the filtering that can be done with Netfilter. The two are configured and enforced independently. Unlike the previous two options, ARP_FILTER can only be enabled or disabled; there are no intermediate states. It is handled in the arp_process function.

Figure 28-7. Example of scenario for the use of ARP_FILTER

Compile-Time Options
Two ARP options can be enabled at compile time: ARPD (CONFIG_ARPD) This allows a user-space daemon to handle ARP, which can improve performance on a very large and busy network. See the section "ARPD." UNSOLICITED ARP (CONFIG_IP_ACCEPT_UNSOLICITED_ARP) By default, when a host receives an ARPOP_REPLY for which it had no pending ARPOP_REQUEST, the kernel drops the reply. Sometimes, however, it could be useful to accept it. This feature, which establishes that unsolicited replies are accepted, is actually not supported by Linux anymore: the code is commented out (in the function arp_process

Kernel variables and associated files in /proc/sys/net/ipv4/neigh subdirectories

Kernel variable name mcast_probes ucast_probes app_probes retrans_time base_reachable_time delay_probe_time gc_staletime queue_len proxy_qlen anycast_delay proxy_delay locktime gc_interval gc_thresh1 gc_thresh2 gc_thresh3

Filename mcast_solicit ucast_solicit app_solicit retrans_time base_reachable_time delay_first_probe_time gc_stale_time unres_qlen proxy_qlen anycast_delay proxy_delay locktime gc_interval gc_thresh1 gc_thresh2 gc_thresh3

Default value for IPv4/IPv6 3 3 0 100 * HZ 30 * HZ 5 * HZ 60 * HZ 3 64 1 * HZ (8*HZ)/10 1 * HZ 30 * HZ 128 512 1,024

Kernel variables and associated files in /proc/sys/net/ipv4/conf subdirectories

Kernel variable name ipv4_devconf.arp_announce ipv4_devconf.arp_filter ipv4_devconf.arp_ignore ipv4_devconf.medium_id ipv4_devconf.proxy_arp Filename arp_announce arp_filter arp_ignore medium_id proxy_arp Default value for IPv4/IPv6 0 0 0 0 0