Tài liệu Troubleshooting Frame Relay 2 ppt

However, upon issuing show frame-relay pvc and show frame-relay map commands on the Singapore router, you see unexpected results.. Adtran Atlas 550 Note If using the Adtran Atlas 550 a

Trang 1

Lab 8.3.4.2: Troubleshooting Frame Relay 2

Frame Relay

Atlas 550 192.168.192.0/24

Fa0/0 192.168.200.1/24 Fa0/0 192.168.232.1/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 You have been asked to confirm connectivity and that

everything is working Everything seems to be working fine as you can ping

and telnet between the London and Singapore LANs However, upon issuing

show frame-relay pvc and show frame-relay map commands on the

Singapore router, you see unexpected results It is your responsibility to

determine if the routers are configured correctly and to make appropriate

configuration corrections if not

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-2-LondonBrokenConfig.txt into the London router Load the file called

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

Trang 2

Use ping and/or telnet to check connectivity between the London and

Singapore LANs All ping and telnet attempts from either site to the other should be successful If not, troubleshoot

Step 2

Issue the show frame-relay pvc command on the Singapore router Your output should appear similar to the sample output below (Remember to ignore information about other DLCIs [such as DLCI 16] not shown or referenced below.)

Singapore#show frame-relay pvc

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

Active Inactive Deleted Static

Local 1 0 1 0

Switched 0 0 0 0

Unused 0 0 0 0

<output omitted>

DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, 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

in DE pkts 0 out DE pkts 0

out bcast pkts 0 out bcast bytes 0

pvc create time 00:15:51, last time pvc status changed 00:14:53

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

1 What are the unexpected results you are seeing? (Hint: Reference the highlighted output items and look at the network diagram; there is one PVC only and that is to London.)

Note: When the status of the PVC is DELETED, it means the Frame Relay switch is not programmed to handle the associated DLCI—at least from this channel or circuit from this router The focus of the troubleshooting should be

on the local router

Trang 3

Issue the show frame-relay map command on the Singapore router Your output should appear similar to the sample output below (Remember to ignore information about other DLCIs [such as DLCI 16] not shown or referenced below.)

Singapore#show frame-relay map

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

broadcast,

CISCO, status defined, active

broadcast,

CISCO, status defined, inactive

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

broadcast,, status defined, active

2 Reference the network diagram and DLCI 18 information from the show

frame-relay pvc output and briefly explain why the show

frame-relay map output does not contain any unusual or unexpected results at

this point

The unexpected output from the show frame-relay pvc command does not appear to be affecting connectivity or causing other problems

3 At this point, there does not appear to be a problem; however, if you find the unexpected output from the show frame-relay pvc results from a misconfiguration, should you make a change even though everything is working fine?

Step 3

Look at the output of the show frame-relay map command and note the map to London (192.168.192.2) was dynamically established rather than

statically

broadcast,

Trang 4

On the Singapore router, shut down the Frame Relay interface, issue a debug frame-relay packet command, then re-enable the interface and note the

highlighted items in the sample output below

Singapore(config)#interface serial 0/0

Singapore(config-if)#shutdown

Singapore#debug frame-relay packet

Frame Relay packet debugging is on

Singapore(config)#interface serial 0/0

Singapore(config-if)#no shutdown

04:53:23: Serial0/0: broadcast search

04:54:14: Serial0/0(i): dlci 18(0x421), pkt type 0x2000, datagramsize 289

04:54:32: Serial0/0(i): dlci 18(0x421), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP),

datagramsize 30 04:54:32: Serial0/0: frame relay INARP received

04:54:32: FR: Sending INARP Reply on interface Serial0/0 dlci 18 for link 7(IP)

04:54:37: Serial0/0: broadcast search

04:54:37: Serial0/0: Broadcast on DLCI 16 link 7

04:54:37: DLCI 16 is either deleted or inactive

04:54:37: Serial0/0: Broadcast on DLCI 18 link 7

