The counters for each VC, including increments in the FECN and BECN counters, can be
particularly useful. Likewise, comparing the packets/bytes sent versus what is received on the
other end of the VC is also quite useful because it reflects the number of packets/bytes lost
inside the Frame Relay cloud. Also, seeing a PVC as active means that it is usable (as opposed
to inactive), which is a great place to start when troubleshooting. All this information can be
better gathered by an SNMP manager.
mapping. A DLCI is listed in each entry, but no mention of corresponding Layer 3 addresses
is made. However, because the subinterfaces are point-to-point, this omission by IOS is
intended--the subinterface acts like a point-to-point link, with two participants. Mapping is
needed only when more than two devices are attached to the link. (See the section "How
Address Mapping Works," earlier in this chapter, for more information.)
in DE pkts 0 out DE pkts 0
out bcast pkts 875 out bcast bytes 142417
pvc create time 05:19:51, last time pvc status changed 04:55:41
--More--
DLCI = 54, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.3
out bytes 142069 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 877 out bcast bytes 142069
pvc create time 05:19:52, last time pvc status changed 05:17:42
Atlanta#show frame-relay map
Serial0.3 (up): point-to-point dlci, dlci 54(0x36,0xC60), broadcast
status defined, active
Serial0.2 (up): point-to-point dlci, dlci 53(0x35,0xC50), broadcast
status defined, active
Serial0.1 (up): point-to-point dlci, dlci 52(0x34,0xC40), broadcast
status defined, active
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data
datagramstart = 0x45AED8, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 A3 A1
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 162, myseq 163