Resolving Problems at the Physical or Data Link Layer

Chapter 7, "Isolating a Problem at the Physical or Data Link Layer," lists several common symptoms of problems occurring at the physical or data link layer. Table 13-1 provides a summary of those symptoms for your review.

Table 13-1 Common Symptoms of Physical and Data Link Layer Problems

Common Symptoms of Problems Occurring at the Physical Layer

Common Symptoms of Problems Occurring at the Data Link Layer

No component above the physical layer works on the failing interface.

No component above the data link layer works on the failing interface.

Even though the network is functional, it is operating at a level below the baseline.

There is no connectivity on the link from the network layer's perspective.

Loss of connectivity occurs at the data link layer.

Encapsulation errors are present.

Framing, line coding, or synchronization errors are reported.

Address resolution errors occur.

Port LEDs are off, red, or at an alarming state.

CRC errors are excessive.

Interface errors are excessive.

Collisions are excessive.

Utilization occurs at a much higher level than the baseline.

Broadcasts are excessive.

Console, system log, management alarm, or trap messages appear.

Console, system log, management alarm, or trap messages appear.

In Chapter 7, you were also given the following general guidelines for isolating problems at the physical and data link layers:

■ Check the operational status and the error rates on the network device interface(s)— Cisco IOS show commands, such as the show interfaces command, provide information on the physical and data link status of your device interfaces. The show interfaces command also provides statistics on drops, collisions, broadcasts, resets, restarts, overruns, and ignores.

■ Verify the correctness of interface configurations—On routers, misconfiguration of parameters such as media type, duplex, and encapsulation type are common errors. In contrast, on LAN switch ports, incorrect speed, duplex, native VLAN, trunk, spanning tree, and channel settings are common errors.

■ Check for broken or loose cables or connections—Cable conditions such as opens, kinks, crimps, sharp bends, and broken connectors or adapters, as well as loose screws, are common physical problems. You can discover some physical problems by visual inspection, whereas others require you to use tools, such as cable testers. Link LEDs are good indicators of link status. When in doubt, replace a suspicious cable with a known/good one for testing.

■ Check for correct cable pin-out—Some Ethernet connections require a straight cable, and others require a crossover cable. Serial connections sometimes require a straight cable and other times require a rollover serial cable.

In the following scenario, a support engineer has been mandated to investigate and, if possible, correct the status, configuration, and error rates on two links. The first link is an Ethernet connection between a router named Router-O (ethernetO) and a router called Router-T (ethernetl). The second link is between Router-O's FastEthernetl interface and the FastEthernetO/1 port of a switch named Switch-D. Figure 13-3 shows these connections.

Figure 13-3 Ethernet Connection Between Router-O and Router-T, and the FastEthernet Connection Between Router-O and Switch-D

Figure 13-3 Ethernet Connection Between Router-O and Router-T, and the FastEthernet Connection Between Router-O and Switch-D

The support engineer decides to connect to the console of Router-O, ping Router-T's IP address on its Ethernet 1 interface, and see the results. He gets the results displayed in Example 13-1.

Example 13-1 Ping Results with Low Success

Router-O#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: !.!..

Success rate is 40 percent (2/5), round-trip min/avg/max = 1/3/5 ms

The 40 percent success rate of ping with a directly connected device is a sign of a problem on the interface or link. To investigate further, the engineer decides to clear counters (by using the Cisco IOS clear counters command) to reset all the data and error counters, redo the ping test, and inspect the Ethernet 0 interface on Router-O. He gets the results shown in Example 13-2.

Example 13-2 Results of show Command for EthernetO Interface of Orlando Router

Router-O#show interfaces ethernet 0

Ethernet0 is up, line protocol is up

Hardware is Lance, address is 0000.0c12.3456 (bia 0000.0c12.

3456)

Internet address is 192.168.1.2/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:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output

drops: 0

Queueing strategy: fifo

Output queue 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

2220 packets input, 3146442 bytes, 0 no buffer

Received 6 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

2801 packets output, 3222650 bytes, 0 underruns

16 output errors, 0 collisions, 10 interface resets

0 babbles, 0 late collision, 0 deferred

16 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Based on the guidelines for isolating problems at the physical and data link layers, the engineer becomes curious about the reason for the errors, resets, and lost carriers.

