Data Link Layer Troubleshooting


Troubleshooting the second layer in Frame Relay includes the encapsulation types, LMI types and messages, and should be performed just after the physical layer issues are resolved. As previously mentioned #show ip interface brief and #show interfaces serial 1(0) are the commands that help narrow the scope of troubleshooting. Some typical reports for protocol layer issues are shown in Example 17-16 and Example 17-17.

Example 17-16. The Serial 1 Interfaces Show Line Up and the Protocol Down
 1604-frame#show ip interface brief Interface        IP-Address           OK? Method Status                Protocol Ethernet0        121.70.194.209       YES NVRAM  up                    up Loopback0        unassigned           YES NVRAM  up                    up Serial0          unassigned           YES NVRAM  administratively down down ! The following narrows the scope of possible problems to ! the data link layer issues. Serial1          unassigned           YES NVRAM  up                    down Serial1.37       unassigned           YES unset  down                  down 

Example 17-17. Data Link Layer Issues Can Be Seen if You Use the show interfaces Command
 7206-frame#show interfaces s3/0:0 Serial0 is up, line protocol is down   Hardware is QUICC Serial (with onboard CSU/DSU) <output omitted> 

PVC Configuration Issues

Configuration issues for a PVC include problems with configuration, encapsulation, and bandwidth definitions. In the case of a 56-kbps configuration shown in Example 17-18, the configuration line is shaded and defines the type of PVC encapsulation.

Example 17-18. First Step Is to Make Sure the Configuration Is Correct
 1602-frame#show running-config <output omitted> ! interface Serial0  no ip address ! The frame relay encapsulation and its type (IETF) are your primary focus here  encapsulation frame-relay IETF  no fair-queue  service-module 56k clock source line  service-module 56k network-type dds ! The LMI type is the second point of attention  frame-relay lmi-type ansi ! <output omitted> 

In the case of fractional T1 (FT1) or T1 configurations, the configuration settings are a little different. The configuration lines are shown in Example 17-19.

Example 17-19. In Case of Fractional T1, the Encapsulation and the LMI Type Need to Be Your Primary Focus
 1602-frame#show running-config <output omitted> ! interface Serial1 <output omitted> ! The frame relay encapsulation and its type are your primary focus here  encapsulation frame-relay  no ip mroute-cache  no fair-queue ! The access rate configuration is your secondary focus.  service-module t1 timeslots 1-2 ! The LMI type is the next point of attention  frame-relay lmi-type ansi ! <output omitted> 

The encapsulation options are shown in Example 17-20.

Example 17-20. The Encapsulation Options for Cisco 1602 Frame Relay Routers
 1602-frame(config-if)#encapsulation ?   atm-dxi         ATM-DXI encapsulation   frame-relay     Frame Relay networks   hdlc            Serial HDLC synchronous   lapb            LAPB (X.25 Level 2)   ppp             Point-to-Point protocol   smds            Switched Megabit Data Service (SMDS)   x25             X.25 

Frame Relay encapsulation options are cisco and ietf (RFC 1490 and RFC 2427). In point-to-point configurations, you need to configure a subinterface, as shown in Example 17-21.

Example 17-21. Fragment of Configuration of Point-To-Point Interface Serial0.1
 interface Serial0.1 point-to-point  bandwidth 56  ip unnumbered Ethernet0  frame-relay interface-dlci 16 

Encapsulation options are shown in Example 17-22, and if the encapsulation type is omitted, it defaults to cisco.

Example 17-22. Frame Relay DLCI Encapsulation Options
 3640-frame(config-fr-dlci)# interface-dlci 16 ?   cisco          Use CISCO Encapsulation   ietf           Use RFC1490/RFC2427 Encapsulation   ppp            Use RFC1973 Encapsulation to support PPP over FR   protocol       Optional protocol information for remote end, 

The DLCI types are as follows: cisco (Consortium, by default), ietf (uses RFC 1490/RFC 2427 encapsulation), ppp (uses RFC 1973 encapsulation to support PPP over Frame Relay), and protocol.

NOTE

An interesting discussion about different ppp options can be found in RFC 1490, "Multiprotocol Interconnect over Frame Relay," by Bradley (July 1995). The ppp option is available in Cisco IOS version 12.0(1).T and later versions. The interesting part about ppp encapsulation is related to the auto recognition of ppp frames and proposed options for LCP, authentication, and compression techniques.


The first potential problem to check is the access rate definition. The service module definition configures the line as a 2 x 64-kbps access rate service. If there is any mismatch between both sides of the UNI interface, the report of the line shows the output in Example 17-23.

Example 17-23. This Output Shows That if the Protocol Layer is Down, the Access Rate Configuration Can Be a Potential Problem
 1604-frame#show ip interface brief Interface         IP-Address    OK? Method Status                Protocol <output omitted> Serial1           unassigned    YES NVRAM  up                    down Serial1.37        unassigned    YES unset  down                  down 

The second important factor is to make sure that the interface is configured with proper encapsulation, and that it matches the encapsulation in the near-end and far-end:

 1602-frame(config-if)#encapsulation frame-relay [cisco | ietf] 

The available options in Cisco routers are as follows:

  • cisco Uses Cisco's own encapsulation.

  • ietf The encapsulation complies with the Internet Engineering Task Force (IETF) standard (RFC 1490). If the chosen encapsulation is IETF, this is an indication that the configuration is designated for a multivendor environment.

NOTE

If the encapsulation is not defined under the serial interface, an attempt to create a subinterface will not work because the default Cisco encapsulation in the serial interface is Cisco Proprietary high-level data link control (HDLC), which does not support subinterfaces.


The correct PVC configuration depends on several factors. The core of the PVC is the DLCI, so you must ensure that the configuration uses the proper DLCI, as it is assigned by the LEC. The DLCI has a local significance, and can be different at each end. At the same time, the DLCI is bound to a certain port on the switch and it cannot be used without the proper settings. When the switch receives a frame, it performs a series of predefined operations. First, it recalculates the FCS and if the value does not match the FCS of the frame, it drops the packet. At the same time, the switch checks the DLCI and the length of the frame. If the DLCI is not correct or the frame is too long, too short, or falls beyond the byte boundary, it discards the frame. After the first check is passed, the switch checks its routing/switching table for proper routing. This routing table consists of port-to-DLCI values, with each pair associated with input or output flows. After the entry is found, the switch changes the incoming DLCI in the frame with the DLCI from the output portion of the table. Using this approach, the incoming DLCI x becomes the outgoing DLCI y and matches the far-end of the connection. Before sending the frame, the switch recalculates the new frame check sequence (FCS), replaces this portion in the outgoing frame, and sends the frame out. If the remote user's equipment is configured with an incorrect DLCI, the indication from the down protocol shows a problem with the DLCI.

NOTE

The line protocol shows down in point-to-point configurations. If the DLCI is miscon-figured, the line protocol does not show down if the configuration is point-to-multipoint.


Cisco routers ease the DLCI troubleshooting process. An example of the output from an incorrect DLCI configuration is shown in Example 17-24. In this example, the LEC's switch is configured for DLCI 16, but the router is configured with DLCI 17. There's more than one indication that the configuration is not correct, as shown in the example.

Example 17-24. The Focus Points, Indicating That There Is an Active DLCI, But There Is Also a Configuration Issue
 1602-frame#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) ! For Serial 0, there is one deleted and one active DLCI ! This should be your first point of attention.                   Active     Inactive      Deleted      Static   Local           0            0           1            0   Switched        0            0           0            0   Unused          1            0           0            0 ! Note that DLCI=16 is active, but unused. ! This should be your second point of attention. DLCI = 16, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0   input pkts 3           output pkts 0          in bytes 918   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      Num Pkts Switched 0   pvc create time 00:02:45, last time pvc status changed 00:02:45 ! Why is the DLCI reported deleted? ! This should be your third point of attention. DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.17   input pkts 0           output pkts 1          in bytes 0   out bytes 312          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 1       out bcast bytes 312   pvc create time 00:03:44, last time pvc status changed 00:02:50 1602-frame# 

NOTE

When checking the DLCI, the other end of the connection is not relevant because DLCI only has a local significance.


NOTE

Remember that if the PVC is reported as inactive or deleted, and even if LMI is configured correctly, LMI still does not send packets over the DLCI.


