October 10, 2001, 11:23 AM — In March we introduced
the Address Resolution Protocol (ARP), a
half-brother to the TCP/IP stack that maps the logical IP address
space into the real world of Ethernet hardware addresses. We didn't
venture very far away from the safe confines of a local area network
and some simple troubleshooting, which is fine for introducing the
relationships of ARP to IP and various network broadcast activities,
but it doesn't describe the real real world very well. If
you're reading this, you've encountered a byzantine complex of hosts,
routers, desktops, and networks that will lay claim to some measure of
high availability, redundancy and well-ordered connectedness. To keep
the packets flowing from one end to the other, no matter what secret
packet vacuum networks you encounter on the way, you'll need to play
games with IP addresses or MAC addresses and fool clients' ARP
requests into believing your temporary version of network reality --
however cobbled together it might be.
This month we're going to complicate our simple explanation of ARP
with a closer look at stupid networking tricks, starting with the
interactions between the ARP family of protocols and the boot process.
We'll toss some routers into the fray, and look at ways of sending
packets to IP networks that aren't quite where the routers think they
are, and finally we'll show you how to run multiple IP networks on the
same physical network, a necessary strategy for most networking
transition and migration plans. We'll sprinkle hints and pointers
through this conclusion to dealing with things that go bump, ARP, or
otherwise collide in the night.
Double reverse slam-dunks: Reversing the ARP protocol
As we saw in my March column,
ARP is used to locate the hardware, or MAC address for a given IP
address. It takes the logical, 32-bit IP addresses like 192.9.200.1
and associates with it a 48-bit physical address like 8:0:20:45:7:b,
uniquely identifying the machine with the noted IP address. ARP is the
workhorse for establishing IP-level connections to new, previously
uncontacted hosts.
What do you do if you know your own MAC address, but need to find an
IP address to use? Such is the case with diskless clients, network
computers, and PCs that are configured without a name service or file
of hostnames and IP addresses -- they can look up their own MAC
addresses in hardware, but have to ask some network authority to
supply the correct IP address. The most common suppliers of the IP
address are Sun's diskless workstation boot parameter (bootparam)
remote procedure call, the bootp client booting protocol, and the
Dynamic Host Configuration Protocol (DHCP). DHCP is described in
RFC 983,
and is at the heart of many PC-LAN based TCP/IP configurations. All of
these protocols use Reverse ARP (RARP) to match the MAC address to a
corresponding IP address.
RARP differs from ARP in more than just the direction of the lookup;
while ARP is a full-fledged part of a TCP/IP implementation, RARP is
almost always handled in a user-level process on the server side.
You'll see the in.rarpd server daemon opening on
/dev/dlpi (in Solaris) or /dev/nit (in SunOS),
extracting raw RARP broadcast frames off the network. Why bother
implementing a network layer protocol in user space? The short answer
is "configuration control." RARP uses the /etc/ethers file or
the ethers NIS map to correlate MAC addresses to IP
addresses; this is maintained by you, our gentle reader, in the same
manner that IP address-to-host name mappings are noted in a hosts
file. The diskless client booting protocol uses other configuration
files to indicate the location of the root and /usr
filesystems, and DHCP has its own set of user-level files as well.
More information can be found in the manual page for
rarpd.
We're taking this detour through RARP land primarily for completeness.
ARP failures tend to be dramatic and affect entire network segments --
and that's when you're just using the dynamically inserted ARP
entries. We'll look at further complications shortly. ARP troubles
appear as slow or intermittent network connections, hideous network
file access performance, and the occasional broadcast storm. RARP
difficulties, on the other hand, tend to blow up one machine at a
time. You'll see machines that hang during boot or fail to boot
cleanly, or can't configure network interfaces correctly.
If you see messages of the form
