arp-zerocostroute

8/3/2019 ARP-Zerocostroute

1/8

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 hostrather 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 netdevmailing 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 ofits interfaces, even ifthe request was received on

this host by a different interface. To make Linux behave as ifaddresses belong

to interfaces, administrators can use the ARP_IGNORE feature described later in

the section "/proc Options."

Hosts can experience theARP flux

problem, in which the wrong interfacebecomes 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 ofthe 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
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-FIG-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-FIG-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.htmlhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://oss.sgi.com/archives/netdevhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-FIG-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-FIG-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html


2/8

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 forany 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 foreach 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 forthe 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 routerthat 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 ofthe router, so that ARP requests forIP address 192.9.200.100 are answered with the Ethernet address of yourrouter, 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/defaultrouterfiles, 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.
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-SECT-5


3/8

ARP_ANNOUNCE

This option controls which source IP addresses can be put in the ARP headers ofsolicitation

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 Meaning

0 (Default) Any local IP address is fine.

1 Ifpossible, pick an address that falls within the same subnet ofthe

target address. Ifnot possible, use level 2.

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 ofthat, an ARPOP_REQUEST will be processed by a host as long as the

target IP address is configured on any ofthe 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 ofthe problem and the possible solutions.[*] 127.x.x.xaddresses are an exception; ARP requests for them are never handled.

Figure 28-6 shows an example ofvirtual 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 ofthe 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
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-1http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-8.html#understandlni-CHP-28-SECT-8.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FN4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-6http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-6http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-1http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-1http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-8.html#understandlni-CHP-28-SECT-8.2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-4.html#understandlni-CHP-28-SECT-4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FN4http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-6http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-6


4/8

ARP_IGNORE is handled in the arp_process function. Possible values are listed in Table 28-2.
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-2http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-TABLE-2


5/8

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 samesubnet as the target IP.

3 Reply only if the scope ofthe 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.

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 ofthe 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 ofHost 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 showsthat 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 inChapter 33.

When configured, ingress ARPOP_REQUEST packets are processed only ifthe kernel knows how to

reach the sender's IP address, and ifthe 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
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-7http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-7http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-PART-VII.html#understandlni-PART-VIIhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-PART-VII.html#understandlni-PART-VIIhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FN5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-33.html#understandlni-CHP-33http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-33.html#understandlni-CHP-33http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-33.html#understandlni-CHP-33http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-7http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FIG-7http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-PART-VII.html#understandlni-PART-VIIhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-PART-VII.html#understandlni-PART-VIIhttp://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-5.html#understandlni-CHP-28-FN5http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-33.html#understandlni-CHP-33http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-33.html#understandlni-CHP-33


6/8

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, thekernel 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
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-13.html#understandlni-CHP-28-SECT-13http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-28-SECT-13.html#understandlni-CHP-28-SECT-13


7/8

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

subdirectories


8/8

Kernel variable name Filename Default value for IPv4/IPv6

mcast_probes mcast_solicit 3

ucast_probes ucast_solicit 3

app_probes app_solicit 0

retrans_time retrans_time 100 * HZ

base_reachable_time base_reachable_time 30 * HZ

delay_probe_time delay_first_probe_time 5 * HZ

gc_staletime gc_stale_time 60 * HZ

queue_len unres_qlen 3

proxy_qlen proxy_qlen 64

anycast_delay anycast_delay 1 * HZ

proxy_delay proxy_delay (8*HZ)/10

locktime locktime 1 * HZ

gc_interval gc_interval 30 * HZ

gc_thresh1 gc_thresh1 128

gc_thresh2 gc_thresh2 512

gc_thresh3 gc_thresh3 1,024

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

subdirectories

Kernel variable name Filename Default value for IPv4/IPv6

ipv4_devconf.arp_announce arp_announce 0

ipv4_devconf.arp_filter arp_filter 0

ipv4_devconf.arp_ignore arp_ignore 0

ipv4_devconf.medium_id medium_id 0

ipv4_devconf.proxy_arp proxy_arp 0

arp-zerocostroute

Documents