Shooting Trouble with IP

Protocols and Packets

This section covers some of the protocols, applications, and utilities at each layer of the TCP/IP suite that may assist you with supporting day-to-day internetworks. First the Internet Layer is discussed, then the Transport Layer, and finally the Application Layers. Each layered subsection contains protocol analysis and packet captures, including a review of the packet headers, to help you better understand the packet traces and prepare you for troubleshooting on your own.

Table 3-2 and the following subsections provide a layered perspective of many of the TCP/IP-related protocols, applications, and utilities.

Table 3-2 TCP/IP Protocols, Applications, and Utilities

Frame Types

Encapsulation, frame format, frame type—they all mean the same thing, which is packaging the upper-layer data, voice, or video into an Layer 2 frame. See Chapter 4, "Shooting Trouble with Novell IPX," and the detailed Layer 2 LAN and WAN chapters for frame type information. Part III of this book covers supporting Ethernet, switches, and virtual LANs (VLANs) and Part IV is about supporting the WAN.

Internet Layer Protocols, Applications, and Utilities

Internet protocols such as those listed in the Table 3-2 are well suited for LAN and WAN heterogeneous communications. The Internet suite of protocols includes not only TCP and IP but also many upper-layer applications and utilities for file, print, messaging, database, and other common practical services.

Ensure that your lab is up and running properly so that you spend your efforts on what happens behind the scenes when hosta pings hostc from an IP standpoint. In this section, you turn on your Sniffer on segment 1 and at least capture a ping from hosta to hostc so that you can walk through the fields in the IP header.

Example 3-26 lists in bold the recommended steps to perform from hosta while capturing the packets with Sniffer Pro or the protocol analyzer you are using for your lab.

Example 3-26 Steps Performed on hosta While Capturing the Packets with Sniffer Pro

C:\>ping 192.168.3.5
Pinging 192.168.3.5 with 32 bytes of data:
Request timed out.
Reply from 192.168.3.5: bytes=32 time=20ms TTL=126
Reply from 192.168.3.5: bytes=32 time=10ms TTL=126
Reply from 192.168.3.5: bytes=32 time=10ms TTL=126
Ping statistics for 192.168.3.5:
  Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
  Minimum = 10ms, Maximum = 20ms, Average = 10ms
C:\>ping 192.168.3.5
Pinging 192.168.3.5 with 32 bytes of data:
Reply from 192.168.3.5: bytes=32 time=10ms TTL=126
Reply from 192.168.3.5: bytes=32 time=10ms TTL=126
Reply from 192.168.3.5: bytes=32 time=10ms TTL=126
Reply from 192.168.3.5: bytes=32 time=20ms TTL=126
Ping statistics for 192.168.3.5:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 10ms, Maximum = 20ms, Average = 12ms
C:\>tracert 192.168.3.5
Tracing route to HOSTC [192.168.3.5]
over a maximum of 30 hops:
 1  10 ms  <10 ms  <10 ms 192.168.1.1
 2  20 ms  20 ms  20 ms 192.168.2.2
 3  20 ms  30 ms  30 ms HOSTC [192.168.3.5]
Trace complete.
C:\>pathping 192.168.3.5
Tracing route to HOSTC [192.168.3.5]
over a maximum of 30 hops:
 0 HOSTA [192.168.1.11]
 1 192.168.1.1
 2 192.168.2.2
 3 HOSTC [192.168.3.5]
Computing statistics for 75 seconds...
      Source to Here  This Node/Link
Hop RTT  Lost/Sent = Pct Lost/Sent = Pct Address
 0                      HOSTA [192.168.1.11]
                0/ 100 = 0%  |
 1  0ms   0/ 100 = 0%   0/ 100 = 0% 192.168.1.1
                0/ 100 = 0%  |
 2  20ms   0/ 100 = 0%   0/ 100 = 0% 192.168.2.2
                0/ 100 = 0%  |
 3  20ms   0/ 100 = 0%   0/ 100 = 0% HOSTC [192.168.3.5]
Trace complete.
C:\>arp -a
Interface: 192.168.1.11 on Interface 0x1000005
 Internet Address   Physical Address   Type
 192.168.1.1      00-00-0c-8d-67-05   dynamic
C:\>

Table 3-3 lists the fields of the IP header (packet or datagram), and Figure 3-5 shows the first significant ping lines of the Sniffer packet capture of hosta pinging hostc. Refer to the file chapter 3 ping from hosta to hostc sniffer capture.

Table 3-3 The IP Header (Packet or Datagram)

Figure 3-5 Hosta ARPs the Router