The first group of data (the overall status of the PVCs) provided by the last LMI shows that the serial line has one local and deleted PVC and one active but unused DLCI. (Later in the discussion, you see that LMI must provide the status of all PVCs configured on the interface on every full status message.) The second indication of the DLCI status is its description (see PVC STATUS line). As shown, the configured DLCI = 17 under subinterface Serial0.17 is not correct and the correct one is DLCI = 16.

The overall status of the PVC can be analyzed by using the #show frame-relay pvc command as displayed in Example 17-24. Table 17-3 contains a description of the output from this command.

Table 17-3. Output and Description From the #show frame-relay pvc Command

Output

Description

This Section Shows the Standard Output

DLCI

DLCI numbers for the PVC.

DLCI USAGE

Lists SWITCHED when the router or access server is used as a switch, or LOCAL when used as a DTE.

PVC STATUS

Status of the PVC: ACTIVE, INACTIVE, or DELETED.

INTERFACE

Specific subinterface associated with this DLCI.

Input pkts

Number of packets received on this PVC.

Output pkts

Number of packets sent on this PVC.

in bytes

Number of bytes received on this PVC.

out bytes

Number of bytes sent on this PVC.

dropped pkts

Number of incoming and outgoing packets dropped by the router at the Frame Relay level.

in FECN pkts

Number of packets received with the FECN bit set.

in BECN pkts

Number of packets received with the BECN bit set.

out FECN pkts

Number of packets sent with the FECN bit set.

out BECN pkts

Number of packets sent with the BECN bit set.

in DE pkts

Number of DE packets received.

out DE pkts

Number of DE packets sent.

out bcast pkts

Number of output broadcast packets.

out bcast bytes

Number of output broadcast bytes.

pvc create time

Time the PVC was created.

last time pvc status changed

Time the PVC changed status (active to inactive).

This Section Appears if Voice Is Configured for This PVC

Service-type

Type of service performed by this PVC. Can be Voice over Frame Relay or Voice over Frame Relay-cisco.

configured voice bandwidth

Amount of bandwidth in bits per second reserved for voice traffic on this PVC.

used voice bandwidth

Amount of bandwidth in bits per second currently being used for voice traffic.

Voice reserved queues

Queue numbers reserved for voice traffic on this PVC. This field was removed in Cisco IOS Release 12.0(5)T.

Fragment type

Type of fragmentation configured for this PVC. The possible types are as follows:

Voice over Frame Relay-cisco Fragmented packets contain the Cisco proprietary header.

Voice over Frame Relay Fragmented packets contain the FRF.11 Annex C header.

End-to-end Fragmented packets contain the standard FRF.12 header.

Fragment size

Size of the fragment payload in bytes.

This Section Appears if the Traffic Shaping Map Class Is Applied to this PVC (Refer to End-to-End Issues Later in This Chapter)

Cir

Current CIR, in bits per second.

Bc

Current committed burst size, in bits.

Be

Current excess burst size, in bits.

Limit

Maximum number of bytes transmitted per internal interval (excess plus sustained).

Interval

Interval being used internally (can be smaller than the interval derived from Bc/CIR; this occurs when the router determines that traffic flow is more stable with a smaller configured interval).

Mincir

Minimum CIR for the PVC.

Byte increment

Number of bytes that can be sustained per internal interval.

BECN response

Frame Relay has backward explicit congestion notification (BECN) adaptation configured.

Pkts

Number of packets associated with this PVC that went through the traffic shaping system.

Bytes

Number of bytes associated with this PVC that went through the traffic shaping system.

Pkts delayed

Number of packets associated with this PVC that were delayed by the traffic shaping system.

Bytes delayed

Number of bytes associated with this PVC that were delayed by the traffic shaping system.

Shaping

Shaping is active for all PVCs that are fragmenting data; otherwise, shaping is active if the traffic sent exceeds the CIR for this circuit.

Shaping drops

Number of packets dropped by the traffic shaping process.

Voice queuing stats

Statistics showing the size of packets, the maximum number of packets, and the number of packets dropped in the special voice queue created by using the frame-relay voice bandwidth command queue keyword.

Discard threshold

Maximum number of packets that can be stored in each packet queue. If additional packets are received after a queue is full, they are discarded.

