Frame Relay Frames
Because Frame Relay is primarily a Layer 2 technology, I want to spend a bit more time with the encapsulation, frame format, and signaling for purposes of supporting it.
Encapsulation
I wouldn't expect encapsulation to be a new topic for you. In this chapter you just change your WAN encapsulation or frame type from HDLC to Frame Relay to communicate using a connection-oriented Data Link Layer technology. With Frame Relay you communicate from DTE (router) to DTE (router) through a provider. Each data-link segment connects to the nearest Frame Relay switch (DCE). Typically the DLCI has local significance. This local significance is just like my cell phone speed dial. I have programmed number 1 to be Mom, and number 2 to be Ed, but you may have number 1 as your significant other and number 2 as your Mom or Dad. Think of the phone number as the IP address and the speed dial as the DLCI.
You can also relate DLCIs to going to the bank. Next time you are sitting at the drive-up window close to closing time, watch the tubes and dream about Frame Relay in a hub-and-spoke topology. You place your payroll check in the tube just as someone else in the next lane (using another DLCI) is doing. The tubes all go to one of the tellers (hub) working that day. When the bank teller processes your transaction, she knows who you are by the tube (PVC) you came in on and therefore gives you your cash and gives the other person hers.
Any way you look at it, some Layer 3 payload gets stuffed into a Layer 2 frame to be transported to the local provider to get it to the proper destination. Statistically you can multiplex many virtual circuits over one physical circuit but part of this efficiency is due to the error and flow control being left up to higher-layer protocols. At Layer 2 the default encapsulation type for Frame Relay is Cisco. The encapsulation possibilities are as follows:
Cisco is the default for Cisco devices.
IETF is for compatibility with non-Cisco devices.
NOTE
Cisco encapsulation is appropriate when both devices are Cisco routers, and Internet Engineering Task Force (IETF) encapsulation is appropriate when at least one of the devices is not.
Now look at the Frame Relay header to see where all the pieces fit.
The Frame Relay Header
Examine the Frame Relay format in Figure 8-7. The frame starts and ends with a 1-byte flag. The Layer 2 DLCIs are contained within the 2-byte address header, and the data is variable. Frame Relay does use a frame check sequence (FCS). Even though the protocol can recognize when there has been an error, there is no retransmission capability at Layer 2 to correct bad data.
Figure 8-7. Frame Relay Header
Think of the 10-bit DLCI like the MAC address on a LAN. Both are Layer 2 addresses, and routing requires mappings of IP next hops to Layer 2 addresses. The DLCI identifies the local connection. The Command/Response (C/R) bit is application-specific and not modified by the network, and the Extension (EA) bits allow for a 3- or 4-byte header. Current implementations use a 2-byte DLCI, but the EA bits allow room for growth in the future. The next 3 bits are used for congestion control. Figure 8-8 shows a graphical view of explicit congestion notification (ECN).
Figure 8-8. Frame Relay ECN
FECN is forward explicit congestion notification in that it tells the receiving end that the congestion occurred in the path from the source to the destination. BECN is backward explicit congestion notification in that it is set in frames traveling in the opposite direction of the congested path. FECN notifies the destination, whereas BECN notifies the source. The DE bit is a priority-based DE bit in case the network becomes short of resources. The frame switch sets the DE bit to 1 when the frame is above your CIR (or committed burst). CPE could do the same, but it makes no sense for the CPE (router) to set DE. Why should you volunteer for packet discard compared to all the other customers?
NOTE
Keep in mind that if there is a lower-layer problem, the data gets discarded (prior to any unmarked frame) and the upper layers request the retransmission. The reason for the discard may be due to errors or congestion. This is part of the efficiency of Frame Relay as a Layer 2 technology.
If you have access to a WAN sniffer, hook it up and watch what is happening. Sniffing on the WAN is quite a bit more expensive than sniffing the LAN. Our focus for analyzing the Frame Relay header has and will continue to be with show and debug commands built in to the IOS. If you expect to see any output at all for Frame Relay, however, it relies on the connection between your router and the frame switch. This signaling or keepalive is more often referred to as LMI. When encapsulation is configured properly, the LMI keepalive activity starts between the local router and frame switch.
Signaling (LMI)
The show frame-relay lmi command is one you must have on the tip of your tongue when troubleshooting Frame Relay. Chevrolet may be the heartbeat of America, but LMI is the heartbeat of Frame Relay. LMI is the signaling between your router and the local frame switch. The LMI type must match on the same data link (from the router to the local frame switch), although multiple LMI types can be used from the source to the destination network. The signaling consists of a status request from the local router to the frame switch and a status message from the frame switch to the local router. Example 8-15 displays the output of show frame-relay lmi.
Example 8-15. show frame-relay lmi
r1>show frame-relay lmi LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO 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 4403 Num Status msgs Rcvd 4403 Num Update Status Rcvd 0 Num Status Timeouts 0 r1> |
The first shaded line displays the statistics for the s1 interface that is configured as Frame Relay DTE with an LMI type of Cisco, which is the default configuration for a Frame Relay interface. The next to the last shaded line indicates the status inquiries and is equal to the messages received, which means LMI is working properly. Keep an eye on the last line for an increasing number of timeouts within the keepalive interval, which tends to lead to faulty equipment or circuit issues.
The debug frame-relay lmi shows the router requesting DLCIs from the frame switch and the local frame switch responding with new PVCs, deleted PVCs, and the integrity of the existing PVCs. Status inquiries always go from the router to the frame switch, which in turn replies with up-to-date PVC and DLCI information. Refer back to Figure 8-6 for a moment. If all is well, the local frame switch for r1 should return DLCI 100 and 400 both as active in that particular example. This process is dynamic like ARP is in the LAN, so you are not sending to something that does not exist. However, things are not always normal when the router receives LMI information. See Table 8-2 for possible PVC states.
| PVC State | Description |
|---|---|
| Active | The provider's network believes that the PVC is configured and operational from edge to edge within the cloud. The remote router is configured to match. |
| Inactive | Local connection may be fine but the other end is not working. Perhaps it has not been configured yet, either on the router or within the provider cloud. |
| Deleted | The DLCI that the router is reporting to the frame switch has no validating entry in the frame route table. The DLCIs may have been reversed or the PVC may have been deleted. |
Use the following commands to check the LMI status:
show frame-relay lmi
show frame-relay pvc
show interfaces
Issue a show interfaces s0 to check the LMI type. Cisco supports the following LMI types:
Cisco LMI type uses DLCI 1023 as its data path.
ANSI T1.617 Annex D LMI uses DLCI 0 as its data path.
ITU-T Q.933 Annex A uses DLCI 0 as its data path.
Note that LMI typically runs over reserved DLCI 0 or 1023. Normally the DLCIs assigned from the service provider are in the range of 16 to 1007. You can easily remember that if you were 16 years old when you got your driver's license and if you are a James Bond fan.
What if you need to configure the LMI to be something other than the Cisco default? The service provider makes this decision in the real world, but in the private world you can certainly do what you want. Refer back to Figure 8-3 if you need to review your lab setup again. Configure r1 for ANSI LMI, and watch the keepalives until the line protocol goes down as in Example 8-16.
Example 8-16. Configuring and Testing ANSI LMI
r1#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data r1#configure terminal r1(config)#interface s1 r1(config-if)#frame-relay lmi-type ansi r1(config-if)#end Dec 10 09:09:29.553: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up Dec 10 09:09:29.557: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:09:29.557: FR encap = 0x00010308 Dec 10 09:09:29.557: 00 75 95 01 01 01 03 02 01 00 Dec 10 09:09:29.565: Dec 10 09:09:29.785: %SYS-5-CONFIG_I: Configured from console by console Dec 10 09:09:39.553: Serial1(out): StEnq, myseq 2, yourseen 0, DTE up Dec 10 09:09:39.557: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:09:39.557: FR encap = 0x00010308 Dec 10 09:09:39.561: 00 75 95 01 01 00 03 02 02 00 Dec 10 09:09:39.565: r1# Dec 10 09:09:49.553: Serial1(out): StEnq, myseq 3, yourseen 0, DTE up Dec 10 09:09:49.557: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:09:49.557: FR encap = 0x00010308 Dec 10 09:09:49.557: 00 75 95 01 01 00 03 02 03 00 Dec 10 09:09:49.565: Dec 10 09:09:59.553: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to INACTIVE Dec 10 09:09:59.585: Serial1(out): StEnq, myseq 1, yourseen 0, DTE down Dec 10 09:09:59.589: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:09:59.589: FR encap = 0x00010308 Dec 10 09:09:59.593: 00 75 95 01 01 00 03 02 01 00 Dec 10 09:09:59.597: Dec 10 09:10:00.553: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed |
state to downNow set s1 on the frame switch to be ANSI LMI, and continue to watch the keepalive activity on r1 as in Example 8-17.
Example 8-17. Configuring the Frame Switch for ANSI LMI
frame-switch(config)#interface s1 frame-switch(config-if)#frame-relay lmi-type ansi frame-switch(config-if)#end frame-switch#copy running-config startup-config !!!status inquiry from r1 to the frame switch Dec 10 09:30:49.553: Serial1(out): StEnq, myseq 126, yourseen 1, DTE down Dec 10 09:30:49.557: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:30:49.557: FR encap = 0x00010308 Dec 10 09:30:49.561: 00 75 95 01 01 01 03 02 7E 01 !!!keepalive reply from the frameswitch to r1 (full status update) Dec 10 09:30:49.597: Serial1(in): Status, myseq 126 Dec 10 09:30:49.597: RT IE 1, length 1, type 0 Dec 10 09:30:49.601: KA IE 3, length 2, yourseq 2 , myseq 126 Dec 10 09:30:49.601: PVC IE 0x7 , length 0x3 , dlci 104, status 0x2 !!!status inquiry from r1 to the frame switch Dec 10 09:30:59.581: Serial1(out): StEnq, myseq 127, yourseen 2, DTE up Dec 10 09:30:59.581: datagramstart = 0xE3F544, datagramsize = 14 Dec 10 09:30:59.585: FR encap = 0x00010308 Dec 10 09:30:59.585: 00 75 95 01 01 01 03 02 7F 02 !!!keepalive reply from the frameswitch to r1 Dec 10 09:30:59.601: Serial1(in): Status, myseq 127 Dec 10 09:30:59.605: RT IE 1, length 1, type 1 Dec 10 09:30:59.605: KA IE 3, length 2, yourseq 3 , myseq 127 Dec 10 09:31:00.553: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed |
The output of debug frame-relay lmi is quite helpful to show the LMI status request sent out by the router as indicated by (out) on the interface. Likewise, the (in) on the interface indicates the LMI received from the switch. Also, type 0 is a full LMI status message that includes such data as the DLCI, the status, the CIR, and any traffic-shaping type of information. The status corresponds to the active, inactive, and deleted states of DLCIs. For example, 0x0 is inactive, 0x2 is active, and 0x4 is deleted. Watch out for 0x4 (the deleted status). The DLCIs may be reversed or the PVC may have actually been deleted.
Now that the DLCI is active, view the LMI statistics, clear the interface counters so that old statistics are not in your way later, and ping the other end of the PVC as in Example 8-18.
Example 8-18. Viewing the LMI Statistics
r1#show frame-relay lmi LMI Statistics for interface Serial1 (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 9675 Num Status msgs Rcvd 9549 Num Update Status Rcvd 0 Num Status Timeouts 127 r1# r1#clear counters s1 Clear "show interface" counters on this interface [confirm] r1#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms |
Examples 8-16 and 8-17 illustrate what it is like to have a local LMI mismatch, but how the remote end of the PVC can use a different LMI from the local end. You proved that the frame switch can handle multiple LMI types just in case it is connected to something other than a Cisco device. However, the same data link or connection between the local router and the frame switch must use the same LMI. Use the show frame-relay lmi command to find LMI mismatches. When you are sending and not receiving, for instance, it is kind of like you talking English and the other person talking French when neither of you happen to be bilingual. Watch for the increase in status timeouts as highlighted in the preceding example.