Analyzing Commands and Applications Used to Isolate Problems Occurring at the Physical and Data Link Layers

This section covers commands that you use to isolate problems at the physical and data link layers. This section also demonstrates isolating problems at physical and data link layers through some examples.

Table 7-2 shows end system commands used to isolate problems at the physical and data link layers. The first part of this table lists general commands. The second section lists commands you enter at an end system running a version of the Windows operating system. In the third part of Table 7-2, commands shown are those you enter at an end system running a version of the UNIX or Mac OS X operating system. These commands display information about several networking layers. You use the output to isolate problems at the physical and data link layers.

Table 7-2 End System Commands to Isolate Physical and Data Link Layer Problems

Command

Type

Description

ping {host | ip-address}

General End System

Sends an echo request packet to an address and then waits for a reply. The {host | ip-address} variable is the IP alias or IP address of the target system.

arp -a

General End System

Displays the current mappings of the IP address to the MAC address in the ARP table.

Netstat [-rn]

General End System

The netstat command displays active TCP/IP connections. The -rn option is for displaying the routing table in numerical format (without querying a Domain Name System [DNS] server).

ipconfig /all

Windows Command

Displays IP information for hosts that are running Windows NT/Windows 2000/Windows XP.

Tracert [destination]

Windows Command

Verifies connectivity (and displays a path) to a destination device for Windows hosts. The destination variable is the IP alias or IP address of the target system.

Winipcfg

Windows Command

Displays IP information for hosts that are running Windows 9x and Windows Me.

ifconfig -a

UNIX and Mac OS X

Displays IP information for UNIX and Mac OS X hosts.

traceroute [destination]

UNIX and Mac OS X

Identifies the path that a packet takes through the network. The destination variable is the host name or IP address of the target system.

The commands listed in Table 7-3 are Cisco IOS commands that display information about several networking layers. Although you can use these commands to display information about several networking layers, these commands are also important for isolating problems at the physical and data link layers. Table 7-3 indicates which of the two layers each command is best for isolating according to the CIT student guide.

Table 7-3 General Physical and Data Link Layer Isolation Cisco IOS Commands

Command

Description

ping {host | ip-address}

(User or Privileged) Sends an echo request packet to an address and then waits for a reply. The {host | ip-address} variable is the IP alias or IP address of the target system.

Best for isolating the physical and data link layers.

traceroute [destination]

(User or Privileged) Identifies the path a packet takes through the network. The destination variable is the IP alias or IP address of the target system.

Best for isolating the physical and data link layers.

[no] debug ?

Displays a list of options for enabling or disabling debugging events on a device.

Best for isolating the physical and data link layers.

show version

Displays the Cisco IOS software version and all installed hardware configurations.

Best for isolating the physical layer.

show ip interface brief

Displays a summary of the status of all interfaces on a device.

Best for isolating the physical layer.

show interfaces [type number]

Displays the operational status of an interface as well as the amount and type of traffic being sent and received.

Best for isolating the physical layer.

Table 7-3 General Physical and Data Link Layer Isolation Cisco IOS Commands (Continued)

Command

Description

show cdp neighbor detail

Displays the device type and Cisco IOS version of neighboring devices.

Best for isolating the physical layer.

show controllers

Displays current internal status information for the interface controller cards.

Best for isolating the physical layer.

debug [asynch | ethernet-interface | frame-relay | isdn | ppp | serial]

Captures events on physical interfaces. Best for isolating the physical layer.

show arp

Displays entries in the ARP table. Best for isolating the data link layer.

debug [arp | lapb | stun]

Captures events relating to data link layer protocols. Best for isolating the data link layer.

NOTE The show command shows a snapshot of the current characteristics of the network device interface or protocol. debug shows you the events taking place from the time the command is entered until reporting is disabled. Using debug commands places more of a negative impact on the performance of a networking device than isolating a problem with show commands. Therefore, it is a good idea to isolate a problem using only show commands when possible. If the information returned from entering show commands does not help you isolate a problem, use debug commands that are targeted at what is the most likely cause of the problem.

Now look at some examples that demonstrate isolating problems at physical and data link layers using these commands.

