1-7 Semester 8 Internetwork Troubleshooting v1.0 - Lab 8.3.4.2 Copyright  2001, Cisco Systems, Inc.
Lab 8.3.4.2: Troubleshooting Frame Relay 2

Frame Relay
Atlas 550
192.168.192.0/24
1/2
2/1
S0/0 S0/0
DLCI 17 DLCI 18
.2
.4
Fa0/0 192.168.200.1/24 Fa0/0 192.168.232.1/24
London Singapore
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


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

input pkts 28 output pkts 34 in bytes 5560
out bytes 6623 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 34 out bcast bytes 6623
pvc create time 00:15:54, last time pvc status changed 00:15:54


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.

Singapore#show frame-relay map
Serial0/0 (up): ip 0.0.0.0 dlci 18(0x12,0x420)
broadcast,
CISCO, status defined, active

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: 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
<output omitted>

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
<output omitted>
!
interface Serial0/0
ip address 192.168.192.4 255.255.255.0

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