With the growing popularity of Frame Relay, I've been revising CCCI's Frame Relay Technology Course to make it a regular, open-enrollment offering. Those of you operating in a Frame Relay environment know how popular it is (just try and get new circuits provisioned quickly).
Those not already doing so may want to look into Frame Relay: there are some persuasive cost-savings to be had. Some stem from using one physical serial interface and access line to carry traffic to multiple sites. Additional savings can come from reduced fees for PVCs (Permanent Virtual Circuits) versus leased lines. And when you need to add a site, Frame Relay is a major win!
This article focuses on some aspects of Frame Relay configuration. There is no way this can cover all you'd want to know, so we'll specifically discuss some topics that seem to give managers problems.
First of all, understand that Cisco has made it easy to configure Frame Relay on a router. It may take as little as:
interface serial 0
encapsulation frame-relay
Really! Now, this is if you and your service provider use the default settings. If you're working with equipment from several vendors, or prefer to adhere to standards, you might instead configure:
interface serial 0
encapsulation frame-relay ietf
frame-relay lmi-type ansi
This uses the IETF (Internet Engineering Task Force) encapsulation instead of the default Cisco "Gang of 4" (Cisco, Northern Telecom, StrataCom, Digital Equipment Corporation) encapsulation. It also specifies the LMI (Local Management Interface) used by the router to talk to the Frame Relay switch. The "LMI-type" command overrides the Cisco default with the ANSI standard version. (For what it's worth, the "Gang of 4" vendors agreed on a preliminary standard, to be interoperable until the official standards were completed.)
If you're going to work with Frame Relay, you have to know about DLCIs (Data Link Connection Identifiers). All you really need to know is that the router at one end of a PVC puts a DLCI number into the Frame Relay packet it sends, and this determines where the packet arrives (see Figure 1). It's not quite like a phone number, because different sites may use different DLCIs to reach a given destination.
If all sites use a common DLCI for each possible destination, your service provider is using Global DLCIs, which can be treated as more or less a "site telephone number." They are a little easier to understand and document.
What makes Frame Relay simple to configure is a mechanism called Inverse ARP. It wasn't always so easy (remember those fun, tedious, "frame-relay map ..." statements?)
.Inverse ARP first appeared in Cisco routers in the first half of 1994 with release 9.21. The idea is that when the switch notifies the router via the LMI that a PVC is active, the router sends out one or more packets bearing its protocol address(es). The router on the other end uses the Inverse ARP packet to acquire the protocol address and the DLCI of the other router. It also sends back information about itself. (See Figure 2.) The end result is that routers learn the protocol addresses and DLCIs for each peer router attached to the Frame Relay cloud. When they have to send a packet to one of their peers, they know the DLCI number that goes in the Frame Relay header.
Contrast the "old days," when a mapping statement was needed for each peer router, one per protocol address and DLCI. And they might have been all different on all the routers! That's a lot of addresses and numbers to configure correctly!
Many people don't seem to appreciate that Inverse ARP is enabled by default. That is, if you are starting up Frame Relay from scratch, you don't have to configure anything to gain the benefits of Inverse ARP.
Another misconception I've seen is that some folks think their router has to know about every remote network. In the "old days," they'd put in a frame-relay map statement for every possible destination! This was real work, especially when you realize it wasn't necessary!
To understand what's happening, remember that routers talk to each other. Routing updates inform a router about other networks. If a packet arrives at a router, the router looks up the destination in the routing table. It finds a next hop router.
In Frame Relay, the next hop router is a peer across the Frame Relay cloud. The router now knows what interface to send the packet out, which router to send it to, but it still needs to put the data layer encapsulation on the packet. That requires a DLCI number, so the switches can get the frame to the right destination. That's where the Inverse ARP information gets used!
So all the Frame Relay router really needs to know is who its peers are and how to get frames to them. Routing tables, reflecting routing updates, take care of more distant networks.
Another misconception that's popped up lately concerns CIR (Committed Information Rate). Think of the CIR as a contractual "pipesize." It's the rate at which the service provider is guaranteeing to handle your data. The CIR is typically part of what you pay for when you order Frame Relay service. Some sites have ordered a CIR of 0, which is inexpensive. They then get upset when they start getting lost packets and retransmissions, typically when they weren't getting any before. Some people think their Cisco router isn't communicating properly with the Frame Relay switch, since the symptoms match what you see with no flow control.
What's really going on is that the CIR is how much data the service provider contracts to deliver. They may be offering CIR 0 as a good deal to drum up business, but it's costing them money, in terms of extra capacity. Or it's coming out of unused capacity other customers pay for but don't use. As usage picks up, the service you once received may evaporate. So don't expect such "freebies" to last! If your router is feeding out data at a faster rate than the pipe size you've contracted for, it's up to you to spot it and order a bigger pipe.
Some protocols, like TCP/IP with its implicit congestion notification, observe packet loss and back off. DECnet and ISO CLNS protocol receive FECN (Forward Explicit Congestion Notification) notification from the Frame Relay switches via the router, and this can cause end nodes to back off. Other protocols may just keep spewing packets faster than the link can handle them.
Your contract typically allows you some burst capacity above the CIR. So as utilization increases, you may see gradual degradation as you exceed the CIR and/or burst capacity. Degradation may be more severe, depending on how your service provider does things. Most sites want to increase their CIR before this happens (or analyze their traffic and reduce the load).
Network management tools are often capable of tracking utilization. Some service providers may include utilization in billing or reports as part of their service. (A service-oriented service provider ought to be more than willing to provide you this information to get you to order, and pay for, more service.) It really is a good idea to keep an eye on your Frame Relay PVC utilization.The simplest model of a Frame Relay network is the NBMA (Non-Broadcast Multi-Access) model. The Frame Relay network is treated as one IP subnet or IPX network. It's an odd one, in that there are several stations attached but they can't use broadcasts to reach all the others simultaneously. This model can be easy to configure, but when a PVC goes down the router may not respond as you'd wish.
Another important concept in Cisco Frame Relay is subinterfaces, which are probably another whole article in themselves. Subinterfaces are another Frame Relay tool that arrived with IOS 9.21. They're more work to configure, but they really make Frame Relay PVCs match up better with the router's way of doing things. That translates to fewer surprises, such as having to reconfigure a number of Frame Relay routers to add AppleTalk or IPX support. This is well worth looking into!
Point-to-point subinterfaces pair subinterfaces with PVCs. The PVC is treated by the router as if it were a separate physical link (logically, it is). (See Figure 3.) It gets a separate IP subnet or IPX network number. Use of subinterfaces allows for routing via other PVCs if one becomes inactive. It also allows for bandwidth, descriptions, and access lists on a per-PVC basis.
And it avoids split-horizon issues, which can affect AppleTalk, IPX SAPs, and transparent bridging. To configure a point-to-point subinterface and tie into DLCI 123:
interface serial 0
encapsulation frame-relay ietf
frame-relay lmi-type ansi
interface serial 0.1 point-to-point
frame-relay interface-dlci 123 broadcast
ip address ...
ipx network ...
This blurs into Frame Relay network design, another topic about which there's a lot to be said. The Cisco Internetworking Design Guide, available on UniverCD, has a lot of good information in it. The Cisco Internetworking Design course (CID), which I teach, also has a section on Frame Relay design.
(Part 2 of Dr. Welcher's article on Frame Relay will appear in the next issue of The Network Monitor)