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 PVC's (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 article can cover all you'd want to know, so we'll stick with some of the topics that seem to give people problems.
First of all, understand that Cisco has made it absolutely easy to configure Frame Relay on a router. It may take as little as:
interface serial 0Really! That's 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:
encapsulation frame-relay
interface serial 0This 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 default is Cisco, and this overrides that with the ANSI standard version.
encapsulation frame-relay ietf
frame-relay lmi-type ansi
(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 DLCI's (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. It's not quite like a phone number, because different sites may use different DLCI's to reach a given destination. If all sites use a common DLCI for each possible destination, your service provider is using Global DLCI's, 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. The end result is that routers learn the protocol addresses and DLCI's 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 all differ on all your routers! That's an awful lot of addresses and numbers to configure correctly.
Many people don't seem to appreciate is 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 is real work, especially when you realize it isn't necessary! (Nor is the counterpart needed for X.25, Dial on Demand Routing, ATM, or SMDS). The modern version of this for Frame Relay is anxiety about remote networks not showing up when you do the command:
show frame-relay mapThis command shows the mappings the router has established: protocol address and DLCI number.
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 "pipe size". It's the rate at which the service provider is guaranteeing to handle your data.
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.
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 PVC's 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. Well worth looking into!
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 a 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.
Point-to-point subinterfaces pair subinterfaces with PVC's. The PVC is treated by the router as if it were a separate physical link (logically, it is). It gets a separate IP subnet or IPX network number. Use of subinterfaces allows for routing via other PVC's 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 it to DLCI 123:
interface serial 0This 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 Design course (CID), which I teach, also has a section on Frame Relay design.
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 ...
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 nine CCIE's, with 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. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .