What's New in Frame Relay

icon What's New in Frame Relay 


There are some nifty new Frame Relay features in Cisco IOS 11.2. We'll take a look at them in this month's article. They include: LMI autosense, Frame Relay SVC support, and Frame Relay Traffic Shaping. We'll also talk briefly about Frame Relay compression.

SNA fans: I suggest you look at the documentation. There's now a whole chapter on the fras command variants (BNN and BAN), for those who wish to talk LLC2 to their FEP. There's also DLSw-Lite support for DLSw over Frame Relay. But that's enough for another whole article I'm not going to write!

LMI Autosense

When necessary a Cisco router will automatically determine the LMI type of the connected switch. This takes place when the physical interface is up, line protocol down, Frame Relay encapsulation is specified for the interface, but there is no configured LMI type. (In fact, it appears to do this when the configured LMI fails to match the switch, per some experimentation, but that's not what's documented).

The router sends out a full status request in all 3 LMI types, ANSI, ITU, then Cisco in rapid succession. The router then listens on DLCI's 0 and 1023. Any reply and the router will configure itself accordingly. Multiple replies and the router uses the last reply received.

The only way you can really see this in action is using debug frame-relay lmi.

This is pretty nifty stuff! It means that when doing NBMA model (the Frame Relay network is all one big subnet), you can now get away with a very small amount of configuration:

interface serial 0
encapsulation frame-relay ietf
Not that I'm recommending NBMA model (see previous Frame Relay articles).

Note that this also opens the door to Frame Relay AutoInstall with switches doing ANSI or ITU LMI.

Frame Relay SVC's

An SVC is a Switched Virtual Circuit. Think "placing a phone call".

You won't be able to try this at home unless you're lucky enough to have service provider who's providing you with SVC's. Technical issues are fading with switch support for SVC's (I gather Stratacom switches will allow SVC's Real Soon Now). Whether your provider is interested in offering the service may also be a business decision on their part: presumably they receive less income from SVC's ("pay-per-use") and the billing may be more complicated (someone's got to track actual usage). The reverse side of that (lower rates) is why we're all interested in SVC's.

Configuring SVC's on the router is relatively easy. You need a command to enable SVC support, and a map-group command, to specify the "phone book". Additional class statements point to map-class statements indicating differing types of service. Below, the addresses in the first entry in my-fr-phonebook are at the "normal" level of service. The second entries use a slower connection.

Here's what that might look like:

interface serial 0
encapsulation frame-relay ietf
ip address A.B.C.D
frame-relay svc
map-group my-fr-phonebook
map-list my-fr-phonebook source-addr e164 111222 dest-addr e164 111333
ip A.B.C.E class normal-class broadcast
ipx 123fde.0000.0c01.2345 class normal-class broadcast
map-list my-fr-phonebook source-addr e164 111222 dest-addr e164 111555
ip A.B.C.F class slow-class broadcast
ipx 123ggg.0000.0c01.6789 class slow-class broadcast
map-class normal-class
frame-relay cir in 1000000
frame-relay cir out 128000
map-class slow-class
frame-relay cir in 128000
frame-relay cir out 56000
I'm interpolating from the documentation here a bit -- it's not clear on how to configure multiple destinations for SVC's, but the syntax shown above is the obvious analog to the way it works for ATM.

The map class commands allow us to specify: custom-queue list or priority list (to prioritize traffic), cir in and out, minimum acceptable cir in and out, bc (committed burst size) and be (excess burst size) both in and out, idle timeout duration, and whether BECN throttles the frame transmission rate. So we get a lot of control over the SVC calls that get placed by our router.

New command for seeing status information with SVC's: show frame-relay lapf.

Traffic Shaping

IOS Release 11.2 supports both generic traffic shaping on interfaces and Frame Relay traffic shaping.

The Frame Relay traffic shaping allows

  • rate enforcement per PVC or SVC
  • dynamic traffic throttling in response to BECN packets
  • custom or priority queuing per virtual circuit
The intent is to allow guaranteed bandwidth for each type of traffic. The queuing features let us prioritize per-circuit, and the rate enforcement makes sure that we won't have a burst on one virtual circuit denying access line bandwidth to the others.

Rate enforcement also makes better use of bandwidth with WAN-hostile protocols (ones that blast away full tilt, never noticing that they're also retransmitting a lot and that it might make more sense to back off and slow down). With rate enforcement, the router controls the pace at which packets are fed into each virtual circuit.

I see the key issue as being where traffic policing takes place. If your provider is kind enough to not have enforcement at their Frame Relay switch, your frames may make it deep into their network before congestion causes them to be discarded. They may feed out of your central router at the access speed, say T1 speed, and perhaps get discarded only when they have to cross a 56K access line to the slow remote site. With rate enforcement, the central site router can buffer (up to a point) then discard excess frames per VC. This ensures that the rate at which frames are fed into a VC doesn't exceed the speed or excess burst capacity at the other end of the VC.

Here's what a sample Frame Relay traffic shaping configuration might look like:

interface serial 0
encapsulation frame-relay ietf
frame-relay traffic-shaping
frame-relay class my-map-class
map-class frame-relay my-map-class
frame-relay traffic-rate 28000 56000
frame-relay custom-queue-list 8
queue-list 8 ...
The map class my-map-class specifies an average traffic rate of 28 Kbps, with peak of 56 Kbps. Traffic will be prioritized according to custom queue list 8.

A map class with traffic shaping parameters may be specified by using the class command. This looks like:

interface serial 0.100 point-to-point
ip address A.B.C.D
frame-relay interface-dlci 100
class my-slow-map-class
map-class frame-relay my-slow-map-class
frame-relay traffic-rate 9600 16000
frame-relay priority-group 2
priority-list 2 ...

Frame Relay Compression

Frame Relay compression has been in the IOS since 11.0 or so. The method is Stacker compression. It is payload compression, since intervening Frame Relay switches need to be able to use the Frame Relay header to forward the frame.

It's really easy to turn compression on for a point-to-point subinterface:

interface serial 0.100 point-to-point
ip address ...
frame-relay interface-dlci 100
frame-relay payload-compress packet-by-packet
Watch your CPU! I'd expect to be able to handle something like 128 Kbps to 256 Kbps of data (pre-compression) on a 2500 model router. At most. So use with caution, and keep an eye on show process cpu.

By the way, it appears that compression can operate asymmetrically. In the lab, we turned it on at one end of a PVC, and observed that we seemed to be still able to communicate just fine with the other end of the PVC. I'd suggest testing this for yourself before you count on it -- don't invite Murphy's Law to activate itself!

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This email address is being protected from spambots. You need JavaScript enabled to view it. .

Copyright (C)  1997,  Peter J. Welcher