Address Resolution: ARP and RARP

ARP, due to its apparent simplicity, is a rather overlooked concept, and sometimes its effect on the well being of network infrastructures is underestimated. ARP-related issues are fairly common in complex scenarios and often poorly understood by non-networking folks. Therefore, this section offers an overview of several manifestations of the ARP protocol itself and related aspects.

For a good understanding of network dynamics, it is also mandatory to understand the timers involved with regard to ARP and switch table entries and their lifetime. ARP table entries have a lifetime in the range of minutes up to tens of minutes, depending on the operating system under discussion.

Politely behaving implementations such as Cisco IOS Software display ARP cache timers within the ARP output. This information will hopefully assist in tracking and resolving problems such as incomplete ARP entries, duplicate IP addresses, and security issues such as spoofing and sniffing. Ethernet MAC addresses can be spoofed easily given physical access to the network segment or VLAN under consideration. Example 7-1 presents an overview of the capabilities of the Linux and BSD arp commands (essentially show, add, and delete). Static ARP entries can as well be deployed via a configuration file. You will read more about the temp/pub flags of the arp command in the following sections.

Example 7-1. Linux and BSD ARP Utility Features

[root@callisto:~#] arp -?


  arp [-vn]  [<HW>] [-i <if>] [-a] [<hostname>]             <-Display ARP cache

  arp [-v]          [-i <if>] -d  <hostname> [pub][nopub]    <-Delete ARP entry

  arp [-vnD] [<HW>] [-i <if>] -f  [<filename>]              <-Add entry from file

  arp [-v]   [<HW>] [-i <if>] -s  <hostname> <hwaddr> [temp][nopub] <-Add entry

  arp [-v]   [<HW>] [-i <if>] -s  <hostname> <hwaddr> [netmask <nm>] pub  <-''-

  arp [-v]   [<HW>] [-i <if>] -Ds <hostname> <if> [netmask <nm>] pub      <-''-

        -a                       display (all) hosts in alternative (BSD) style

        -e                       display (all) hosts in default (Linux) style

        -s, --set                set a new ARP entry

        -d, --delete             delete a specified entry

        -v, --verbose            be verbose

        -n, --numeric            don't resolve names

        -i, --device             specify network interface (e.g. eth0)

        -D, --use-device         read <hwaddr> from given device

        -A, -p, --protocol       specify protocol family

        -f, --file               read new entries from file or from /etc/ethers

  <HW>=Use '-H <hw>' to specify hardware address type. Default: ether

  List of possible hardware types (which support ARP):

    strip (Metricom Starmode IP) ash (Ash) ether (Ethernet)

    tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25)

    netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet)

    dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi (HIPPI)

    irda (IrLAP) x25 (generic X.25)

[root@castor:~#] arp

usage: arp [-n] hostname

       arp [-n] -a

       arp -d hostname [pub]

       arp -d -a

       arp -s hostname ether_addr [temp] [pub]

       arp -S hostname ether_addr [temp] [pub]

       arp -f filename

[root@callisto:~#] rarp -?

rarp: invalid option -- ?

Usage: rarp -a                               list entries in cache.

       rarp -d <hostname>                    delete entry from cache.

       rarp [<HW>] -s <hostname> <hwaddr>    add entry to cache.

       rarp -f                               add entries from /etc/ethers.

       rarp -V                               display program version.

  <HW>=Use '-H <hw>' to specify hardware address type. Default: ether

  List of possible hardware types (which support ARP):

    strip (Metricom Starmode IP) ash (Ash) ether (Ethernet)

    tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25)

    netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet)

    dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi (HIPPI)

    irda (IrLAP) x25 (generic X.25)

