Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are both key low-level parts of the IP protocol that one encounters every day. ARP is how end devices on the same network segment learn the Layer 2 MAC addresses for one another. ICMP is used for a wide variety of different network control and management functions.
For a device to take part in a Layer 3 protocol such as IP, it has to be able to send and receive these packets through a Layer 2 medium. Suppose a device wants to communicate with another device on the same Ethernet segment. It knows the IP address for this destination device, but, in general, it doesn't know the Ethernet MAC address. The 802.3 protocol says that if this is going to be a point-to-point conversation, then the Ethernet frame must have valid source and destination addresses.
The conversation can't begin until these two devices discover one another's MAC addresses. And, of course, this problem isn't specific to Ethernet. The same problem exists on every Layer 2 network, whether it is Token Ring or ATM. You must have a valid Layer 2 destination address before you can send even the first packet.
This is the problem that ARP solves. For simplicity, I will restrict this discussion to Layer 2 network technology that supports broadcasting. ARP still exists for non-broadcast media such as ATM networks, but it becomes significantly more complicated in these cases.
The solution is remarkably simple. Every device on the network segment receives broadcasts. All one has to do is send out a broadcast packet called an ARP Request and look for the required destination IP address. If one of the devices receiving this packet is the owner of this IP address, it sends back an ARP Reply.
The body of the ARP Request packet contains both the sender and receiver IP and MAC addresses. Some information is, of course, duplicated in the Layer 2 frame header. Since the sender doesn't actually know the receiver's MAC address, it fills in the broadcast address FF:FF:FF:FF:FF:FF.
The ARP Reply then contains similar information. The sender and receiver fields are swapped and the missing MAC address is filled in.
When the first device receives the ARP Reply in response, it puts the information in its ARP Cache. This cache is simply a local table of IP and MAC addresses for all devices it has communicated with recently. This cache allows the first device to avoid another ARP exchange as long as the two devices are in contact. However, if a device is not heard from in a standard timeout period, it is removed from the table. This period is usually about 20 minutes, but individual devices can define it locally.
The first kind of ICMP packet most people think of is a ping. The ping function is an echo request and response facility that allows one to test whether certain devices are reachable on the network. ICMP actually has a wide range of other uses, particularly for reporting network errors.
The ping function is relatively simple. One device sends an ICMP echo request packet to another. The receiving device then responds to this packet with an echo response. This response has many uses, particularly in network management. It is also frequently used by applications that want to verify that a server is available before starting a session. For network management, it provides a simple way to measure end-to-end latency in the network—by taking the time difference between sending the request and receiving the response packet.
ICMP packets also provide a way to report several important error conditions. For example, one fairly common error situation is to have a packet dropped because there is no route available to the destination.
Another important example is when an IP packet is too large to pass through a particular section of the network. Ordinarily, this is not a problem because the router simply breaks up the packet into fragments and passes it along. However, some applications set a flag in their packets to prevent them from being fragmented. In this case, the router has no choice but to drop the packet.
In each of these cases, the router that drops the packet alerts the source device of the problem by sending a special ICMP message. This message allows the application or the user to take appropriate action to fix the problem. In the case of the large packet, the router might simply try again using smaller packets, for example.
Another common and important type of ICMP message is the ICMP Redirect. The redirect is most frequently seen when two or more routers are on the same network segment as the end device. If these routers handle different sets of IP addresses, the end device could inadvertently send a packet to the wrong router. This is particularly common if one of the routers is configured as the default gateway for the end device.
When this happens, the first router simply forwards the packet over to the other router and sends an ICMP redirect message. This message tells the end device that it has delivered the packet, but that, for future reference, another router has a more direct path. The end device should then update its internal routing table to use this second router the next time it sends such a packet.
This issue is particularly important for the network designer to understand because some devices do not respond correctly to ICMP redirection. In these cases, it is often necessary to configure the routers to not send these messages and just to forward the packets. Otherwise, the segment can suffer from extra congestion due to all of the redirection messages—one for every application packet.
In general, I prefer to only have one router on any end device segment, configured as the default gateway for all end devices. As I've mentioned earlier, this router can be made redundant by adding a second router and using HSRP or VRRP. As far as the end devices are concerned, there is only one way off the segment. Network segments built this way should never see any ICMP Redirect messages.