28.5. Tunable ARP Options
The kernel allows the user to tune the ARP behavior via both the /proc filesystem and compile-time options . We will see details on how to configure those features, their allowed settings, and their defaults in the section "Tuning via /proc Filesystem" in Chapter 29, but let's introduce the main ones here.
28.5.1. Compile-Time Options
Two ARP options can be enabled at compile time:
28.5.2. /proc Options
Most of those features can be configured both globally and on a per-device basis. Code can check whether they are enabled by using the IN_DEV_XXX macros defined in include/linux/inetdevice.h (e.g., IN_DEV_ARP_ANNOUNCE, IN_DEV_ARP_IGNORE, and IN_DEV_ARPFILTER). Please refer to the definition of those macros to see which features are global and which are local. All of the macros take, as their input parameter, the device's IP configuration block (net_device->ip_ptr), which is normally retrieved with the routine in_dev_get.
Some of those options have been introduced to address issues specific to Linux Virtual Servers (LVS). In the LVS HOWTO, in the section "LVS: the ARP problem," you can find detailed information on what these features are for and how they can be configured. You will also find information about previous approaches.
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.
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.
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 well-defined 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.
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).
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
184.108.40.206. Medium ID
This is a feature that can be used to handle certain rare cases where a subnet spans different LANs, and where a host offering proxy ARP has multiple NICs on that subnet serving the different LANs. The term medium refers to a network served by a single broadcast address. If a hub or switch ties two such media together, a situation could arise where a proxy ARP host acts as a proxy inappropriately, responding to a request on behalf of a host on a different LAN that could handle the request itself.
We already saw in Chapter 26 that a proxy ARP server does not reply to an ARPOP_REQUEST that is received on the same device through which the solicited IP address can be reached. However, when multiple NICs are connected to the same LAN, this condition may not be sufficient to ensure proper behavior. Let's look at the example in Figure 28-8.[*]
Host B is configured with two NICs on the same LAN (medium). eth0 is used to reach all of the IP addresses in the 10.0.0.0/24 subnet, and eth1 is used to communicate to Host C only, thanks to the /30 netmask. Host B acts as a proxy for both LAN1 and LAN3.
Let's assume now that Host A needs to transmit something to HostC but does not have its L2 address. Host A will send a broadcast ARPOP_REQUEST, which will be received by both eth0 and eth1 on Host B as well as by Host C. Host B should not reply to the ARPOP_REQUEST because Host C will do so by itself.
Figure 28-8. Example of use of medium ID
Let's suppose Host B is a proxy ARP server with proxying enabled on all of its interfaces, and see how it behaves when it receives the ARPOP_REQUEST on both of its interfaces:
As you can see, there is a need for a way to tell the proxy ARP server that its two interfaces reside on the same broadcast domain, and that therefore neither of the two ARPOP_REQUESTs should be processed. This is done by assigning an ID called the medium ID to interfaces connected to the same LAN. In this case, the same medium ID should be assigned to both eth0 and eth1 on Host B. A host replies to an ingress solicitation request only when the solicited address is reachable through a device with a medium ID different from the one associated with the ingress device. Medium IDs are positive numbers; other values have special meanings as shown in Table 28-3.
The medium ID configuration is not necessary in the topology in Figure 28-9, where Host B's interfaces are connected to two different LANs. For details on the purpose and use of medium IDs, see http://www.ssi.bg/~ja/medium_id.txt.
Figure 28-9. Redesign of the topology in Figure 28-8 that does not need the medium ID configuration
Figure 28-10 shows the logic implemented by arp_fwd_proxy, the routine invoked by arp_process to see whether a given ARP request can be proxied based on the proxy ARP and Medium ID configuration.