Based on his training and past experience, and again, based on the guidelines, the engineer decides to inspect the cable and physical connection to Router-O's Ethernet 0 interface. There, he notices that the cable is not properly seated in the connector. He disconnects the cable, properly reconnects/reseats it, and clears the counters on Router-O. Once again, he tests the connection by issuing a ping from

Router-O to Router-T's adjacent IP address (192.168.1.1) and reinspecting the error rates in the interface. The ping results are shown in Example 13-3. The output of show interfaces Ethernet 0 shows no more input errors, interface resets, or lost carriers.

Example 13-3 Ping Results with Perfect Success

Router-O#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to

192.168.1.1

timeout is 2 seconds:

Success rate is 100 percent (5/5)

round-trip

min/avg/max = 1/1/2 ms

Next, the network engineer goes after the problem on the FastEthernet connection between Router-O and Switch-D. Users have complained about the performance of their applications that travel across that link. The engineer decides to look at the status and error rates on the FastEthernet1 interface of the Router-O router, again using the show interfaces command. Example 13-4 shows the results.

Example 13-4 Results of show Command for FastEthernetl Interface of Router-O Router

Router-O#show interfaces fastethernet 1

FastEthernetl is up, line protocol is up

Hardware is Fast Ethernet, address is 0000.0c66.7788 (bia 00(

90.0c66.7788)

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usee,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Half-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output

drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

26 packets input, 3233 bytes, 0 no buffer

Received 25 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 25 multicast, 0 pause input

0 input packets with dribble condition detected

135237 packets output, 15687924 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 255 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

The network engineer notices that the FastEthernetl interface of Router-O router is up, and there are no drops or output errors. That is good news. Despite the good news, a surprising number (255) of late collisions is reported on the FastEthernetl interface. Based on his past experience and the guidelines for isolating problems at the physical and data link layers, the engineer suspects that either the total length of the cable connecting Router-O's FastEthernetl interface is longer than the recommended maximum, or Router-O's FastEthernetl interface's half duplex setting does not match the setting on FastEthernet0/1 port of Switch-D at the other end. Therefore, the engineer decides to check the FastEthernet0/1 interface of Switch-D. The results are shown in Example 13-5.

Example 13-5 Results of show Command for FastEthernet0/1 Interface of Switch-D

Switch-D#show interfaces fastethernet 0/1

FastEthernet0/1 is up, line protocol is up

Hardware is Fast Ethernet, address is 0000.0c02.2222 (bia 00(

90.0c02.2222)

MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usee,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output

drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

15835 packets input, 2215305 bytes, 0 no buffer

Received 1358 broadcasts, 0 runts, 0 giants, 0 throttles

10 input errors, 10 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

174455 packets output, 38446758 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

After inspecting the results of the show interfaces FastEthernet 0/1 command, the network engineer quickly notices that the interface is set up for full duplex. Therefore, it seems that the mismatch of Duplex setting on the two ends of the fast Ethernet connection between Router-O's FastEthernetl and Switch-D's FastEthernet0/1 is the root of the problem on this link. The engineer changes the duplex setting on Router O's FastEthernetl, clears the counters, and observes the statistics on that interface. The results are positive. Example 13-6 displays the work done and the output of the show interfaces command after the corrections are made and the counters are cleared.

Example 13-6 Change of Duplex Setting of FastEthernet 1 on Router-O and the Results

Router-O(config)#interface fastethernet 1

Router-O(config-if)#duplex full

Router-O(config-if)#~Z

Router-O#

August 03 01:06:06: %SYS-5-CONFIG_I: Configured from console by

console

Router-O#clear counters

Clear "show interface" counters on all interfaces [confirm]

Router-O#

Router-O#show interfaces fastethernet 1

FastEthernetl is up, line protocol is up

Hardware is Fast Ethernet, address is 0000.0c66.7788 (bia 000

0.0c66.7788)

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usee,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output

drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

26 packets input, 3233 bytes, 0 no buffer

Received 25 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 25 multicast, 0 pause input

0 input packets with dribble condition detected

138001 packets output, 16799924 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

The engineer's next responsibility is to document his efforts and the work done.

0 0

Post a comment