View the summary pane to be aware of the general packet flow when hosta initiated a ping to hostc in Figure 3-5. Hosta is on network 192.168.1.0/24, and hostc is on network 192.168.3.0/24, so hosta relied on its default gateway (local router interface) in which to hand the packets. Line 28 shows the local ARP request as a broadcast command, and line 29 shows the unicast ARP response from 192.168.1.1 (default gateway). Compare this to the arp –a output on hosta back in Example 3-26. Lines 30 to 37 illustrate the ICMP Echo Requests and Echo Replies. Normally, Microsoft hosts issue four requests and four replies, whereas Cisco routers give you five by default. However, there are not four replies here. Look back at Example 3-26 to analyze why.

Move along to the Echo Request packet on line 32 in Figure 3-6. Notice how I sized my windows to see more of the detailed IP header. These are the same fields that are in Table 3-3. Compare them one-by-one until you are comfortable with the IP packet structure (although this will not be your last chance to do this). Also note the differences between the Echo Request and the Echo Reply packet. Figure 3-7 displays the output of an Echo Reply.

Figure 3-6 Analyzing the IP Header of an Echo Request Packet

Figure 3-7 Analyzing the IP Header of an Echo Reply Packet

The main differences you should have noted in the Sniffer traces include the following:

• The source and destination MAC addresses are reversed per the Data Link Control (DLC) header.

• The source and destination IP addresses are reversed per the IP header.

• The Internet Control Message Protocol (ICMP) type is 8 for the Echo Request and 0 for the Echo Reply per the ICMP header.

Real-world packet analysis should make you a little more comfortable with how IP works, but I'll certainly test that out in the upcoming Trouble Tickets. IP is the main protocol at the Internet Layer that has helpers such as ARP and ICMP to assist it with its duties. ARP is for resolving an IP address to a MAC address, whereas Reverse Address Resolution Protocol (RARP) is for resolving a MAC address to an IP address. ICMP is for status and error reporting. Look back at Example 3-26 to see the status lines, such as Reply from..., and the error reporting, such as Request timed out. Obviously, this is why you didn't have four successful replies in the protocol analyzer capture. Also note in the Example that 192.168.3.5 is nowhere to be found in the ARP cache; instead, the default gateway IP and MAC address is there. Example 3-27 displays the e0 interface on r1 so that you can compare this information. Also note that r1 has hosta 192.168.1.11 in its IP and ARP cache.

Example 3-27 r1 Ethernet 0 IP and MAC Addresses

r1#show interfaces ethernet 0
Ethernet0 is up, line protocol is up 
 Hardware is Lance, address is 0000.0c8d.6705 (bia 0000.0c8d.6705)
 Description: e0 to hosta and hostb
 Internet address is 192.168.1.1/24
 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
 Encapsulation ARPA, loopback not set, keepalive set (10 sec)
 ARP type: ARPA, ARP Timeout 04:00:00
 Last input 00:00:00, output 00:00:09, output hang never
 Last clearing of "show interface" counters never
Queueing strategy: fifo
 Output queue 0/40, 0 drops; input queue 1/75, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
   2358 packets input, 361385 bytes, 0 no buffer
   Received 1949 broadcasts, 0 runts, 0 giants, 0 throttles
   0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
   0 input packets with dribble condition detected
   2889 packets output, 320787 bytes, 0 underruns
   0 output errors, 11 collisions, 2 interface resets
   0 babbles, 0 late collision, 15 deferred
   0 lost carrier, 0 no carrier
   0 output buffer failures, 0 output buffers swapped out
r1#show ip cache
IP routing cache 1 entry, 172 bytes
  5 adds, 4 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
  quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Prefix/Length     Age    Interface    Next Hop
192.168.1.11/32     03:02:54 Ethernet0    192.168.1.11
r1#show arp
Protocol Address           Age (min) Hardware Addr  Type  Interface
Internet 192.168.1.11      34        0010.4ba5.ae50 ARPA  Ethernet0
Internet 192.168.1.1       -         0000.0c8d.6705 ARPA  Ethernet0
Internet 192.168.4.1       -         0000.0c8d.6706 ARPA  Ethernet1
Internet 192.168.4.2       42        0000.0c38.a05d ARPA  Ethernet1
r1#

I want to continue the layered approach to discussing TCP/IP, so next the discussion moves up the stack to the Transport Layer. After I discuss the Transport and Application Layers, I spend a bit more time on addressing and protocols before venturing into the Trouble Tickets.

Transport (Host-to-Host) Layer Protocols, Applications, and Utilities

Recall from the OSI model in Chapter 1, the Transport Layer is all about host-to-host delivery. TCP and UDP are the Transport Layer twins. TCP is connection-oriented (logical connection) and reliable (ACKs).

UDP, like IP at the Internet Layer, is connectionless and unreliable; therefore it relies on the upper layers for reliability. TCP is like the certified mail protocol, whereas UDP is like the regular mail (or better yet, bulk mail) protocol.