[root@callisto:~#] rarp -a

This kernel does not support RARP.

##### My LAB kernel does not support netboot such as RARP/BOOTP ######

##### This has to be configured at compile time ######################

Proxy ARP

Proxy almost always means "to act on someone's behalf"; this is exactly what happens when a manual ARP entry is configured with the publish tag on BSD. This is explained perfectly in the BSD arp(8) manual page.

In the particular case of proxy ARP, the system responds to ARP requests for that entry as if it were the target of the request with its own MAC address, thereby impersonating an ARP server. This is essentially relevant only for hosts without a default gateway or routing table configured or certain boot or transitional situations. The use of proxy ARP in modern routed and subnet-aware networks is discouraged but occasionally found in context with failover protocols. Regarding this issue, I found an interesting quote from the Linux arp(7) man page:

Linux will automatically add a non-permanent proxy arp entry when it receives a request for an address it forwards to and proxy arp is enabled on the receiving interface. When there is a reject route for the target no proxy arp entry is added . . . Support for proxy arp entries for networks (netmask not equal 0xffffffff) was dropped in Linux 2.2. It is replaced by automatic proxy arp setup by the kernel for all reachable hosts on other interfaces (when forwarding and proxy arp is enabled for the interface).[1]

Example 7-2 shows the sysctl parameters that affect proxy ARP behavior and ARP filtering on Linux systems.


For a better understanding of the ARP_filter, consider this quote from the Linux kernel documentation (ip-sysctl.txt):

arp_filter - BOOLEAN

1 - Allows you to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered based on whether or not the kernel would route a packet from the ARP'd IP out that interface (therefore you must use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but it usually makes sense, because it increases the chance of successful communication. IP addresses are owned by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing does this behaviour cause problems.

Example 7-2. Proxy ARP Parameters for Linux Interfaces

[root@callisto:~#] sysctl -a | grep arp

net.ipv4.conf.eth1.arp_ignore = 0

net.ipv4.conf.eth1.arp_announce = 0

net.ipv4.conf.eth1.arp_filter = 0

net.ipv4.conf.eth1.proxy_arp = 0

net.ipv4.conf.eth0.arp_ignore = 0

net.ipv4.conf.eth0.arp_announce = 0

net.ipv4.conf.eth0.arp_filter = 0

net.ipv4.conf.eth0.proxy_arp = 0

net.ipv4.conf.lo.arp_ignore = 0

net.ipv4.conf.lo.arp_announce = 0

net.ipv4.conf.lo.arp_filter = 0

net.ipv4.conf.lo.proxy_arp = 0

net.ipv4.conf.default.arp_ignore = 0

net.ipv4.conf.default.arp_announce = 0

net.ipv4.conf.default.arp_filter = 0

net.ipv4.conf.default.proxy_arp = 0

net.ipv4.conf.all.arp_ignore = 0

net.ipv4.conf.all.arp_announce = 0

net.ipv4.conf.all.arp_filter = 0

net.ipv4.conf.all.proxy_arp = 0

ARP Cache

The route and ARP cache are intimately related via MAC resolution or data-link identifiers, or, to be more general, by "next-hop" addresses and directly attached physical and logical interfaces. Example 7-3 shows an example of the Linux ARP table. "Incomplete" entries (shaded text) would mean that no ARP replies were received for that particular MAC address resolution attempt.

Example 7-3. Linux ARP Table

[root@callisto:~#] arp

Address                  HWtype  HWaddress           Flags Mask            Iface

pollux                   ether   08:00:46:64:74:1B   C                     eth1

ganymed                  ether   48:54:E8:8C:0A:3F   C                     eth1           ether   00:00:0C:1A:A9:AB   C                     eth0

[root@callisto:~#] arp -a

pollux ( at 08:00:46:64:74:1B [ether] on eth1

europa ( at 48:54:E8:8C:0A:3F [ether] on eth1

scar ( at <incomplete> on eth0

Static ARP Entries

Static ARP entries serve different purposes: They make smaller network setups more predictable, enhance security, and can be required in context with static Network Address Translation (NAT) entries of firewall gateways. Example 7-4 shows two examples for static ARP entries on Linux and BSD systems. Note that these are examples for temporary manual entries (in contrast to permanent). The OpenBSD example temp flag results in proxy ARP behavior (as demonstrated in the highlighted text).

Example 7-4. Two Examples of Static ARP Entries

[root@callisto:~#] arp -s A3:A3:A3:A3:A3:A3 temp

[root@callisto:~#] arp

Address                  HWtype  HWaddress           Flags Mask            Iface

pollux                   ether   08:00:46:64:74:1B   C                     eth1

ganymed                  ether   48:54:E8:8C:0A:3F   C                     eth1           ether   00:00:0C:1A:A9:AB   C                     eth0             ether   A3:A3:A3:A3:A3:A3   C                     eth1

[root@ganymed:~#] arp -s A3:A3:A3:A3:A3:A3 pub temp

[root@ganymed:~#] arp -an

? ( at 52:54:05:e3:51:87

? ( at 08:00:46:64:74:1b

? ( at a3:a3:a3:a3:a3:a3 published

? ( at 00:10:5a:c4:2c:04

? ( at 00:05:9a:5b:23:fc

Gratuitous ARP

Gratuitous ARP resembles emission of an unsolicited ARP reply to which no request was sent or received. This is quite common behavior during bootstrap or boot procedures of several operating systems when they initialize their IP stacks. When a computer receives a new interface or another change occurs, it can update all neighboring ARP caches with one gratuitous ARP packet to FF:FF:FF:FF:FF:FF.

A second important application is checking for duplicate IP addresses. The initializing IP stack would not complete its initialization sequence upon detection of such a situation. There exist security and performance implications when accepting gratuitous ARP packets; therefore, routers and switches can be configured to ignore them. This feature can be used to maliciously take over IP addresses.

Gratuitous ARP plays an important role in modern Hot Standby Routing Protocol (HSRP) and heartbeat failover configurations, and sometimes in context of static NAT. Example 7-5 shows a sniffing example of a booting operating system, and Example 7-6 shows relevant Cisco IOS commands to influence proxy ARP and gratuitous ARP behavior. I would not recommend touching the default settings unless you know well what you want to accomplish.

Example 7-5. Gratuitous ARP at BSD IP Stack Initialization

[root@ganymed:~#] tethereal -i ne4

Capturing on ne4

  0.000000 -> ff:ff:ff:ff:ff:ff ARP Who has


Example 7-6. Improving Cisco Security and Performance

scar(config-if)# no ip proxy-arp

scar(config)# no ip gratuitous-arps

scar# show arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet            -   0000.3058.9555  SNAP   TokenRing0

Internet            0   0010.5ad7.9360  ARPA   Ethernet1

Internet            11   5254.05e3.e488  ARPA   Ethernet0

Internet            -   0000.3058.95b5  SNAP   TokenRing1

Internet           -   0000.0c1a.a9a8  ARPA   Ethernet0

Internet          -   0000.0c1a.a9ab  ARPA   Ethernet1


UNIX workstations also send out gratuitous ARP when initializing alias or VLAN interfaces.

Reverse ARP (RARP), the Bootstrap Protocol (BOOTP), and Dynamic Host Configuration Protocol (DHCP)

UNIX workstations can run a rarpd to respond to RARP requests of diskless or client workstations. It can return an IP address for a requesting MAC address as well as a bootable image via Trivial File Transfer Protocol (TFTP). There also exists a bootpd in the BSD world.

BOOTP, Preboot Execution Environment (PXE), and DHCP approaches have largely superseded RARP. Because network-bootable client issues go beyond the scope of this book, no examples are provided. Consult the man pages for rarpd, bootpd, and the links provided in the "Recommended Reading" section for further information. Example 7-7 shows the relevant sysctl parameters to influence BOOTP behavior on Linux systems.


The ISC-DHCP server discussed in Chapter 6, "The Analyzer Toolbox, DHCP, and CDP," can answer both DHCP and BOOTP requests.

Example 7-7. Linux Can Relay BOOTP Requests

[root@callisto:~#] sysctl -a | grep bootp

net.ipv4.conf.eth1.bootp_relay = 0

net.ipv4.conf.eth0.bootp_relay = 0

net.ipv4.conf.lo.bootp_relay = 0

net.ipv4.conf.default.bootp_relay = 0

net.ipv4.conf.all.bootp_relay = 0


TFTP is a lightweight protocol without any security that allows storage, retrieval, and creation of files in a particular directory. On UNIX systems, it is usually started via the (x)inetd super server. UNIX operating systems usually provide a native TFTP service out of the box. It is a broadcast protocol commonly used in network-boot environments together with DHCP, BOOTP, PXE, and RARP. In addition, it is often used to store and retrieve configurations for network elements. Recently there was interest in multicast TFTP servers to efficiently and simultaneously boot multiple clients.

There essentially exist several improved versions of TFTP server implementations:

  • utftpd? Represents my TFTP UNIX implementation of choice. It consists of a client and a server. According to its creator, it offers "fine-grained access control, support for blksize (RFC 2348) and timeout options, and support for revision control" (

  • tftpd-hpa? An enhanced version of the BSD tftpd called tftp-hpa that has TCP wrapper support as well (

  • atftp? Advanced TFTP client and server is multithreaded, supports libwrap (the TCP wrapper library), and is fully compliant with all relevant standards. You can downloaded it from

  • The Solarwinds TFTP server? If you require a TFTP server for Windows, you can use the free tool from Solarwinds (


TFTP is an inherently insecure protocol without a password facility. Therefore, it is strongly advised to compile your TFTP server of choice with TCP wrapper support to protect the server or place it behind a packet filter or firewall. utftp and Solarwinds TFTP provide an internal security mechanism that can filter based on source IP address.

Inverse ARP (InARP), UNARP, and DirectedARP

Inverse ARP is a feature used in ATM and Frame Relay dynamic address mapping. It is used to request the next-hop protocol address given a data-link connection identifier (DLCI) or ATM virtual path identifier/virtual circuit identifier (VPI/VCI) pair. The result is an address-to-DLCI or -VPI/VCI mapping table. In addition, static mappings can be configured. Inverse ARP is a multiprotocol mechanism on Cisco routers and turned on per default for Frame Relay (all protocols). Go to for example configurations.

Examples 7-8 and 7-9 show a brief hub-and-spoke Frame Relay configuration example to emphasize this point. Keep in mind that this setup requires an intermediate Frame Relay switch; hence the name "Frame Relay" or "cell relay" for ATM networks. This will not work in a crossover fashion. Every Layer 2 WAN protocol deals with ARP issues in its own way.

Example 7-8. Cisco Frame Relay Point-to-Multipoint Example (Hub Configuration Fragment)

scar# show running-config



interface Serial1

 no ip address

 encapsulation frame-relay


interface Serial1.1 multipoint

 ip address

 frame-relay map ip 160 broadcast



Example 7-9. Cisco Frame Relay Point-to-Multipoint Example (Spoke Configuration Fragment)

simba# show running-config



interface Serial0

 ip address

 encapsulation frame-relay

 frame-relay map ip 140 broadcast



Interesting future developments (quoted from the RFCs) include the following:

UNARP (RFC 1868):

The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries. This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.

DirectedARP (RFC 1433):

Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.