The interfaces of a UNIX gateway can be divided into two groups: logical (virtual) and physical interfaces.
Chapter 5, "Ethernet and VLANs," already introduced the concept of virtual LAN (VLAN) interfaces as an example for a logical interface, as well as alias (secondary) interface configuration. Data link layer address resolution works differently on WAN links. You must consider special Address Resolution Protocol (ARP) issues that are related to point-to-point or point-to-multipoint (Frame Relay) setups.
This chapter introduces the ARP operation as well as the gateway's view of its directly connected physical and logical interfaces. You have already learned in Chapter 5 how they become represented in the kernel routing and ARP tables, and how their deletion or disappearance affects these tables. As you will see, ARP operation can take on different manifestations, such as proxy ARP or gratuitous ARP, regular ARP and reverse/inverse ARP. A discussion of routing table tools (netstat, route, iproute2) concludes the chapter.
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 -?
Usage:
arp [-vn] [
-A, -p, --protocol specify protocol family
-f, --file read new entries from file or from /etc/ethers
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
rarp [
rarp -f add entries from /etc/ethers.
rarp -V display program version.
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.
ARP_filter
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
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
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 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
? (111.11.117.1) 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 castor.nerdzone.org -> ff:ff:ff:ff:ff:ff ARP Who has 192.168.2.7?
Tell 192.168.2.7
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 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
NOTE
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.
NOTE
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
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).
NOTE
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 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.
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 10.1.1.3 255.255.255.0
frame-relay map ip 10.1.1.1 160 broadcast
!
...
Example 7-9. Cisco Frame Relay Point-to-Multipoint Example (Spoke Configuration Fragment)
simba# show running-config
...
!
interface Serial0
ip address 4.0.1.1 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.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