UDP is connectionless, which means it does not require an established connection before communications can occur. It is unreliable at the Transport Layer, which means that its reliability is left up to the application. Compare the TCP and UDP packet formats in Tables 3-4 and 3-5.

Table 3-4 The TCP Segment

Table 3-5 The UDP Datagram

The 20-byte TCP header is a lot more sophisticated than the 8-byte UDP header, as you will again confirm with Sniffer. First, open the previous Sniffer Pro trace where you issued the ping and tracert commands in Example 3-26. I named my file chapter 3 ping from hosta to hostc sniffer capture. Use this file to analyze the layers or refer to Figure 3-8, in which I emphasize the layers of a RIP packet.

Although the focus in this subsection is the Transport Layer, remember that each layer depends on the functionality of another layer to carry out communications. The Sniffer trace certainly illustrates that. For example, the RIP packet at the Data Link Layer is a good example of multicast communications. RIPv2 works via multicast address 01005E000009 at Layer 2, whereas RIPv1 works via broadcast, which would be shown as all Fs at Layer 2. The EtherType is 0800, which tells the Data Link Layer to hand off to IP at the Internet Layer for further processing.

Review the IP header fields—Version, Header length, TOS, Total length, Identification, Flags, Fragment offset, TTL, Protocol, Checksum, Addresses, and Options. The IP header contains the Protocol field to hand off to at the next layer in the stack. In Figure 3-8, for example, the protocol number is 17, which means to hand up to UDP. The source address is the Ethernet 0 interface on r1, and the destination is again the reserved multicast address of 224.0.0.9 for RIPv2, but this time at the Internet Layer.

IANA has reserved addresses from 224.0.0.0 through 224.0.0.255, such as those in Table 3-6, for local multicasts.

Figure 3-8 Analyzing the RIP Packet at Layers 2, 3, and 4

Table 3-6 Local Multicast Addresses

Globally scoped addresses from 224.0.1.0 through 238.255.255.255 can be used to multicast data between organizations and across the Internet. An example of an IANA reserved address is 224.0.1.1 for Network Time Protocol (NTP).

In addition, IANA owns a block of Ethernet MAC addresses that start with 01:00:5E, where half of the block (0100.5e00.0000 through 0100.5e7f.ffff) is allocated for multicast addresses. In the Ethernet address, 23 bits correspond to the IP multicast group address. Search for "ethernet mac multicast" at Cisco.com to get a detailed explanation and pictures. With this mapping, the upper 5 bits of the IP multicast address are dropped and the resulting address is not unique, which results in different multicast group IDs that all map to the same Ethernet address. The Internet Group Management Protocol (IGMP) dynamically registers individual hosts in a multicast group. The hosts send IGMP messages to their router. The routers listen and periodically send out queries to discover which groups are active or inactive on a particular subnet.

The Transport Layer contains the fields listed Table 3-5 for the UDP datagram. RIP works via UDP port 520, which is clearly revealed here. UDP port 520 is how the Transport Layer hands off to the Application Layer for RIP communications (as discussed in more detail later). For now, look at the details of TCP.

TCP provides end-to-end full-duplex delivery, flow control through windowing, and error-detection and -correction services. Data moves in a continuous byte stream, in which bytes are identified by sequence numbers. TCP hides lower-layer intricacies from the upper layers on the receiving host. It segments and re-assembles data for upper-layer applications based on various port numbers. Unlike UDP, however, a 3-way handshake must occur before communications can begin. This establishes the virtual connection between the two communicating parties (see Figure 3-9).

Figure 3-9 The TCP 3-Way Handshake Sequence

A good example of an application that uses TCP is telnet. Try it out and telnet from hosta (at the command prompt) to r1. Capture your results with Sniffer (see Figure 3-10). Save the Sniffer file as chapter 3 telnet from hosta to r1 sniffer capture so that you can refer back to it later. Analyze your own capture or look at my Sniffer trace. It may prove helpful to use the Sniffer output to label the 3-way handshake in Figure 3-9, including flags, ports, sequence, and acknowledgement numbers.

Figure 3-10 Analyzing Telnet and the 3-Way Handshake

In the preceding example, hosta was configured with the local router IP address as its default gateway. Because of this, hosta sent an ARP request packet to its default gateway to learn the MAC address of the Ethernet 0 interface on r1. The command arp –a on the host would have shown this, whereas show ip arp is the command on the router. ARP frames are not part of the 3-way handshake or TCP session, but are certainly required for hosta to transmit data.

