Frame Relay Terminology
- Describe different methods for connecting to a WAN
As with most Cisco concepts, you’ll find that the configuration piece of Frame Relay is fairly simple; the difficulty appears when you try to understand the concepts behind the configuration. Frame Relay introduces a plethora of new terms that describe the end-to-end communication. The first term you have already seen: a virtual circuit. You’ll now find out that there are two types of virtual circuits.
Permanent Virtual Circuit
A permanent virtual circuit (PVC) is a permanently established circuit through the Frame Relay service provider network. It enables the routers at each end to communicate with each other without any setup process. A PVC closely emulates a leased-line connection between your devices.
Switched Virtual Circuit
A switched virtual circuit (SVC) gives you an “on-demand” connection through the Frame Relay cloud. The connection from end-to-end is built as the routers require it and may be billed on a usage basis (very much like ISDN connections). SVC connections have largely decreased in use in recent years (almost to the point of non-existence) because service providers no longer have true end-to-end Frame Relay connections, but rather, convert from Frame Relay to some other network type after you transmit data into the cloud. If this seems odd, remember: What happens in the cloud, stays in the cloud.
Local Management Interface
The local management interface (LMI) signaling is the “language of love” between your router and the service provider. Using LMI, the service provider can transmit status information about the state of your virtual circuits to your router. In recent versions of the IOS, your router can auto-detect what LMI language the service provider uses. In older IOS versions, this must be manually configured under the interface.
Data Link Connection Identifier
It is a little known fact that router serial interfaces do not have MAC addresses. MAC addresses are related only to LAN connections. WAN connections therefore all have different Layer 2 addresses that they use to identify the other side of the connection. In the case of Frame Relay, this is known as a Data Link Connection Identifier (DLCI). Communicating through DLCIs is unlike most other network communication that you’ve seen thus far. Rather than
access a destination DLCI number to reach the remote router, you leave on a local DLCI number to reach a remote router.
This is very similar to the way airline travel works. When you want to fly to a remote destination, say North Dakota, you might leave on flight #4513. When you want to return from North Dakota to your original location, you might leave on flight #4839. This means that the DLCI numbers you use are locally significant; the DLCIs you have in Arizona matter only to the router in Arizona. The DLCIs you have in North Dakota matter only to the router in North Dakota. Look at Figure 23.5 for a network diagram.
Figure 23.5 shows a full mesh design with three locations: Arizona, California, and Michigan. At each location, the routers have two virtual circuits that enable them to reach the other locations. Now remember, the way DLCIs work is you leave on a local DLCI number rather than access a remote DLCI, so if Arizona wants to reach California, it uses DLCI number 507 to get there. If California wants to get back to Arizona, it uses DLCI 705. Likewise, California uses DLCI 401 to reach the router in Michigan.
Because DLCIs are locally significant, service providers can do whatever they want with them. Take a look at the DLCI connection between Arizona and Michigan. It’s not a mistype! Arizona is assigned to use DLCI 508 to reach Michigan. Michigan also uses DLCI 508 to reach Arizona. This seems to make no sense until you realize that the DLCI number 508 means something totally different if it is received in Arizona than if it is received in Michigan. Remember: locally significant. The service provider probably has DLCI 508 in use in many locations for many different customers. As long as the set of DLCIs is unique at each location, everything is fine with the Frame Relay standards.
Local Access Rate
The Local Access Rate (commonly called the line speed) is the maximum physical speed that your Frame Relay connection can attain. Today’s Frame Relay connections can usually reach up to T3 speeds (just over 44Mbps). This maximum can vary depending on the area in which you are and the service provider you are using. This does not define how fast your virtual circuits can travel. That’s the job of the Committed Information Rate (which is covered next).
However, the accumulation of all the bandwidth on all your virtual circuits can never exceed the router’s Local Access Rate.
Committed Information Rate
With a Frame Relay connection, really just two things heavily affect the price of the connection: first, the number of virtual circuits you purchase, and second, the Committed Information Rate (CIR) for each one of those virtual circuits. The CIR is the minimum speed the service provider commits to give you for the circuit at all times. It’s your guarantee.
Typically, you get more bandwidth than what your CIR dictates, but if the service provider starts running thin on bandwidth allocations, it can contractually cut your location’s virtual circuits down to the minimum amount of bandwidth defined by your CIR.
Now here’s the major concept: Each PVC you purchase has its own CIR. This can be mindboggling because you just learned about the Local Access Rate, which defines the maximum physical speed of the connection. Frame Relay enables you to divide up your connections, assigning a CIR for each PVC destination. Take a look at Figure 23.6.
You now have a hub and spoke Frame Relay design where Arizona is connected to California, Missouri, and Oregon. Focus for the moment on Arizona: The Local Access Rate is shown as T1 speed—1.544Mbps. Each PVC has its own CIR: The PVC to California is rated at a CIR of 500Kbps, the PVC to Missouri uses a CIR of 450Kbps, and the connection to Oregon uses a 300Kbps CIR. Notice that the total bandwidth of all the PVCs does not exceed the Local Access Rate of the line. Remember, the CIR is the minimum amount of bandwidth the service provider gives you. If you oversubscribe your Local Access Rate with the sum of all the CIRs, you may be physically limiting how much bandwidth the service provider would be willing to give you (and paying too much for your connection).
Many service providers offer extremely low-cost Frame Relay connections that are rated at a zero CIR. This means that you’ll probably get bandwidth, but the service provider does not guarantee anything. When signing up for one of these connections, be sure to use a reputable service provider because some of the smaller service providers may be oversubscribing their network with these connections and not have enough bandwidth to give you a reliable connection.
Backwards Explicit Congestion Notification
Because service providers allow you to burst above your CIR (using more bandwidth than you’re paying for), you have the potential of taking advantage of the service provider. If not configured differently, your router will attempt to send across all PVCs at the maximum speed the physical interface can handle (your Local Access Rate). If there is a large mismatch between your CIR and the Local Access Rate, your PVC will soon begin to become congested. The service provider will send messages to the router sending the large amount of traffic attempting to tell it to slow down. This is known as a Backwards Explicit Congestion Notification (BECN) message. The method the service provider uses to send this notification is important to understand.
Because of the way PVCs are engineered, the service provider cannot communicate directly to the router sending the data. Instead, it modifies the headers of return traffic to notify the person sending the excessive amount of data. For example, imagine that you were sitting at the Arizona location (from the prior Figure 23.6) transferring a large file to the California location via FTP. The entire time you are sending this file, the California site is sending TCP
Acknowledgments (ACKs) back to confirm the data receipt. If the Arizona site is excessively exceeding the CIR, the service provider flips a bit (known as the BECN bit) in the header of the ACK messages to notify the sender that it needs to slow down.
By default, your Cisco router ignores the BECN message (what audacity!). It does so because BECN response falls under a major configuration called Frame Relay Traffic Shaping, which you’ll learn plenty about if you decide to continue on into the CCNP courses. It is to your advantage to drop your speed when you receive a BECN message because the service provider will soon thereafter liquidate the vast majority of your traffic in the Frame Relay cloud, causing drastic performance reductions.
Forward Explicit Congestion Notification
This one is one of the most misunderstood of all Frame Relay terms. After you understand the concept of a BECN, it seems logical to assume a Forward Explicit Congestion Notification (FECN) tells the receiving side of the connection to slow down. This is not true at all. Why would a Frame Relay service provider tell the receiver to slow down? It is not sending any traffic, just receiving it. Instead, a FECN message is used to tell the receiver to generate traffic that the service provider can tag with a BECN to tell the sender to slow down.
I’m sure you’re thinking, “What?!?” Here’s an example. Again, you have a device in Arizona sending traffic to the California location. This time, they are sending an enormous video stream (which uses UDP communication). UDP requires no
acknowledgments, so the service provider has no return traffic to mark as a BECN to tell the sender to slow down. Instead, it tags some of the traffic heading to the receiver.
This is known as a FECN (it uses the same bit in the header as the BECN, but is interpreted as a FECN because it is sent the other way). If the receiving router is configured to support FECNs, it generates some “junk” (called a Q.922 test frame), puts it in a frame, and sends it back to the sender. The junk in the packet is really junk. The sending router in Arizona drops it after it is received. All it’s there for is to give the service provider something to tag to tell Arizona to slow down. So, a FECN message is just a method to generate some traffic so the service provider can send a BECN.
This term describes any traffic that you send above the CIR you have purchased. Because you are using bandwidth that you did not pay for, the service provider automatically tags your packets as Discard Eligible (written as De—that’s D subscript e).
Just because a packet is marked D e doesn’t mean it will be discarded. Most of the time it makes it across the Frame Relay network just fine. What the De marking means is if the service provider experiences congestion, guess which packets are the first to go—yep, the packets tagged as De. When you get deeper into Frame Relay traffic shaping (later in your Cisco career), you’ll discover that there’s a way to mark your own traffic De. This enables you to be selective with what traffic is marked D e rather than use the random selection of the service provider. This can keep your high-priority traffic from being sent above the CIR.
The Nature of NBMA Networks
- Describe different methods for connecting to a WAN
Frame Relay networks fall under the umbrella of Non-Broadcast Multi-Access (NBMA) networks. As the name implies, these networks allow multiple devices to access the network, but do not allow broadcast between them. Although this is their default behavior, you can configure your Cisco router to treat the network however you’d like. Because NBMA networks allow traffic between only the sites for which you purchase PVCs, this leads to some very odd configurations. The hub and spoke topology can be very confusing to manage until you understand the problems associated with these network types.
One of the major problems that can be encountered is that of running distance vector routing protocols over a Frame Relay network. These routing protocols (which include RIP, IGRP, and even EIGRP) have a built-in loop prevention mechanism called split-horizon. This mechanism prevents a router from sending an update out the same interface as that on which it received an update.
Figure 23.7 shows where the problems begin with the default Frame Relay configuration.
FIGURE 23.7 Split-horizon issues in Frame Relay networks.
This figure shows a typical hub and spoke configuration between Nevada, Washington, and New Mexico. Because this network is so simple, this company has decided to use the RIP routing protocol. Here’s how the problem starts: New Mexico sends an RIP routing update to Nevada regarding its 172.16.30.0/24 network. Nevada receives the update coming in its S0 interface. Now the spilt-horizon rule steps in and tells the Nevada router not to send that routing update back out the interface on which it was received. Washington never hears about the 172.16.30.0 network through the RIP protocol and is unable to access any devices at that location. The same thing goes for the Washington network. The advertisement reaches the Nevada router, but is never sent to New Mexico because of the split-horizon rule.
Two methods are used to solve this problem. First, you can disable the split-horizon mechanism altogether. This is a risky move because you are then relying on the other loop prevention mechanisms to keep a loop from happening in the network. The second method is to use subinterfaces.
Know the terminology behind Frame Relay. Especially ensure you understand the CIR and DLCI concepts.