04:54:37: Serial0/0(o): dlci 18(0x421), pkt type 0x800(IP), datagramsize 64

04:54:37: broadcast dequeue

04:54:37: Serial0/0(o):Pkt sent on dlci 18(0x421), pkt type 0x800(IP), datagramsize 64

Turn debug frame-relay packet off

Singapore#no debug frame-relay packet or no debug all

4 Based upon the map being dynamically established and output from the

debug frame-relay packet command, can you determine whether a frame-relay map or frame-relay interface-dlci command

was used in the router configuration? (Hint: Inverse ARP.)

Since you have determined a frame-relay interface-dlci command was used, you should check the statement with a show running-config

command Your output should appear the same as the partial sample output below

Singapore#show running-config

!

interface Serial0/0

ip address 192.168.192.4 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

no ip mroute-cache

Trang 5

cdp enable

frame-relay interface-dlci 17

frame-relay lmi-type ansi

!

5 What facts can be gathered about the situation?

Step 4

6 Examine the facts you have just gathered Based on your observations, what are the possible causes of DLCI 17 being deleted and DLCI 18 being the active link with London?

You call the Frame Relay service provider and they tell you the correct DLCI for the PVC to London is 18 This confirms your findings about why DLCI 17 is deleted while DLCI 18 is active

What happened was the LMI process noticed the DLCI was miconfigured on the Singapore router (frame-relay interface-dlci 17 instead of

frame-relay interface-dlci 18) Early in the LMI process, the Frame Relay switch sends the router all of the DLCIs configured for that circuit and for which there should be a PVC to a destination network In the case of the

Singapore router, the Frame Relay switch sent router DLCI 18, the DLCI for the PVC to London When the Singapore router received this DLCI 18, it did an inverse ARP to map London’s remote IP address to this DLCI since there was

no static mapping for DLCI 18 in the Singapore configuration The Singapore router then deleted DLCI 17 and made DLCI 18 active as you saw in the output

of the show frame-relay pvc command And the output of the show

frame-relay map command showed DLCI 18 was mapped to London’s IP

address as a result of inverse ARP

If the Singapore router had an incorrect frame-relay map statement instead

of a frame-relay interface-dlci statement, the self-correcting

automatic inverse ARP process would not have taken place and the connection between Singapore and London would have been down (as was the case in

Trang 6

Lab 8-1) Remember that inverse ARP is automatically disabled for an interface that has a frame-relay map statement configured

Step 5

You have now confirmed everything is working fine and inverse ARP

automatically overcame a misconfiguration on the Singapore router And, as addressed earlier, even though there isn’t a problem, you decide to correct Singapore’s configuration to avoid unforeseen problems later and to help make troubleshooting less difficult

Your action plan is to replace the incorrect frame-relay interface-dlci statement with a corrected one

Step 6

Implement the action plan and observe the results

Remove the existing incorrect frame-relay interface-dlci 17

statement

Enter the correct frame-relay interface-dlci 18 statement

Shutdown then re-enable the interface

Issue a show frame-relay pvc command on the Singapore router Your output should appear similar to the sample output below (Remember to ignore information about other DLCIs/DLCI 16.)

Singapore#show frame-relay pvc

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

Active Inactive Deleted Static

Local 1 1 0 0

Switched 0 0 0 0

Unused 0 0 0 0

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

You should now have only one active PVC DLCI 18

Issue a show frame-relay map command on the Singapore router Your output should appear similar to the sample output below

Trang 7

broadcast,

CISCO, status defined, inactive

Although this output is the same as before, you determined there was an

incorrect DLCI number in the Singapore router configuration This time it is because of the frame-relay interface-dlci 18 statement and not inverse ARP If you enable debug frame-relay packet and observe the output, you will not see inverse ARP taking place

Use ping and/or telnet to check connectivity between the London and

Singapore LANs All ping and/or telnet attempts from either site to the other should still be successful

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 2
Trường học	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	7
Dung lượng	37,65 KB