Dynamic queue count

Number of packet queues reserved for best-effort traffic.

Reserved queue count

Number of packet queues reserved for voice traffic.

Output queue size

Size in bytes of each output queue.

max total

Maximum number of packets of all types that can be queued in all queues.

Drops

Number of frames dropped by all output queues.


LMI Issues

The PVC status reports the static or snapshot information, and the LMI provides the dynamics for the troubleshooting process. Some explanations are necessary to understand the outputs on the screen. For troubleshooting purposes, it is important to understand the difference between formats and the underlying concept of LMIs. Local Management Interfaces (LMIs) provide information about the DLCI values and the status of virtual circuits. Three different standards for LMI messages exist: cisco LMI (default), which users DLCI 1023 for connection management, ANSI LMI, which uses DLCI 0 for connection management, and Q933a (ITU).

The Consortium LMI defines two messages: status enqiry and status. The general format of LMI type cisco (Consortium) is shown in Figure 17-2.

Figure 17-2. LMI Message Format (Consortium)


Both messages are sent in HDLC Unnumbered Information (UI) frames, with a Control field value of 03h. The message header, based on Q.931, is three octets and includes protocol discriminator 09h, call reference value 00h (Dummy Call reference), and message type indicator for the message type: status enquiry 75h (0111 0101) or status 7Dh (0111 1101).

The Consortium LMI Status Enquiry Message Format

The Consortium LMI operates by periodically polling the network, and by using status enquiry messages. The Consortium document defines the polling period as the variable nT1, which ranges from 5 to 30 seconds, where 10 seconds is the default. The message contains two IEs: Report Type and Keepalive Sequence (see Figure 17-3).

Figure 17-3. LMI Status Enquiry Message Format (Consortium)


When used with the status enquiry message, the report type defines the content of the network's Status message. The report type IE is identified by 01H in the first byte. The second byte specifies the length of the contents, and the third one identifies the report type. A report type of 00H indicates a full status message, and 01h indicates a sequence number exchange, which verifies the integrity of the link.

NOTE

The Consortium format of the report type is the same as for AnnexD. The difference is AnnexD defines an additional report type, which is the Single PVC Asynchronous Status Report, 02h.


The Keepalive Sequence IE is identified by a 03h in the first octet. The second octet specifies the length of the contents in bytes (02 stands for the second octet), and the last two bytes are Current and Last received sequence numbers. Each time the router or network sends a status enquiry message, it increments its internal sequence number and places the value in the Current received sequence number (byte three). The last sequence number received from the other end of the link is paced in the Last received sequence number (byte four).

NOTE

Less frequently, the Frame Relay access device (router) requests a full status message, which adds one PVC status IE for each PVC configured on the interface. This polling period is defined by the variable nN1, which ranges from 1 to 255 intervals of nT1, with a default of six intervals.


The Consortium LMI Status Message Format

The network sends the status message to the CPE in response to the status enquiry message. Figure 17-4 shows the status message format.

Figure 17-4. LMI Status Message (Consortium) Format


Report type and keepalive sequence IEs are always transmitted with the status message. PVC IEs are added, one per configured PVC, to the status message when the full status message is requested. The PVC status IE is identified by 07h in the first octet and it is either 5 or 8 bytes long. The second octet specifies the length of the contents (3 or 6 bytes). The third and fourth octets carry the DLCI for this PVC, and the fifth octet contains status-bit coding that identifies whether the PVC is new (N = 1) or Active (A = 1). The Consortium defined octets 6 through 8 to optionally carry a 24-bit number, which represents the minimum bandwidth in bits per second that the network has allocated for this PVC.

LMI Type ANSIT1.617 AnnexD

The Consortium status enquiry messages contain the report type and keepalive sequences, and the AnnexD status enquiry messages contain report type and link integrity verification IEs, as shown in Figure 17-5. The link integrity verification IE has the value of 03h in the Control UI Frame field.

Figure 17-5. AnnexD Status Enquiry Message


The link integrity verification IE has an identification ID in the first byte, the length of the integrity verification content in the second byte, send sequence number in the third byte, and receive sequence number in the fourth byte.

The AnnexD status message uses a similar format as Consortium, as shown in Figure 17-6.