Study TCP in the Sniffer capture and drawing. It is often referred to as the 3-way handshake. Step 1 of the 3-way handshake (SYN) is like me introducing myself to you and giving you my basic communication parameters so that we can talk. Step 2 is like you saying, "Okay (ACK), Donna, I want to talk, too; here are my communication parameters (SYN)." Step 3 is my okay (ACK) to you. After a 3-way handshake, the two communicating parties are virtually connected and TCP communications can then occur. Some applications require multiple handshakes. A bona fide example is anything involving the World Wide Web (WWW). Every time you click a link on a web page, another TCP session starts. Another example is a phone call. The connection is set up and you talk; then the logical connection is torn down and is available for someone else.

Next look a little closer at the exact packets in the Sniffer capture for the 3-way handshake. You can glean a lot from the summary pane on this one, but the detail pane is shown as well. The shaded line 7 starts the handshake described in Figure 3-9. It shows the SYN from hosta (192.168.1.11) to the router (192.168.1.1). The source port (S) is random (ephemeral) port number 1079, but the destination port is the well-known port number 23 for telnet.

Ports are places to leave stuff for applications to pick up, as you will continue to see throughout this book. A client typically establishes a port within first 4 bytes of the Transport Layer header. Notice how the ports reverse depending on who is doing the talking, hosta or the router. Line 8 shows the router responding back to hosta with ACK number ...2608, which if you look close is one more than the previous SEQ number of ...2607. The SEQ of Step 2 of the handshake is ...3396. Step 3 of the handshake in line 9 ACKs the previous SEQ number with ...3397. When the TCP session has been established, the numbers increment by the actual number of bytes transferred.

Instead of analyzing the telnet details, I want you to pay attention to the TCP session tear down next. Open your Sniffer capture and refer to the very end of the file as I illustrate in Figure 3-11.

Figure 3-11 TCP Session Disconnect

Frame 132 starts the TCP disconnect with the FIN flag from the router. Hosta ACKs in frame 133 and says, "Hey, I am also finished," in frame 134 (FIN). The router gives the final ACK in the last frame. A 4-way disconnect like this is common.

Next I want you to think outside the box a little. What would have happened if the default gateway was not configured on the host or if the router was not local in the preceding testing? You can give me the number one phrase that most support people give, which is, it depends; as usual, however, I'll cringe at that answer. In many cases, however, that is the best answer. Actually, the packets may still get to their destination assuming proxy ARP is enabled on the router and that hosta will ARP for nonlocal destinations.

Proxy ARP helps hosts reach remote subnets without configuring routing or a default gateway. Configuring the host with a smaller subnet mask would make the host ARP for everything and thus send all packets via the router. The router just replies to the host with its MAC address assuming that it is configured to accept and respond to proxy ARP. Obviously, there are security and overhead disadvantages to proxy ARP. The Cisco IOS interface command no ip proxy-arp turns this off and is shown in Example 3-28.

Example 3-28 Proxy ARP

r1#show run interface ethernet 0
interface Ethernet0
 description e0 to hosta and hostb
 ip address 192.168.1.1 255.255.255.0
 no ip directed-broadcast
end
r1#configure terminal
r1(config)#interface ethernet 0
r1(config-if)#no ip proxy-arp
r1(config-if)#end
r1#show run interface ethernet 0 
interface Ethernet0
 description e0 to hosta and hostb
 ip address 192.168.1.1 255.255.255.0
 no ip directed-broadcast
 no ip proxy-arp
end
r1#configure terminal
r1(config)#interface e0
r1(config-if)#ip proxy-arp 
r1(config-if)#end

Prior to the thinking outside the box exercise, you were working with telnet, which is an application based on TCP port 23. TCP port 23 is the pointer from the Transport Layer to the Application Layer, just as the IP packet contains a protocol number such as 6 to link to the Transport Layer TCP protocol for further processing. Figure 3-12 shows this layer linkage for the UDP and TCP applications you previously examined. You can always compare this to your saved Sniffer traces to validate the theory from the lower layers to the upper layers.

Figure 3-12 Protocols, Applications, and Utilities

Many applications have well-known port numbers assigned. Ports greater than 1024 are referred to as ephemeral, random, short-lived, or temporary, whereas numbers below 1024 are considered well-known ports.

Figure 3-13, http://www.iana.org, and RFC 1700 provide you with more detail. Ports are often categorized as follows:

• 0–1023 Well-known

• 1024–49151 Registered

• 49152–65535 Dynamic (private)

Figure 3-13 Application Port Numbers

As you have seen in the previous subsections, after you have eliminated Physical Layer issues, protocol connections are troubleshooting targets that must be considered. After the protocol connections have been confirmed as operational, it is time to move up to the Application Layers. I could not begin to cover the vast variety of upper-layer applications in use today, but I will introduce some of the major Application Layer protocols of the TCP/IP suite.

Upper-Layer Protocols, Applications, and Utilities

