994 Words. Plan about 6 minute(s) to read this.
I think I can do this entire chapter in one blog post. There is a good bit of material here, but the chapter is short, only 12 pages, about 3 of which are covered with IOS code which I don’t go into too much detail on here in the blog. (Yes, gentle reader, lest you think you’re getting the Official Exam Certification Guide for free by reading my blog, you aren’t. Sadly, not even close. I do try to hit all key elements of the chapter, but I skim over many IOS command details and option, as well as sample output that the author dives into with fantastic detail. Oh, and the diagrams. You’re missing those…lots of network diagrams, all of which I have found helpful at the very least, and more often than not, vital in readily grasping the concepts. And also, you’ve probably noticed that I’ve been doing little in the way of editing grammar and, to a lesser degree, spelling. So buy the book. All the cool CCIE candidates are doing it.)
Frame relay is still in wide use. Really. I’ve got at least a couple of thousand routers hanging off of frame clouds. If you’ve yet to see a frame network, your time is coming. MPLS, VPLS and IP VPNs are making great strides as WAN technologies, but frame is still here, ubiquitous in my experience. Some of my first Cisco jobs way-back-when were building out frame networks, and every enterprise I’ve worked for since has had frame-relay, and possibly ATM or FRASI.
Frame-Relay Data Link Connection Identifiers (DLCIs)
- Frame DTEs (the endpoints, the routers) use virtual circuits (VCs) to establish a connection across the shared medium we think of as a frame cloud.
- The VC is identified on either end with a DLCI number.
- DLCIs are only meaningful between the router and the upstream switch. The DLCI number doesn’t have to be (and generally is not) the same on either end of the VC.
- Some providers use global addressing, meaning that each router has unique DLCI assignments per VC, but the significance is still local-only.
Local Management Interface (LMI)
- LMI is used to manage the link between a frame router and the frame switch upstream from him. (Typically, the frame switch is owned by the telco, and not you.)
- A frame DTE (the router) sends an LMI “status enquiry” to the switch. The switch should respond with an LMI “Status” message. The “status” message contains:
- DLCIs of the specific VC.
- The status of each VC.
- LMI messages, by default, are sent every 10 seconds.
- Every 6th message (or once a minute by default), contains a full Status with more information about each VC.
- LMIs function as keep alive messages, in addition to the information they carry; the router will assume the interface is gone if he misses 3 (by default) LMIs in a row.
- LMI is enabled or disabled by using the keepalive or no keepalive commands on an interface.
- There are 3 types of LMI:
- Cisco – proprietary, lmi-type=cisco, 16-1007 allowed range, LMI DLCI=1023
- ANSI – T1.617 Annex D, lmi-type=ansi, 16-991 allowed range, LMI DLCI=0
- ITU – Q.933 Annex A, lmi-type=q933a, 16-991 allowed range, LMI DLCI=0
- The “fram-relay lmi-type type” command is used to set the LMI type. (As if you couldn’t have guessed.)
Frame Relay Headers and Encapsulation
- A router makes a frame-relay frame using a number of headers in order.
- ITU Link Access Procedure fo Frame-Mode Bearer Services (LAPF) header – includes the DLCI, DE, BECN and FECN fields.
- Frame Relay encapsulation header – includes information useful to the DTEs (routers) on either end of the VC.
- Could be a Cisco proprietary header. This is good if you have Cisco routes on either end of the VC.
- Could be an IETF RFC 2427 (once RFC 1490) header. This is good for interoperability with non-Cisco devices.
- In IOS, a router will use the Cisco encapsulation header, unless you force it via configuration to use IETF.
- “encapsulation frame-relay ietf” will change the interface default to IETF.
- “frame-relay interface-dlci <number> ietf” will change the interface for a specific VC to IETF.
- “frame-relay map dlci…ietf” also accomplishes this for a specific VC.
Frame Relay Congestion: DE, BECN and FECN
- Because you can have 100 T1s mapped into a single T3 (for instance), it’s possible for traffic coming from the edge of the cloud to overwhelm the head-end. And vice-versa – the T3 could swamp a T1 at the far end because it’s so much bigger. Frame gives us tools to manage these congestion scenarios (known often as egress blocking).
- The FECN and BECN bits in the LAPF header are used to tell a router that congestion is occuring on a particular VC.
- Forward explicit congestion notification (FECN) bits are set only by frame-relay switches. A frame-switch that sees congestion in a forward direction will set the FECN bit, and then forward the frame to the next hop.
- Backward explicit congestion notification (BECN) bits are set to let the sender know that there was congestion on the VC, implicitly that he needs to back off.
- Alternatively, if the frame switch doesn’t want to wait for a frame to head back to the sender, he can inject a Q.922 test frame with the BECN bit set. This is aka “FECN reflection”. Hey, I saw a FECN – I’m going to reflect that fact back to the sender with a Q.922 test frame with the BECN bits set.
- The Discard Eligibility (DE) bit is used to mark a frame as more likely to get dropped when queues get full. The idea is to let a router know that this particular frame is, given the choice, a frame you’d prefer gets dropped as opposed to other traffic without the DE bit set. Both routers and switches can set the DE bit.
Okay, I lied. It’s going to be 2 posts. This post is plenty long enough…the next one will cover frame relay configuration.