Figure 17-6. AnnexD Status Message Format


The LMI type configuration is crucial for Frame Relay service. If the DTE configuration does not match the switch configuration, the LMI autosense mode is used, which is supported by Cisco. If the configuration of LMI is not configured explicitly, the router sends out a full status enquiry in all three LMI types to the switch. The order is ANSI, ITU, and Cisco. Cisco can listen on DLCI 0 and DLCI 1023 simultaneously. One of the enquiries receives a status message, but if the autosense is unsuccessful, another status enquiry message is sent every N391 interval (the default is 60 seconds: 6 attempts every 10 seconds) to try to define the LMI type. After a status message is received, Cisco IOS decodes the message and configures the router with the correct LMI type.

When the LMI type is configured, you can use either of the following two options to see the details of the LMI exchange:

 1602-frame#show frame-relay lmi 1602-frame#debug frame-relay lmi 

The first command reports the statistics for the time period, after clearing the interface counters, as shown in Example 17-25 and explained in Table 17-4.

Example 17-25. Output from the show frame-relay lmi Command
 7206-frame#show frame-relay lmi LMI Statistics for interface Serial3/0:0 (Frame Relay DTE) LMI TYPE = ANSI   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 5570             Num Status msgs Rcvd 5570   Num Update Status Rcvd 0              Num Status Timeouts 0 

Table 17-4. Output and Description of the #show frame-relay lmi Command

Output

Description

LMI Statistics

Signaling or LMI specification: CISCO, ANSI, or ITU-T.

Invalid Unnumbered info 0

Number of received LMI messages with invalid unnumbered information field.

Invalid Prot Disc 0

Number of received LMI messages with invalid protocol discriminator.

Invalid Dummy Call Ref 0

Number of received LMI messages with invalid dummy call references.

Invalid Msg Type 0

Number of received LMI messages with invalid message type.

Invalid Status Message 0

Number of received LMI messages with invalid status message.

Invalid Lock Shift 0

Number of received LMI messages with invalid lock shift type.

Refer to the LMI ANSI message type.

Invalid Information ID 0

Number of received LMI messages with invalid information identifier.

Invalid Report IE Len 0

Number of received LMI messages with invalid Report IE Length.

Invalid Report Request 0

Number of received LMI messages with invalid Report Request.

Invalid Keep IE Len 0

Number of received LMI messages with invalid Keep IE Length.

Num Status Enq. Sent 5570

Number of LMI status inquiry messages sent.

Number of status enquiries successfully sent after the last clear counters command.

Num Status Msgs Rcvd 5570

Number of LMI status messages received.

Number of status enquiries successfully received after the last clear counters command.

Num Update Status Rcvd 0

Number of LMI asynchronous update status messages received.

Num Status Timeouts 0

Number of times the status message was not received within the keepalive time value.

Number of resets trying to trigger the exchange.


For troubleshooting purposes, you need to identify non-zero values and, based on the provided figures, analyze the connection. An important consideration is the keepalive (Invalid Keep IE Len) messages and timeouts for status enquiry messages (Num Status Enq. Timeouts), which reflect the number of resets when the interface tries to trigger the exchange within the T392 time interval. All parameters depend on Frame Relay timers and counters, which are listed in Table 17-6.

NOTE

If there are no LMI-related errors, expect Num Status Enq. Sent = 5570 and Num Status msgs Rcvd = 5570 to be the same. In erroneous conditions, Num Status Enq. Sent = Num Status msgs Rcvd + Num Status Timeouts Expect performance issues when this occurs.


The second troubleshooting tool is debug frame-relay lmi. The output of this command is not chatty, so it can be used without concern for use of the main CPU in the router. The output from a serial line of 1544 kbps, with Cisco encapsulation for Frame Relays, LMI DLCI 0 with a LMI type of ANSI AnnexD, and the router is DTE, as shown in Example 17-26.