This subsection covers applications such as telnet, FTP, TFTP, SMTP, POP3, DNS, SNMP, RIP, HTTP, HTTPS, and DHCP. Obviously, these are not the only applications you will need to troubleshoot, but they are very common.

First look at the terminal emulation protocol telnet from an application perspective. Review Figures 3-9 and 3-10 and your Sniffer capture file (chapter 3 telnet from hosta to r1 sniffer capture). Figure 3-14 illustrates the telnet session from hosta on port 1079 to r1 on port 23. Line 10 starts the telnet session, which was dependent on the TCP 3-way handshake in lines 7, 8, and 9. Notice the echo, window size, and terminal negotiation in lines 10 to 15. Frame 12 is waiting for the login that eventually appears in lines 17 to 25 one character at a time. In addition, notice how that after the user-level password I typed the necessary command and password to get into enable mode. Although I do not show all this in the screen capture of Figure 3-14, if you have your own file you can see the rest of the commands that were typed on the router, letter for letter. It is pretty obvious here that the standard telnet programs do not encrypt the login information, and I doubt that this is what you want people to see when you telnet to your devices to configure them. In the real-world application of telnet where security is more of a concern, many people use secure telnet programs (Secure Shell [SSH] port 22). Examples include SecureCRT, CommNet, and PuTTY.SSH.

Figure 3-14 Telnet from an Application Perspective

Next look at TFTP and FTP. As I illustrated in Figure 3-13, TFTP typically operates over UDP port 69, and FTP typically operates over TCP port 21 for control and 20 for data. When I say typically, I really mean that this is entirely up to the developer. FTP and TFTP are very useful applications in the support environment. For instance, what happens if you lose the configuration on one of your routers? Hopefully, you have an automated way to restore it instead of having to type in the configuration line-for-line.

To test TFTP, I am using a freeware program called PumpKin in Figure 3-15. You can download PumpKin, set up another router as a TFTP server, or use any TFTP application you like. I started and configured PumpKin to put and get all files, started a new Sniffer capture, and proceeded to copy my r1 configuration file to the TFTP server for this test. You should even go a few steps further to wipe your configuration with the erase startup-config or write erase command to ensure this really works. After all, this is the type of thing you should do in a lab environment many times so that you are prepared for the unexpected. Use Example 3-29 as a guide for this exercise.

Save the Sniffer file as chapter 3 tftp from r1 to hosta and back sniffer capture for further review.

Figure 3-15 Using PumpKin for a TFTP Server

Example 3-29 Copying r1 Configuration to a TFTP Server

 r1#copy running-config tftp
Address or name of remote host []? 192.168.1.11
Destination filename [running-config]? hosta-config
!!
1093 bytes copied in 5.888 secs (218 bytes/sec)
r1#erase startup-config
Erasing the nvram filesystem will remove all files! Continue? [confirm]
[OK]
Erase of nvram: complete
!!!The next 2 shaded commands are not necessary for the tftp exercise
!!!However, it is a good time to review when files are replaced or 
!!!just modified.
r1#copy startup-config running-config
Destination filename [running-config]? 
r1#show running-config
Building configuration...
Current configuration:
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname r1
enable password donna
ip subnet-zero
ip host r1 192.168.1.1 192.168.2.1 192.168.4.1 10.1.1.1
ip host r2 192.168.4.2 192.168.5.1 192.168.6.1
ip host r3 192.168.2.2 192.168.5.2 192.168.6.2 192.168.3.1 10.2.2.1
ip host r4 10.2.2.2
ip host r5 10.1.1.2
...!

Next reload the router as in Example 3-30.

Example 3-30 Reloading the Router

r1#reload
Proceed with reload? [confirm]
02:21:13: %SYS-5-RELOAD: Reload requested
System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE
Copyright 1986-1995 by cisco Systems
2500 processor with 2048 Kbytes of main memory
F3: 7464832+102636+503004 at 0x3000060
       Restricted Rights Legend