Consider two routers—one named SanFran and the other named SanJose—that are located in different cities (see Figure 7-1). The routers are connected via a T1 link. (E1 is a similar service in Europe.)

Figure 7-1 T1 Connection (Similar to the European E1) Between Two Routers at Remote Branches

Figure 7-1 T1 Connection (Similar to the European E1) Between Two Routers at Remote Branches

While you are configuring SanFran, you observe a console message that indicates a physical layer issue. To isolate the problem and confirm that the system message is not transient, you decide to use a Cisco show command that will display a summary of the status of the interface. Entering the show ip interface brief command shows that the interface named serial 1/0 is up, but the line protocol is down. (See the top portion of Example 7-4.)

Example 7-4 Gathering Information to Isolate a Physical Layer Problem on a Cisco Router

SanFran#show ip

interface brief

Interface

IP-Address

OK? Method Status Protocol

FastEthernet0/0

10.141.148.129

YES NVRAM up

up

Serial1/0

10.141.147.2

YES manual up

down

SanFran#

SanJose#show ip

interface brief

Interface

IP-Address OK?

Method Status

Protocol

FastEthernet0/0

10.141.141.1 YES

NVRAM up

up

Serial1/0

10.141.147.1 manual administratively down down

SanJose#

To continue with problem isolation, you use your dial-up modem to connect to the console session on the SanJose router. There you use the show ip interface brief command. The output of this command shows that interface Serial 1/0 on SanJose is administratively down, or that the interface is not configured to be active. The line protocol is also in the down state. (See the bottom portion of Example 7-4.) For Cisco routers, the default interface state is shutdown. Your associate forgot to activate the interface when it was configured. To fix this problem, you need to activate the interface using the no shutdown command.

As a second example, assume that you are the network engineer for a router named Orlando. Orlando uses Frame Relay to connect to a router named Daytona (see Figure 7-2).

Figure 7-2 Frame Relay Connection Between the Remote Branches at Daytona and Orlando

Figure 7-2 Frame Relay Connection Between the Remote Branches at Daytona and Orlando

Now imagine that Network Operations calls to inform you that the link to Daytona is down. You ask if anyone had made changes to the configuration of Orlando. Network Operations says that it made no changes. Example 7-5 shows a console message that Network Operations says that it saw on Orlando during a check of the logs. The line protocol down message is an indication that there is a problem with the interface at the data link layer that prevents it from functioning properly. (Note that when the line protocol goes down, Enhanced Interior Gateway Routing Protocol (EIGRP) neighbor adjacencies time out.)

Example 7-5 Console Message Showing a Symptom of a Data Link Layer Problem Orlando#

Aug 03 21:14:24: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down Aug 03 21:14:24: %DUAL-5-NBRCHANGE: IP-EIGRP 101: Neighbor 172.21.177.1

(Serial1/0) is down: interface down Orlando#

To start problem isolation, you connect into the console port on Orlando and use the show ip interface brief command to look for interface status. The output of this command shows that interface Serial 1/0 on Orlando is up, but the line protocol is down. (See the top portion of Example 7-6.)

Example 7-6 Gathering Information to Isolate a Data Link Layer Problem on a Cisco Router

Orlando#show ip

interface brief

Interface

IP-Address

OK?

Method

Status

Protocol

FastEthernet0/0

172.21.178.129

YES

NVRAM

up

up

Serial1/0

172.21.177.2

YES

NVRAM

up

Orlando#show running-config interface serial 1/0

Building configuration...

Current configuration : 162 bytes

interface Serial1/0 description Frame Relay link to Daytona ip address 172.21.177.2 255.255.255.252 encapsulation frame-relay frame-relay lmi-type ansi end

Orlando#

Orlando#

Orlando#show running-config interface serial 1/0

Building configuration...

Current configuration : 162 bytes

interface Serial1/0 description Frame Relay link to Daytona ip address 172.21.177.2 255.255.255.252 encapsulation frame-relay frame-relay lmi-type ansi end

Orlando#