Example 17-26. Full Status Request Message
 7206-frame#debug frame-relay lmi Aug 26 11:03:25 PDT: Serial4/2:0(out): StEnq, myseq 183, yourseen 182, DTE up (OUT) Report for serial interface 4/2:0. STATUS ENGUIRY message; myseq=183,     yourseen=182 out; DTE  up. Aug 26 11:03:25 PDT: datagramstart = 0x7000214, datagramsize = 14 (OUT) Start of the next datagram; size of the datagram Aug 26 11:03:25 PDT: FR encap = 0x00010308 (OUT) Frame Relay encapsulation  0x00010308  cisco; ( 0xFCF10309  IETF) Aug 26 11:03:25 PDT: 00 75 95 01 01 00 03 02 B7 B6 Aug 26 11:03:25 PDT: Aug 26 11:03:25 PDT: Serial4/2:0(in): Status, myseq 183 (IN) STATUS message from the switch;myseq 183 Aug 26 11:03:25 PDT: RT IE 1, length 1, type 0 (IN) Report Type (RT) Information Element 1, length 1, type 0 Aug 26 11:03:25 PDT: KA IE 3, length 2, yourseq 183, myseq 183 (IN) Keep Alive (integrity verification message); length, yourseq, myseq. Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 35, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 37, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 38, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 40, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 45, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 46, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 55, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 56, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 59, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 64, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 67, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 68, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 72, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 75, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 84, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 90, status 0x2 Aug 26 11:03:25 PDT: PVC IE 0x7 , length 0x3 , dlci 92, status 0x2 ! All PVCs are listed because full status message was used. 

You must know what to expect from various outputs; the expected LMI code values are shown in Table 17-5.

Table 17-5. LMI Code Values

Message Type

Binary Value[*]

Status

01111101

Status enquiry

01110101

Update status

01111011

Information Element ID

Keep Alive Sequence

00000011

Report Type

00000001

PVC status/Modified PVC status

00000111

Multicast status

00000101

Information Definitions

Report Type

Full status message

00000000

Sequence number exchange

00000001

Reserved

RAll other values

PVC Status Bit Coding

New status

00001RXR

PVC already present

00000RXR[**]

PVC active

00000R1R

PVC inactive

00000R0R

Modified PVC Status Bit Codings

PVC Present

000000XX

PVC deleted

000001XX

DLCI added

000010XX

PVC active

0000XX1X

PVC inactive

0000XX0X

PVC's buffers above threshold

0000XXX1

PVC's buffers below threshold

0000XXX0

Multicast Status Bit Codings

Multicast Channel Present

000000XX

Multicast Channel Deleted

000001XX

DLCI added

000010XX

Multicast active

0000XX1X

Multicast inactive

0000XX0X


[*] Rreserved; Xdoes not matter.

[**] Note the PVC status reporting; the PVC present is 0000RXR and is either active or inactive.

For more information, see Frame Relay Networking by Gilbert Held (John Wiley and Sons, Inc., 1999).

NOTE

Some common status indications based on the output include status 0xa, which represents a PVC and indicates that the DLCI is passing traffic to the far end; status 0x2, which indicates that the PVC is added and passing traffic; status 0x0, which indicates that the PVC is added but inactive; status 0x4, which identifies that the PVC as deleted; and status 0x8, which indicates that the new PVC is not active.


The appearance of the full status message in the LMI debug is a configurable parameter that is controlled by the value of n391 timers. Because many of the parameters in this exchange are configurable, the optional values and configuration commands are shown in Table 17-6.

The importance of the LMI timer and counter parameters is obvious. One additional aspect to be considered is the situation when you see keepalive mismatches, where both sides of the connection use different keepalive intervals. This solution requires attention to prevent the line from flapping.

Table 17-6. LMI Timers and Counters

Timers

Description

Range

Default

Config Command

N391dte

The full status-polling interval, which transmits a status enquiry after expiration. It records an error if STATUS is not received.

1255

6

frame-relay lmi-n391dte keep-exchange

N392dce

Set DCE and NNI interface error threshold (declared down), which after expiration, records the error, increments, and restarts.

110

2

frame-relay lmi-n392dce threshold

N392dte

Set DTE and UNI interface error threshold (declared down), which after expiration, records the error, increments, and restarts.

110

3

frame-relay lmi-n392dte threshold

N393dce

Set DCE and NNI monitored event count.

110

2

frame-relay lmi-n393dce events

N393dte

Set DTE and UNI monitored event count (>than N392dte).

