Tài liệu Troubleshooting Frame Relay 3 pdf

Console into the London router and issue a show interface serial 0/0 command.. London#show frame-relay lmi LMI Statistics for interface Serial0/0 Frame Relay DTE LMI TYPE = CISCO Inval

Trang 1

Lab 8.3.4.3: Troubleshooting Frame Relay 3

Frame Relay

Atlas 550 192.168.192.0/24

Objective

Apply the troubleshooting method to a simple Frame Relay network problem

Scenario

A new Frame Relay connection was installed between London and Singapore over the weekend On Monday, both network operators at London and

Singapore call to let you know they are unable reach each other with this new Frame Relay connection You check connectivity between the London router and the Singapore router and find you cannot ping or telnet between the sites It is your responsibility to get London and Singapore communicating

Adtran Atlas 550 Note

If using the Adtran Atlas 550 as your Frame Relay switch, you will see

information about DLCIs (such as DLCI 16) that is not shown in sample outputs

of this lab These DLCIs are configured on the Atlas 550, but are not being used for this specific lab You would not normally see these extra DLCIs, so any information pertaining to them should be disregarded for this lab

Step 1

Cable the lab as shown in the diagram

Load the configuration file called Lab8-3-4-3-LondonBrokenConfig.txt into the London router Load the file called

Lab8-3-4-3-SingaporeBrokenConfig.txt into the Singapore router

Step 2

Trang 2

Use ping and telnet to check connectivity between London and Singapore All ping and telnet attempts from either site to the other should fail From each router, ping its directly connected LAN interface This ping should be successful

1 Define the problem you are experiencing

Step 3

Gather the facts about the situation The commands listed below are useful for gathering factual information about each router

• show interface

• show frame-relay lmi

• show frame-relay pvc

• show frame-relay map

• debug frame-relay lmi

Gather information about the London router first Console into the London router and issue a show interface serial 0/0 command The

highlighted information in the sample output below is useful for troubleshooting and should be the same as the information in your output

London#show interface serial 0/0

Serial0/0 is up, line protocol is down

Hardware is PowerQUICC Serial

Internet address is 192.168.192.2/24

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

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

Encapsulation FRAME-RELAY, loopback not set

Keepalive set (10 sec)

LMI enq sent 69, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0

Last input 00:15:53, output 00:00:05, output hang never

Last clearing of "show interface" counters 00:11:37

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

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/32 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

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

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

0 packets input, 0 bytes, 0 no buffer

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

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

69 packets output, 897 bytes, 0 underruns

0 output errors, 0 collisions, 22 interface resets

0 output buffer failures, 0 output buffers swapped out

Trang 3

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

2 Examine the output and list the pertinent facts about the interface

Issue a show frame-relay lmi command on the London router The

highlighted information in the sample output below is useful for troubleshooting and should be similar to the information in your output

London#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO

Invalid Unnumbered info 0 Invalid Prot Disc 0

Invalid dummy Call Ref 0 Invalid Msg Type 0

Invalid Status Message 0 Invalid Lock Shift 0

Invalid Information ID 0 Invalid Report IE Len 0

Invalid Report Request 0 Invalid Keep IE Len 0

Num Status Enq Sent 188 Num Status msgs Rcvd 0

Num Update Status Rcvd 0 Num Status Timeouts 187

Checking the status of the LMI is always a good place to start with Frame Relay

3 Examine the output Do you notice anything unusual?

Issue a show frame-relay pvc command on the London router The

highlighted information in the sample output below is useful for troubleshooting and should be the same as the information in your output (Remember to ignore information about other DLCIs.)

London#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

Active Inactive Deleted Static

Local 0 1 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0

input pkts 0 output pkts 0 in bytes 0

out bytes 0 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

Trang 4

in DE pkts 0 out DE pkts 0

out bcast pkts 0 out bcast bytes 0

pvc create time 00:47:06, last time pvc status changed 00:47:06

4 Notice the PVC for DLCI 17 is INACTIVE Would this be unexpected?

Issue a show frame-relay map command on the London router

There should not be any output Since no LMI messages are being received and the PVC is inactive, no mapping is taking place Before any mapping

between the local DLCI and the remote IP address can happen, LMIs must be exchanged between the routers and the Frame Relay switches, and the PVC must be active

