4.5 ARP Examples

4.5 ARP Examples

In this section we'll use the tcpdump command to see what really happens with ARP when we execute normal TCP utilities such as Telnet. Appendix A contains additional details on the tcpdump program.

Normal Example

To see the operation of ARP we'll execute the telnet command, connecting to the discard server.

 bsdi %  arp -a   verify ARP cache is empty  bsdi %  telnet svr4 discard   connect to the discard server  Trying 140.252.13.34...     Connected to svr4.     Escape character is '^]'.  ^]   type Control, right bracket to get Telnet client prompt  telnet>  quit   and terminate  Connection closed. 

While this is happening we run the tcpdump command on another system ( sun ) with the -e option. This displays the hardware addresses (which in our examples are 48-bit Ethernet addresses).

Figure A.3 in Appendix A contains the raw output from tcpdump used for Figure 4.4. Since this is the first example of tcpdump output in the text, you should review that appendix to see how we've beautified the output.

Figure 4.4. ARP request and ARP reply generated by TCP connection request.
graphics/04fig04.gif

We have deleted the final four lines of the tcpdump output that correspond to the termination of the connection (which we cover in Chapter 18), since they're not relevant to the discussion here.

In line 1 the hardware address of the source ( bsdi ) is 0:0:c0:6f:2d:40. The destination hardware address is ff:ff:ff:ff:ff:ff, which is the Ethernet broadcast address. Every Ethernet interface on the cable will receive the frame and process it, as shown in Figure 4.2.

The next output field on line 1, arp, means the frame type field is 0 —0806, specifying either an ARP request or an ARP reply.

The value 60 printed after the words arp and ip on each of the five lines is the length of the Ethernet frame. Since the size of an ARP request and ARP reply is 42 bytes (28 bytes for the ARP message, 14 bytes for the Ethernet header), each frame has been padded to the Ethernet minimum: 60 bytes.

Referring to Figure 1.7, this minimum of 60 bytes starts with and includes the 14-byte Ethernet header, but does not include the 4-byte Ethernet trailer. Some books state the minimum as 64 bytes, which includes the Ethernet trailer. We purposely did not include the 14-byte Ethernet header in the minimum of 46 bytes shown in Figure 1.7, since the corresponding maximum (1500 bytes) is what's referred to as the MTU ”maximum transmission unit (Figure 2.5). We use the MTU often, because it limits the size of an IP datagram, but are normally not concerned with the minimum. Most device drivers or interface cards automatically pad an Ethernet frame to the minimum size. The IP datagrams on lines 3, 4, and 5 (containing the TCP segments) are all smaller than the minimum, and have also been padded to 60 bytes.

The next field on line 1, arp who-has, identifies the frame as an ARP request with the IP address of svr4 as the target IP address and the IP address of bsdi as the sender IP address, tcpdump prints the hostnames corresponding to the IP address by default. (We'll use the -n option in Section 4.7 to see the actual IP addresses in an ARP request.)

From line 2 we see that while the ARP request is broadcast, the destination address of the ARP reply is bsdi ( 0:0:c0:6f:2d:40 ). The ARP reply is sent directly to the requesting host; it is not broadcast.

tcpdump prints arp reply for this frame, along with the hostname and hardware address of the responder .

Line 3 is the first TCP segment requesting that a connection be established. Its destination hardware address is the destination host ( svr4 ). We'll cover the details of this segment in Chapter 18.

The number printed after the line number on each line is the time (in seconds) when the packet was received by tcpdump. Each line other than the first also contains the time difference (in seconds) from the previous line, in parentheses. We can see in this figure that the time between sending the ARP request and receiving the ARP reply is 2.2 ms. The first TCP segment is sent 0.7 ms after this. The overhead involved in using ARP for dynamic address resolution in this example is less than 3 ms.

A final point from the tcpdump output is that we don't see an ARP request from svr4 before it sends its first TCP segment (line 4). While it's possible that svr4 already had an entry for bsdi in its ARP cache, normally when a system receives an ARP request addressed to it, in addition to sending the ARP reply it also saves the requestor's hardware address and IP address in its own ARP cache. This is on the logical assumption that if the requestor is about to send it an IP datagram, the receiver of the datagram will probably send a reply.

ARP Request to a Nonexistent Host

What happens if the host being queried for is down or nonexistent? To see this we specify a nonexistent Internet address ”the network ID and subnet ID are that of the local Ethernet, but there is no host with the specified host ID. From Figure 3.10 we see the host IDs 36 through 62 are nonexistent (the host ID of 63 is the broadcast address). We'll use the host ID 36 in this example.

  telnet to an address this time, not a hostname  bsdi %  date ; telnet 140.252.13.36 ; date  Sat Jan 30 06:46:33 MST 1993    Trying 140.252.13.36...    telnet: Unable to connect to remote host: Connection timed out    Sat Jan 30 06:47:49 MST 1993  76 seconds after previous date output  bsdi %  arp -a   check the ARP cache  ? (140.252.13.36) at (incomplete) 

Figure 4.5 shows the tcpdump output.

Figure 4.5. ARP requests to a nonexistent host.
graphics/04fig05.gif

This time we didn't specify the -e option since we already know that the ARP requests are broadcast.

What's interesting here is to see the frequency of the ARP requests: 5.5 seconds after the first request, then again 24 seconds later. (We examine TCP's timeout and retransmission algorithms in more detail in Chapter 21.) The total time shown in the tcpdump output is 29.5 seconds. But the output from the date commands before and after the telnet command shows that the connection request from the Telnet client appears to have given up after about 75 seconds. Indeed, we'll see later that most BSD implementations set a limit of 75 seconds for a TCP connection request to complete.

In Chapter 18 when we see the sequence of TCP segments that is sent to establish the connection, we'll see that these ARP requests correspond one-to-one with the initial TCP SYN (synchronize) segment that TCP is trying to send.

Note that on the wire we never see the TCP segments. All we can see are the ARP requests. Until an ARP reply comes back, the TCP segments can't be sent, since the destination hardware address isn't known. If we ran tcpdump in a filtering mode, looking only for TCP data, there would have been no output at all.

ARP Cache Timeout

A timeout is normally provided for entries in the ARP cache. (In Section 4.8 we'll see that the arp command allows an entry to be placed into the cache by the administrator that will never time out.) Berkeley-derived implementations normally have a timeout of 20 minutes for a completed entry and 3 minutes for an incomplete entry. (We saw an incomplete entry in our previous example where we forced an ARP to a nonexistent host on the Ethernet.) These implementations normally restart the 20-minute timeout for an entry each time the entry is used.

The Host Requirements RFC says that this timeout should occur even if the entry is in use, but most Berkeley-derived implementations do not do this ” they restart the timeout each time the entry is referenced.



TCP.IP Illustrated, Volume 1. The Protocols
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)
ISBN: 0201633469
EAN: 2147483647
Year: 1993
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net