110

4

frame-relay lmi-n393dte events

T392dce

Set the polling verification timer in the NNI interface.

530

15

frame-relay lmi-t392dce seconds

K

The maximum number of outstanding or unacknowledged IEs.

1127

7

frame-relay lapf t203 k

N200

The maximum number for retransmission of a frame.

 

3

frame-relay lapf n200 reties

N201

The maximum length of the I-frame in LAPF.

116,384

260 bytes

frame-relay lapf n201 bytes

T200

The maximum retransmission timer value.

1100

15

frame-relay lapf t200 sec/10

T203

The idle timer value (has to be T203>T200).

165,535

30

frame-relay lapf t203 seconds


NOTE

For troubleshooting purposes, you might sometimes consider verifying the PVC information. One tool to use here is the full status message, which regularly appears every 60 seconds. You can change this interval by using the Cisco IOS command frame-relay lmi-n391dte 1. This command requests a Local Management Interface (LMI) full status update every 10 seconds instead every 60 seconds (the default). Remember to turn off the command at the end of the troubleshooting process because this command adds more processing to the router and should be used only if it cannot be avoided.


Some of the timer and counter settings are shown in the output in Example 17-27. Even if SVC is disabled, and as a result the LAPF control protocol is down, some of the timer and counter settings show in the output, as in Example 17-27.

Example 17-27. Verifying the Status of the LAPF Protocol
 1602-frame#show frame-relay lapf Interface = Serial1 (up),  LAPF state = TEI_ASSIGNED (down) SVC disabled,  link down cause = SVC disabled,  #link-reset = 0 T200 = 1.5 sec.,  T203 = 30 sec.,  N200 = 3,  k = 7,  N201 = 260 I-frame xmt = 0,  I-frame rcv = 0,  I-frame reXmt = 0 I xmt dropped = 0,  I rcv dropped = 0,  Rcv pak dropped = 0 RR xmt = 0,  RR rcv = 0,  RNR xmt = 0,  RNR rcv = 0 REJ xmt = 0,  REJ rcv = 0,  FRMR xmt = 0,  FRMR rcv = 0 DM xmt = 0,  DM rcv = 0,  DISC xmt = 0,  DISC rcv = 0 SABME xmt = 0,  SABME rcv = 0,  UA xmt = 0,  UA rcv = 0 V(S) = 0,  V(A) = 0,  V(R) = 0,  N(S) = 0,  N(R) = 0 Xmt FRMR at Frame Reject 

The parameters in Table 17-6 are related to one of the common techniques used by engineers to check the serial line when the LMI exchange is not available and as a result the Frame Relay protocol is reported down. The technique includes setting the encapsulation to HDLC (temporarily) on both ends of the link and then to run the command #debug interface serial from the DTE to determine if the keepalive message exchange is successful.

NOTE

The reason for temporarily changing the encapsulation is that LMI carries keepalive messages, and as soon as LMI is not functional, there is no keepalive exchange. To change the encapsulation from Frame Relay to HDLC, just negate the Frame Relay encapsulation. Cisco proprietary HDLC is the default encapsulation in serial lines. The other option is to define HDLC explicitly by entering 1602-frame(config-if)#encapsulation hdlc.


Example 17-28 shows the output of the debug interface serial command with LMI on.

Example 17-28. Output of the debug interface serial Command with LMI On
 1602-frame#debug interface serial 6w6d: Serial1(out): StEnq, myseq 137, yourseen 136, DTE up (OUT) STATUS ENQUIRY, keepalive send by DTE (myseq 137), keepalive sent by the other side (yourseen 136), DTE is up. 6w6d: Serial1(in): Status, myseq 137 (IN) STATUS, DTE keepalive seen by the other side. 6w6d: Serial1(out): StEnq, myseq 138, yourseen 137, DTE up 6w6d: Serial1(in): Status, myseq 138 6w6d: Serial1(out): StEnq, myseq 139, yourseen 138, DTE up 6w6d: Serial1(in): Status, myseq 139 6w6d: Serial1(out): StEnq, myseq 140, yourseen 139, DTE up 6w6d: Serial1(in): Status, myseq 140 6w6d: Serial1(out): StEnq, myseq 141, yourseen 140, DTE up 6w6d: Serial1(in): Status, myseq 141 6w6d: Serial1(out): StEnq, myseq 142, yourseen 141, DTE up 6w6d: Serial1(in): Status, myseq 142 6w6d: Serial1(out): StEnq, myseq 143, yourseen 142, DTE up 6w6d: Serial1(in): Status, myseq 143 1602-frame# 