Listed below is a summary of pertinent factual information gathered about the London router

• The WAN interface serial 0/0 interface and line protocol are up; the

encapsulation is Frame-Relay; the LMI is up; and the LMI type is ANSI

• LMIs are being sent and received so the router and Frame Relay switch are exchanging LMIs

• The PVC for DLCI 17 is active, indicating the PVC between the router and switch is configured correctly

• The Frame Relay map is configured correctly

Issue a debug frame-relay lmi command on the London router Since LMIs were not being received, debugging the LMI process gives you a closer look and will verify LMIs are not being received Note: Your sequence numbers may differ

London#debug frame-relay lmi

Frame Relay LMI debugging is on

Displaying all Frame Relay LMI data

London#

00:18:57: Serial0/0(out): StEnq, myseq 96, yourseen 0, DTE down

00:18:57: datagramstart = 0x1A01ED4, datagramsize = 13

00:18:57: FR encap = 0xFCF10309

00:18:57: 00 75 01 01 00 03 02 60 00

00:18:57:

00:19:07: FR encap = 0xFCF10309

00:19:07: 00 75 01 01 00 03 02 61 00

00:19:07:

00:19:17: FR encap = 0xFCF10309

00:19:17: 00 75 01 01 00 03 02 62 00

00:19:17:

Trang 5

The "Serial0/0(out):" and "myseq" greater than "0" indicate LMIs are being sent, but "yourseen 0" indicates LMIs are not being received Note too that there are

no "Serial0/0(in):" messages which also indicate there are no LMI messages being received "DTE down" also means there is a problem communicating LMIs between the local router and the Frame Relay switch

Turn the debugging off

Examine the Singapore router to see if you can learn any new information Issue a show interface serial 0/0 command Your output should be similar to the sample output below

Singapore#show interface serial 0/0

Serial0/0 is up, line protocol is up

LMI enq sent 227, LMI stat recvd 227, LMI upd recvd 0, DTE LMI up

LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

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

Last clearing of "show interface" counters 00:38:03

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

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/32 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

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

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

228 packets input, 3572 bytes, 0 no buffer

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

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

228 packets output, 3192 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

5 Compare this output with the output from the London router What are the differences?

So far the Singapore router seems to be successfully sending and receiving LMIs with its Frame Relay switch Issue a show frame-relay lmi

command to verify this Your output should appear similar to the sample output shown below

Trang 6

Singapore#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI

Examine the output Notice LMI inquiries have been sent and messages

received and there are no timeouts There are no indications of a problem Check the status of the PVC to London Issue a show frame-relay pvc

command Your output should appear similar to the sample output shown below (Remember to ignore information about other DLCIs.)

Singapore#show frame-relay pvc

Local 0 2 0 0

Switched 0 0 0 0

Unused 0 0 0 0

<output omitted>

DLCI = 18, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0

Note that DLCI 18 PVC status is INACTIVE, which should be expected since London is not exchanging LMIs with its Frame Relay switch As was addressed previously, when the PVC status is inactive status, it is a good idea to look at the local router; however, in this case, the status is inactive on both routers and LMIs are not being exchanged on the London router while it is being

exchanged on the Singapore router

Issue a show frame-relay map command

There should not be any output (except for maybe DLCI 16, which should be ignored)

Even though LMI messages are being sent and received, the PVC is inactive

so no mapping is taking place Before any mapping between the local DLCI and the remote IP address can happen, LMIs must be exchanged between the routers and the Frame Relay switches, and the PVC must be active

Trang 7

Issue a show running-config command to check the mapping statement and other interface information Your output should appear similar to the

sample output below

interface Serial0/0

ip address 192.168.192.4 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

no ip mroute-cache

cdp enable

frame-relay interface-dlci 18

frame-relay lmi-type ansi

As was discovered earlier, the encapsulation is frame-relay and the frame-relay type is ANSI and a frame-relay interface-dlci statement was used

If the Singapore router was configured with a frame-relay map statement instead of the frame-relay interface-dlci statement, this would have caused a static mapping to London's remote IP address and the mapping would have been displayed However, the PVC status would be inactive

Step 4

Examine the facts about both routers you have just gathered

• The London router Serial 0/0 line is up, but the protocol is down

• The Singapore router Serial 0/0 line is up and the protocol is up

• Both routers’ Serial 0/0 encapsulations are Frame-Relay

