| Up to now, we've assumed that once we know the IP address of a machine, we can pass data to it. Unfortunately, that's not quite true. To explain why, let's look at the hardware in a little more detail. Every machine in the world capable of being connected to a network is assigned a unique number, which is normally burnt onto a chip when the machine is built. Sometimes, as in the case of a Sun, it may be on the main machine motherboard, while at other times it may be built into a third-party network card. This number is known by a variety of namesthe Ethernet address, the hardware address, or the Media Access Control (MAC) address. An address is a 48-bit number usually written as six colon-separated hex bytes. Each manufacturer is assigned a particular range of numbers and left to assign the remainder as required. For example, Sun has been assigned "8:0:20." An example MAC address on a Sun system would be as follows: 8:0:20:aa:bb:cc It is this address that actually receives the packets, which means we need some way of mapping a system's IP address to its MAC address. To do this, we use a mechanism known as the Address Resolution Protocol (ARP). Determining the MAC Address It's very useful to know the MAC address of a system, as it often helps when trying to troubleshoot network connectivity. For example, a common error is duplicating the IP address of a machine. When they are both connected to the network, an error message along the lines of "Duplicate IP address from 8:0:20:1:2:3" would be seen. Knowing the MAC addresses of the systems would allow us to pinpoint the offending machine. There are various ways to find this out. One is to check the banner message when the system is powered on, which may look similar to that shown below: Sun Ultra 5/10 UPA/PCI (UltraSPARC 440MHz), Keyboard Present OpenBoot 3.25, 1024 MB memory installed, Serial #1234567 Ethernet address 8:0:20:aa:bb:cc, Host ID: 807014ac. Another is to run ifconfig, as shown below: hydrogen# ifconfig hme0 hme0: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.22.1 netmask ffffff80 broadcast 192.168.22.127 ether 8:0:20:aa:bb:cc hydrogen# A third method is to check the ARP tablethis is the cache used by ARP to maintain its IP address to MAC address mappings: hydrogen# arp -a Net to Media Table Device IP Address Mask Flags Phys Addr ------ ------------------ ------------- ----- --------------- hme0 hydrogen 255.255.255.255 8:0:20:aa:bb:cc hme0 indium 255.255.255.255 8:0:20:dd:56:32 hme1 indium 255.255.255.255 8:0:20:dd:56:32 <lines removed for clarity> hydrogen# Multiple Network Cards We can see from the arp output, and also the earlier output from ifconfig, that both network cards configured for indium report the same MAC address. This is because it is burnt into the main system, rather than onto the card itself. Sometimes this can cause problems, such as dropped packets, when communicating with other devices. Even if everything is working OK, some administrators prefer to have a different MAC address for every network interface. This is quite easy to do; we can simply reset it using ifconfig, as shown below: indium# ifconfig hme1 ether 1:2:3:dd:56:32 indium# ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 hme0: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.22.49 netmask ffffff80 broadcast 192.168.22.127 ether 8:0:20:dd:56:32 hme1: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.44.50 netmask ffffff80 broadcast 192.168.44.127 ether 1:2:3:dd:56:32 indium# Choosing the correct value to use is the biggest problem here. If you only use Sun equipment, then the choice is easier since all your MAC addresses should begin with "8:0:20." Some sites even choose the address of a company whose kit they know they will never use! Deleting Table Entries The entries in the ARP cache are deleted after a period of time, but sometimes this may not be soon enough. For example, if a faulty system is swapped for another, but the original IP address is assigned to the new system, then the ARP cache will still contain the original MAC address. This means that data will be trying to locate the original MAC address instead of the new one. In this case, the best procedure would be to delete the entry from the cache and let ARP relocate the new machine. We could do this as shown below: hydrogen# arp hydrogen hme0 hydrogen 255.255.255.255 8:0:20:aa:bb:cc hydrogen# arp -d hydrogen hydrogen (192.168.22.1) deleted hydrogen# ping hydrogen hydrogen is alive hydrogen# arp hydrogen hme0 hydrogen 255.255.255.255 8:0:20:dd:ee:ff hydrogen# Reverse Address Resolution Another protocol very similar to ARP is the Reverse Address Resolution Protocol (RARP). The main difference is that RARP works in the opposite directionwhen it receives a MAC address it determines the correct IP address. This mechanism is commonly used by machines configured to boot across the network (diskless clients, for example). One of their first tasks is to send broadcast RARP requests out to the network, which say something like "My Ethernet address is 8:0:20:aa:bb:cc; can someone tell me what my IP address is?" A machine configured as a RARP server would respond with the correct IP address, and the machine uses that to continue its boot process. Whereas ARP will determine the mappings itself, RARP has to be provided with the correct information. We do this by creating a file named /etc/ethers, which could look similar to the one below: hydrogen# cat /etc/ethers 8:0:20:aa:bb:cc hydrogen 8:0:20:dd:56:32 indium # for info - hme0 1:2:3:dd:56:32 tin # for info - hme1 hydrogen# The RARP server, in.rarpd, will start automatically at boot-time once it detects a valid ethers file. | 