...
Cisco Internetwork Operating System Software 
IOS (tm) 2500 Software (C2500-IS-L), Version 12.0(5), RELEASE SOFTWARE (fc1)
Copyright 1986-1999 by cisco Systems, Inc.
Compiled Tue 15-Jun-99 19:57 by phanguye
Image text-base: 0x0303D744, data-base: 0x00001000
cisco 2500 (68030) processor (revision L) with 2048K/2048K bytes of memory.
Processor board ID 03074719, with hardware revision 00000000
Bridging software.
X.25 software, Version 3.0.0.
2 Ethernet/IEEE 802.3 interface(s)
2 Serial network interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read ONLY)
%Error opening tftp://255.255.255.255/network-confg (Timed out)
%Error opening tftp://255.255.255.255/cisconet.cfg (Timed out)
SETUP: new interface Ethernet0 placed in "shutdown" state
SETUP: new interface Ethernet1 placed in "shutdown" state
%Error opening tftp://255.255.255.255/network-confg (Timed out)
%Error opening tftp://255.255.255.255/cisconet.cfg (Timed out)
%Error opening tftp://255.255.255.255/router-confg (Timed out)
%Error opening tftp://255.255.255.255/ciscortr.cfg (Timed out)
Press RETURN to get started!
...
00:03:45: %SYS-5-RESTART: System restarted --
Cisco Internetwork Operating System Software 
IOS (tm) 2500 Software (C2500-IS-L), Version 12.0(5), RELEASE SOFTWARE (fc1)
Copyright 1986-1999 by cisc
Router>o Systems, Inc.
Compiled Tue 15-Jun-99 19:57 by phanguye
Router>enable
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface ethernet 0
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#no shut
...
Router(config-if)#end

Now copy the file from the TFTP to r1 as in Example 3-31. By the way, a router with no configuration is often referred to as a router out of the box (ROTB).

Example 3-31 Copying the Configuration from the TFTP Server

Router#copy tftp running-config
Address or name of remote host []? 192.168.1.11
Source filename []? hosta-config
Destination filename [running-config]? 
Accessing tftp://192.168.1.11/hosta-config...
Loading hosta-config from 192.168.1.11 (via Ethernet0): !
[OK - 1093/2048 bytes]
1093 bytes copied in 5.124 secs (218 bytes/sec)
r1#copy running-config startup-config
Destination filename [startup-config]? 
Building configuration...

In the preceding example, I copied my file to a TFTP server and made sure it was really there. Then I performed an erase start on the router to erase the startup configuration. When I tried to overwrite the running configuration with the startup configuration, however, it acted as a merge, which is what you should expect. To really get rid of the running configuration, you must reload the router; so I did. When the router came back up, it had no configuration, but it was certainly looking for one (as you can see from the shaded output in Example 3-30). Next I configured the IP address on the Ethernet 0 interface and issued a no shut. If the TFTP server were not local, a default gateway would be required as well. Now that I had TCP/IP communications, I continued and copied the configuration file from the TFTP server back to the router and saved the configuration.

TFTP and FTP can assist you with saving configurations and IOS images depending on your IOS version. To explore the differences, save the TFTP capture or refer to my Sniffer files to later compare it to FTP. Make a list of the major differences as you observe the two applications.

Before you experiment with FTP, take a few minutes to decode the TFTP Sniffer capture. The shaded line in Figure 3-16 highlights a TFTP write request, which Sniffer portrays as opcode 2 in the detail pane. Lines 63 to 69 include the actual file transfer. Line 64 is an opcode 3 and is the first data packet transfer. Notice that the first block, or 512 bytes, of data was transferred and line 65 is the application acknowledgement to the first data packet with an opcode 4. Table 3-7 lists the common opcodes.

Table 3-7 OpCodes

Figure 3-16 TFTP Write Request

Also note that the Sniffer trace does not in any way hide the configuration while it is transferring. Figure 3-17 shows the ending configuration, including passwords. Notice how you can read the entire configuration file when you open each data packet individually.

Using the Sniffer capture, take a few minutes to draw a simple picture of what happens when you transfer a file using TFTP. Include communications between r1 and hosta, including line numbers, ports, and opcodes, as I did in Figure 3-18.

Many UDP-based applications such as some implementations of TFTP and DNS use a fixed data length (such as 512 bytes) to operate, but the maximum per segment is 65535 bytes.

Figure 3-17 TFTP Clear Text

Figure 3-18 TFTP Communications

As you verified in the previous figures, TFTP transfers text in the clear. Use FTP to perform the same file transfer as in the TFTP exercise. Actually, I transferred the configuration from r1 and r2 to the FTP server in my test. Any FTP application is appropriate. I am using 3CDaemon in Figure 3-19, a freeware program I downloaded from support.3com.com/infodeli/swlib/utilities_for_windows_32_bit.htm for the lab in Example 3-32. Use Sniffer to capture the results, analyze your findings, list or draw a picture of what happens when you transfer a file using FTP, and, last but not least, compare the two IP-based applications.

Figure 3-19 FTP Server Software

Example 3-32 Copying r1 and r2 Configuration to an FTP Server

r1(config)#ip ftp username anonymous
r1(config)#ip ftp password donna@shoretraining.com
r1(config)#end
r1#copy running-config startup-config
r1#copy running-config ftp
Address or name of remote host []? 192.168.1.11
Destination filename [running-config]? r1-config
Writing r1-config !
1169 bytes copied in 8.836 secs (146 bytes/sec)
...