You call Network Operations in Daytona and ask your contact to use the show ip interface brief command to display the interface status and any recent console messages. Your contact at Network Operations reads a recent console message stating that the hold time for the EIGRP neighbor has expired. However, your contact at Network Operations tells you that the output of the show ip interface brief command on Daytona shows interface Serial 1/0 of Daytona is up and the line protocol is also up.

So far, the problem appears to be on your device; therefore, you return to your console session on Orlando for further problem isolation. You display specific interface configuration information with the show running-config interface serial 1/0 command. (See the bottom portion of Example 7-6.) The configuration indicates that the interface has Frame Relay encapsulation and is expecting an American National Standards Institute (ANSI) Local Management Interface (LMI) type. This output matches your baseline configuration information. You decide to look for more information on the interface with the show interface serial 1/0 command and see the results shown in Example 7-7. You notice that Orlando is sending LMI inquiries but not receiving the same number of LMI status packets from the Frame Relay service provider. You also notice a large number of input errors and carrier transitions.

Example 7-7 Analyzing the Output of a show interface Command on a Cisco Router

Orlando#show interface serial 1 /0

Serial1/0 is up, line protocol is down Hardware is PowerQUICC Serial Description: Frame Relay link to Daytona Internet address is 172.21.177.2/30 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usee, reliability 254/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec)

LMI enq sent 232, LMI stat recvd 73, LMI upd recvd 0, DTE LMI down

(some output is deleted)

37 input errors, 0 CRC, 36 frame, 0 overrun, 0 ignored, 1 abort 268 packets output, 10960 bytes, 0 underruns 0 output errors, 0 collisions, 50 interface resets 0 output buffer failures, 0 output buffers swapped out 112 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Orlando#

Finally, you begin to question what your Frame Relay carrier has done. You decide to enter the debug frame-relay lmi command to gather some additional details. The results are shown in Example 7-8.

Example 7-8 Analyzing the Output of a debug frame-relay Command on a Cisco Router

Orlando#debug frame-relay lmi

Frame Relay LMI debugging is on Displaying all Frame Relay LMI data Orlando#

Aug 03 21

43:13.655

Serial1/0(out): StEnq, myseq 174, yourseen 19, DTE down

Aug 03 21 Aug 03 21 Aug 03 21 Aug 03 21

43:13.655 43:13.655 43:13.655 43:13.655

datagramstart = 0x3B5BC14, datagramsize = 14

FR encap = 0x00010308

00 75 95 01 01 00 03 02 AE 13

Aug 03 21

43:23.656

Serial1/0(out): StEnq, myseq 175, yourseen 19, DTE down

Aug 03 21 Aug 03 21 Aug 03 21 Aug 03 21

43:23.656 43:23.656 43:23.656 43:23.656

datagramstart = 0x3999F54, datagramsize = 14

FR encap = 0x00010308

00 75 95 01 01 00 03 02 AF 13

Aug 03 21

43:33.656

Serial1/0(out): StEnq, myseq 176, yourseen 19, DTE down

Aug 03 21 Aug 03 21

43:33.656 43:33.656

datagramstart = 0x3B5BE94, datagramsize = 14 FR encap = 0x00010308

continues

Example 7-8 Analyzing the Output of a debug frame-relay Command on a Cisco Router (Continued) Aug 03 21:43:33.656: 00 75 95 01 01 00 03 02 B0 13

Orlando#undebug all

All possible debugging has been turned off Orlando#

The result of the debug frame-relay lmi command helps you isolate the issue. If the Frame Relay service were working correctly, you would see an LMI reply from the switch for every LMI request the router sends to the switch. In addition, you should periodically see a full LMI status message from the switch that includes a description of the permanent virtual circuits (PVCs). This full LMI status message is sent in response to a status inquiry message that the router transmits after every six LMI keepalives. With the default keepalive of 10 seconds, you should see the full LMI status every minute. You should also see an incrementing counter in the yourseen field. In addition, the data terminal equipment (DTE) status should be up. Because everything used to work and no one changed anything on Orlando, you can pinpoint the issue to the Frame Relay carrier and the LMI encapsulation type. You have a defined LMI type in your interface configuration. If your service provider changed the LMI type that was offered to you, the line protocol would fail due to mismatched LMI types.

0 0

Post a comment