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.
[root@callisto:~#] arp -? Usage: 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 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).
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
[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
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.
[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 192.168.14.254 ether 00:00:0C:1A:A9:AB C eth0 [root@callisto:~#] arp -a pollux (192.168.1.250) at 08:00:46:64:74:1B [ether] on eth1 europa (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1 scar (192.168.14.254) at <incomplete> on eth0
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).
[root@callisto:~#] arp -s 192.168.1.55 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 192.168.14.254 ether 00:00:0C:1A:A9:AB C eth0 192.168.1.55 ether A3:A3:A3:A3:A3:A3 C eth1 [root@ganymed:~#] arp -s 192.168.1.55 A3:A3:A3:A3:A3:A3 pub temp [root@ganymed:~#] arp -an ? (192.168.1.1) at 52:54:05:e3:51:87 ? (192.168.1.2) at 08:00:46:64:74:1b ? (192.168.1.55) at a3:a3:a3:a3:a3:a3 published ? (192.168.2.7) at 00:10:5a:c4:2c:04 ? (126.96.36.199) at 00:05:9a:5b:23:fc
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.
[root@ganymed:~#] tethereal -i ne4 Capturing on ne4 0.000000 castor.nerdzone.org -> ff:ff:ff:ff:ff:ff ARP Who has 192.168.2.7? Tell 192.168.2.7
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 192.168.13.1 - 0000.3058.9555 SNAP TokenRing0 Internet 192.168.14.1 0 0010.5ad7.9360 ARPA Ethernet1 Internet 192.168.7.7 11 5254.05e3.e488 ARPA Ethernet0 Internet 192.168.17.1 - 0000.3058.95b5 SNAP TokenRing1 Internet 192.168.7.254 - 0000.0c1a.a9a8 ARPA Ethernet0 Internet 192.168.14.254 - 0000.0c1a.a9ab ARPA Ethernet1
UNIX workstations also send out gratuitous ARP when initializing alias or VLAN interfaces.
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.
[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" (http://www.ohse.de/uwe/software/utftpd.html).
tftpd-hpa? An enhanced version of the BSD tftpd called tftp-hpa that has TCP wrapper support as well (http://www.kernel.org/pub/software/network/tftp/).
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 ftp://ftp.mamalinux.com/pub/atftp/.
The Solarwinds TFTP server? If you require a TFTP server for Windows, you can use the free tool from Solarwinds (http://www.solarwinds.net).
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 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 Cisco.com 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.
scar# show running-config ... ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 multipoint ip address 10.1.1.3 255.255.255.0 frame-relay map ip 10.1.1.1 160 broadcast ! ...
simba# show running-config ... ! interface Serial0 ip address 188.8.131.52 255.255.255.0 encapsulation frame-relay frame-relay map ip 10.1.1.2 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.