Example 17-29 shows the output of the debug interface serial command with LMI off and HDLC on.

Example 17-29. Output of the debug interface serial Command with LMI Off and HDLC On
 1602-frame#debug interface serial *Sep 16 01:26:57 PDT: Serial2/0/1:0: HDLC myseq 20158, mineseen 20158*,     yourseen  20316, line up *Sep 16 01:27:07 PDT: Serial2/0/1:0: HDLC myseq 20159, mineseen 20159*,     yourseen  20317, line up *Sep 16 01:27:17 PDT: Serial2/0/1:0: HDLC myseq 20160, mineseen 20160*,     yourseen  20318, line up *Sep 16 01:27:27 PDT: Serial2/0/1:0: HDLC myseq 20161, mineseen 20161*,     yourseen  20319, line up *Sep 16 01:27:37 PDT: Serial2/0/1:0: HDLC myseq 20162, mineseen 20162*,     yourseen  20320, line up *Sep 16 01:27:47 PDT: Serial2/0/1:0: HDLC myseq 20163, mineseen 20163*,     yourseen  20321, line up *Sep 16 01:27:57 PDT: Serial2/0/1:0: HDLC myseq 20164, mineseen 20164*,     yourseen  20322, line up *Sep 16 01:28:17 PDT: Serial2/0/1:0: HDLC myseq 20166, mineseen 20166*,     yourseen  20324, line up *Sep 16 01:28:20 PDT: Illegal HDLC serial type code 34915, PC=0x601B7E8C 

NOTE

It is common at the end of this output to see the message illegal serial line type xxx. The message indicates that the encapsulation is Frame Relay or HDLC, and the router attempts to send a packet with an unknown packet type.


If the (OUT) myseq message matches the other side's (IN) myseq message, the line is up. For N392dte keepalive exchanges, which count N393dte events, if the values do not match, the interface is reported down, the N392dte increments, and the interface restarts. In other words, if in four consecutive exchanges the values do not match, the interface is reported down.

The keepalive sequence IE (Consortium) is identified by a 03h in the first octet. The second octet specifies the length of the contents in bytes (01 stands for 1 octet), and the last two bytes are current and last received sequence numbers. Each time the router or network sends a status enquiry message, it increments its internal sequence number and places the value in the current sequence number (byte three) (see Figure 17-7 and Figure 17-8). The last sequence number received from the other end of the link is placed in the last received sequence number (byte four). Both types of messages are four bytes in length and differ slightly in format, but work the same way.

Figure 17-7. Keepalive Sequence IE (Consortium)


Figure 17-8. Link Integrity Verification IE (ANSI)


Several commands trim the keepalive messages, as shown in Table 17-7. These commands require a good understanding of the implication that they can have on the Frame Relay functionality and should be used with caution.

Table 17-7. IOS Keepalive Configuration Commands

IOS Command

Description

Max/Default

frame-relay end-to-end keepalive error-threshold [send | receive] count

Modifies the error threshold value.

32/2

frame-relay end-to-end keepalive event window [send | receive] size

Modifies the keepalive event window.

32/3

frame-relay end-to-end keepalive mode [bi-directional | request | reply | passive-replay]

When the keepalive mode is enabled, default values depend on which mode is selected.

 

frame-relay end-to-end keepalive success-events [send | receive] count

Modifies the keepalive success events.

32/2

frame-relay end-to-end keepalive timer [send | receive] interval

Modifies the keepalive timer value.

/10,15


These configuration commands can be part of the Frame Relay map-class definitions to trim the parameters of the service. Every single command has an output, which can be displayed if you enter the following:

 3640#show frame-relay end-to-end keepalive interface serial 1 

The full description of Cisco IOS Frame Relay configuration commands and their output can be found in Cisco IOS 12.0 Wide Area Networking Solutions (Cisco Press, 1999).




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net