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 Down1604-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 IssuesConfiguration 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 Correct1602-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 Focus1602-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.1interface 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 Problem1604-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:
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 Issue1602-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.
LMI IssuesThe 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 FormatThe 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 FormatThe 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) FormatReport 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 AnnexDThe 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 MessageThe 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 FormatThe 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
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 Message7206-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.
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.
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 On1602-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.
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). |