• DLCI 17 PVC status on the London router is inactive

• DLCI 18 PVC status on the Singapore router is inactive

• LMI status inquires have been sent, but no messages received on the

London router

• LMI status inquires have been sent and messages received on the

Singapore router

• DTE LMI is down on the London router

• DTE LMI is up on the Singapore router

• Frame-relay interface-dlci commands were used on both routers and are correct

• LMI type is CISCO on the London router

• LMI type is ANSI on the Singapore router

Based upon the information gathered, it would appear the Singapore router configuration is fine while the London router may require attention—the line protocol is down; LMI status inquiries and messages have not been sent and received; and the DTE LMI is down

Even though the LMI type is ANSI on the Singapore router and CISCO on the London router, this is not necessarily a problem as the LMI type is only between

Trang 8

the local router and its Frame Relay switch The LMI at opposite ends of the same PVC can be different However, all indications point to an LMI problem on the London router as LMIs must be sent and received between the router and Frame Relay switch before the PVC status becomes active LMIs are being successfully exchanged between the Singapore router and its Frame Relay switch, but the PVC status is inactive

6 Based on your observations, what is the possible cause of the problems on the London router?

Step 5

Create an action plan to solve this problem You could check with the Frame Relay provider to confirm the LMI type on the switch; you could try a different LMI type; or you could use the frame-relay qos-autosense command to let the router receive LMI type information from the Frame Relay switch

The Frame Relay provider has not gotten back to you yet so you either must try

an LMI type of ANSI or Q933a, or use the auto sensing command You decide

to try an LMI type of ANSI first

Step 6

Implement the action plan

Change the LMI type on the Serial 0/0 interface of the London router to ANSI

London(config-if)#frame-relay lmi-type ansi

It is a good idea to shutdown, and no shutdown the interface after changing

the LMI type

Observe the results of your implementation You may need to wait a minute or two for the connection to come up

First, ping and/or telnet from either the London or Singapore site to the other Both should now be successful

Verify the results of your change on both the London and Singapore routers using the same commands you used to gather information to make sure that

Trang 9

the change not only corrected the problem, but that it didn’t cause any new problems

• show interface

• show frame-relay lmi

• show frame-relay pvc

• show frame-relay map

The outputs below are only from the commands that were showing problematic output These commands will now show that the change has worked

Issue a show interface serial 0/0 command on the London router Your output should appear similar to the sample output shown below Note that the line protocol and DTE LMI are now up and LMI inquiries and messages are being sent and received

London#show interface serial 0/0

Serial0/0 is up, line protocol is up

LMI enq sent 868, LMI stat recvd 314, LMI upd recvd 0, DTE LMI up

LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

Issue a show frame-relay lmi command on the London router Your output should appear similar to the sample output below Note the LMI type is ANSI and LMI inquiries and messages are being sent and received

London#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = ANSI

Issue a show frame-relay pvc command on the Singapore and London routers Your output should appear similar to the sample outputs below

(Remember to ignore information about other DLCIs.) Both PVCs should now

be active

Singapore#show frame-relay pvc

Local 1 0 0 0

Switched 0 0 0 0

Trang 10

Unused 0 1 0 0

DLCI = 18, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

London#show frame-relay pvc

Local 1 0 0 0

Switched 0 0 0 0

Unused 0 1 0 0

DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

Issue a show frame-relay map command on the Singapore and London routers Your output should appear similar to the sample outputs below

(Remember to ignore information about other DLCIs.) Note a map is now

present on both routers established dynamically—indicating a frame-relay interface-dlci command was used to map the PVC

Singapore#show frame-relay map

Serial0/0 (up): ip 192.168.192.2 dlci 18(0x12,0x420), dynamic,

broadcast,, status defined, active

London#show frame-relay map

Serial0/0 (up): ip 192.168.192.4 dlci 17(0x11,0x410), dynamic,

broadcast,, status defined, active

7 Did your solution fix the problem? If not, undo your changes and repeat the process

Step 7

8 Document the results

Tiêu đề	Troubleshooting Frame Relay 3
Tác giả	Cisco Systems, Inc.
Chuyên ngành	Internetwork Troubleshooting
Thể loại	Lab
Năm xuất bản	2001

Định dạng
Số trang	10
Dung lượng	45,73 KB