嵌入式linux中文站在线图书

Previous Page
Next Page

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:


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) and the kernel configuration menu does not provide any way to enable it.

Do not confuse the effect of this feature with gratuitous ARP. ARP_UNSOLICITED accepts unsolicited ARPOP_REPLY packets, whereas gratuitous ARP causes a "push" update via an ARPOP_REQUEST. As Figure 28-18 shows, only unicast unsolicited requests are accepted.

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.

28.5.2.1. 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.

Table 28-1. ARP_ANNOUNCE levels

Value

Meaning

0 (Default)

Any local IP address is fine.

1

If possible, pick an address that falls within the same subnet of the target address. If not possible, use level 2.

2

Prefer primary addresses.


28.5.2.2. 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 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.

Table 28-2. ARP_IGNORE values

Value

Meaning

0 (Default)

Reply for any local address.

1

Reply only if the target IP is configured on the receiving interface.

2

Like 1, but the source IP (sender's address) must belong to the same subnet as the target IP.

3

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).

4-7

Reserved.

8

Do not reply.

>8

Unknown value; accept request.


28.5.2.3. 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


28.5.2.4. 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.[*]

[*] This is an extended version of the example provided by Julian Anastasov and Alexey Kuznetsov at http://www.ssi.bg/~ja/medium_id.txt. The document also describes a common scenario where this feature can be useful.

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:


Request received on eth0

According to the routing table, the solicited address 10.0.0.1 is reachable via a different interface (eth1). Therefore, Host B processes the request. Note that Host B has two routes that match the destination address 10.0.0.1, but the one with netmask /30 is more specific and therefore wins.


Request received on eth1

In this case, the receiving interface and the one used to reach 10.0.0.1 match, so Host B does not process the request.

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.

Table 28-3. Value of medium ID

Value

Meaning

-1

Proxy ARP is disabled.

0 (default)

Medium ID feature is disabled.

>0

Valid medium ID.


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.


Previous Page
Next Page