I did not take the time to erase my configuration and test this out as I did with the TFTP example. If you need more practice, you can do just that. My chapter 3 ftp from r1 and r2 to hosta sniffer capture file displays in Figure 3-20. Follow the TCP sessions and data transfer, including the sequence and acknowledgement numbers for a review.

Figure 3-20 FTP Write Request

Feel free to draw a more specific picture with line numbers, ports, and sequence and acknowledgement numbers. However, the following gives a general picture of how FTP works:

• ARP and TCP 3-way handshake (FTP control port 21)

• FTP user login (anonymous) and password (donna@shoretraining.com)

• TCP 3-way handshake (FTP data transfer port 20)

• FTP data transfer (clear text)

• Session tear down (data port 20)

• Session tear down (control port 21)

The main difference is that the program I used for the test does not use an individual port 20 for each data transfer, but instead uses a separate ephemeral port.

You should have notes similar to the following to compare TFTP and FTP communications:

• The client uses an ephemeral port to initiate communications to TFTP server port 69 and the server picks an ephemeral port to respond to the client. FTP uses port 21 for control and a separate port 20 for file transfer, and the server port doesn't need to change for multiple clients because of the TCP session.

• No login, username, or password is used for TFTP. FTP requires login and can allow anonymous login with the e-mail address for the password.

• TFTP transfers a minimum of 512 bytes of data per datagram, and the application ACKs each one individually because UDP has no reliability mechanism; FTP, on the other hand, uses a TCP session for each file transfer.

• TFTP and FTP use clear-text data transmission. FTP secure implementations are available.

In addition, TFTP and FTP are very helpful in the Cisco environment to copy not only configurations but also Cisco Operating System images. Many times I set up my router as a TFTP server so that I can copy the IOS to another location. Appendix B provides more detail on such topics.

As you can see, it is helpful to understand the basics of how applications work to more easily troubleshoot them. Next take a look at the Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP3) in Figure 3-21.

Figure 3-21 SMTP and POP3

SMTP is like the mail truck delivering from post office to post office. If you work for Cisco Press and you want to set up your mail client to send your mail, for example, you may set up smtp.ciscopress.com, which by default occurs on TCP port 25.

POP3 is more of a server to the client mail delivery protocol that operates by default on TCP port 110. Therefore if you work for Cisco Press and want to set up your mail client, you may set up pop3.ciscopress.com to receive your mail.

Assume user@ciscopress.com wants to send an e-mail to donna@shoretraining.com. That user clicks Send and SMTP is used to transfer the e-mail from the user to his mail server using SMTP TCP port 25. The mail server delivers the mail to the shoretraining.com domain over port 25. When I check my mail on shoretraining, my e-mail program establishes a connection to my mail server over POP3 port 110.

Knowing the overall SMTP/POP3 delivery process may assist you with troubleshooting your e-mail one day. For example, I have been in situations where I could send e-mail but not receive, which turned out to be a POP3 issue. Perhaps a particular port or address was blocked by an access list. I have also been in situations where the opposite occurs. For example, many times you may have the luxury of using a higher-speed network connection but your ISP may not allow you to "relay" through another system. However, troubleshooting e-mail issues happens to be another book in itself (as are most applications).

DNS is another application that it is quite helpful to understand in the support world. I would much rather type http://www.cisco.com than its IP address every time I want to look up something on Cisco.com. DNS maps an IP address to a hostname so that humans can relate to it a little better.

Hostname resolution once was a flat hosts file, but who would have enough memory to open such a thing today? Hosts files are still available for use, however. You have them on each of your routers now. Type show hosts with me on r1 as in Example 3-33.

Example 3-33 Cisco Hosts File

r1>show hosts
Default domain is not set
Name/address lookup uses domain service
Name servers are 255.255.255.255
Host           Flags   Age Type  Address(es)
r1            (perm, OK) 23  IP  192.168.1.1 192.168.2.1
                        192.168.4.1 10.1.1.1
r2            (perm, OK) 23  IP  192.168.4.2 192.168.5.1
                        192.168.6.1
r3            (perm, OK) 23  IP  192.168.2.2 192.168.5.2
                        192.168.6.2 192.168.3.1
                        10.2.2.1
r4            (perm, OK) 23  IP  10.2.2.2
r5            (perm, OK) 23  IP  10.1.1.2

Hosts files on PCs are typically found in locations such as \Windows, \Etc, \Winnt\System32\Drivers\Etc and are named hosts. Reference Figure 3-22 for a sample Windows 2000 hosts file.

Figure 3-22 Windows 2000 Hosts File

The other files listed in Figure 3-22 can be quite helpful, too. Lmhosts is for NetBIOS name resolution. The other files contain common network, protocol, and port numbers. At the upper layers, I often ask myself whether a hostname or a NetBIOS issue exists. Figure 3-23 provides some examples, as does Table 3-1 earlier in this chapter.

Figure 3-23 Name and Address Resolution

DNS is hierarchical in nature; therefore, fully qualified domain names (FQDN) must be unique. Upper-level domain names include such domain names as com, edu, net, and gov. Second-level domain names must be registered. For example, ciscopress.com and shoretraining.com are both part of the top-level com domain. Cisco Press has authority over what they do under ciscopress.com, and I have control over what I do under shoretraining.com. Obviously, these second-level domains must be registered through Internet service providers (ISPs) or companies such as VeriSign.

The name space contains domains, subdomains, and hosts. The servers contain zones, which are database files with various record types. Common record types include alias (canonical name) or mail (MX) records.

Why do you care? Name resolution is certainly something to check for in the upper layers. If you can ping the IP address but not the hostname, for example, chances are you have a hostname resolution issue. If you can issue a Start > Run \\192.168.1.12 but not a Start > Run \\hostb, the problem is probably NetBIOS name resolution. These could in turn be DNS or WINS issues, depending on the applications and settings in your environment.

If you were capturing DNS information with Sniffer, you would see that queries typically are done over UDP port 53, whereas zone transfers are completed over TCP port 53. Next take a look at SNMP, which is everything but simple.

SNMP was originally for remote management of network hardware devices, but today is used for lots more. A management console sends a request to an agent (managed device) over UDP port 161, and the agent generates a trap on port 162 to a specific address. An agent really can't initiate anything on its own, but it can notify the manager of events, such as a link up or down or a software mail problem. The requests are part of a database referred to as a Management Information Base (MIB) in the SNMP world. Communities are groups that talk to one another to assist with security, and public is the default community. CiscoWorks, Cisco Info Center (CIC), and HP OpenView are examples of network management platforms that support SNMP-based management.

Next I review the RIP application. RIP is the routing protocol you set up earlier in the chapter so that one end system could get to another end system. RIP is an application that operates over UDP port 520. RIPv2 still operates over UDP port 520, but it uses 224.0.0.9 as a destination IP multicast address. Although each of the prefix entries includes a mask, RIPv2 is more considerate of the hosts, which are not interested in its messages, because their NICs will filter the frames at Layer 2. Figure 3-24 enables you to analyze the RIP header. Does my capture display RIPv1 or RIPv2?

Figure 3-24 RIP

You are correct if you said Figure 3-24 displays RIPv2 because the destination is the multicast 224.0.0.9 address rather than a local broadcast.

Now look at another application that is common in a day-to-day environment; Hypertext Transport Protocol (HTTP) uses TCP port 80 to provide web services. It also uses clear-text data transmission. Obviously this is a very big issue with purchasing items over the Internet. E-commerce applications make use of more secure protocols such as HTTPS over TCP port 443. If you compare a Sniffer trace of HTTP and HTTPS traffic, the HTTPS data is encrypted. Figure 3-25 shows you what people can sniff when you use HTTP to access a switch. I had to turn port monitoring on for this to work. Those details are covered more depth in the switch chapters, Chapter 6, "Shooting Trouble with CatOS and IOS," and Chapter 7, "Shooting Trouble with VLANs on Routers and Switches." For now, analyze the layered approach to HTTP as you have done with the other applications.

Figure 3-25 HTTP to a 1900 Switch

Now that I have touched on all the layers of the TCP/IP suite to lead into the addressing section, I will discuss DHCP. First there was RARP, then BOOTP, and now DHCP. The basic concept is the same. Take RARP, for example. It is used to resolve MAC addresses to IP addresses. It is the opposite of ARP, with which I know you have become pretty comfortable by now. The Bootstrap Protocol (BOOTP) was developed to allow diskless workstations to obtain IP information upon bootup. BOOTP spawned DHCP, which is widely used today.

DHCP is not fully automatic because someone must configure the server with a range of IP addresses (scope) and other optional parameters such as the mask, gateway, DNS server, WINS server, and so on. Clients request DHCP parameters via Layer 2 and Layer 3 broadcasts to UDP port 67. The server sends messages to the client on UDP port 68. However, it would defeat the purpose of a router if it were allowed to forward all broadcasts. On the other hand, it is possible for you to open up certain ports for routers to forward via the ip helper-address [ipaddress] command. Request forwarding is also possible via DHCP proxy agents. Figure 3-26 provides examples of the ip helper command. Helpers in effect change the local broadcast destination to a unicast or directed broadcast to reach the DHCP server. Table 3-8 shows DHCP frames that you should capture sometime with a protocol analyzer.

Figure 3-26 IP Helper

Table 3-8 DHCP Frames