Frame relay is still one of the most popular WAN services deployed over the past decade, and there’s a good reason for this cost. And it’s a rare network design or designer that has the privilege to ignore that all-important cost factor!
By default, frame relay is classified as a non-broadcast multi-access (NBMA) network, meaning it doesn’t send any broadcasts like RIP updates across the network. No worries we are not going leave you hanging. We’ll get into this more soon.
Frame relay has at its roots a technology called X.25, and it essentially incorporates the components of X.25 that are still relevant to today’s reliable and relatively “clean” telecommunications networks while leaving out the no-longer-needed error correction components. It’s substantially more complex than the simple leased line networks you learned about when we discussed the HDLC and PPP protocols. The leased line networks are easy to conceptualize but not so much when it comes to Frame relay. It can be significantly more complex and versatile, which is why it’s often represented as a “cloud” in networking graphics. We’ll get to that in a minute for right now, we are going to introduce frame relay in concept and show you how it differs from simplex leased-line technologies.
Along with your introduction to this technology, you’ll get a virtual dictionary of all the new terminology you’ll need to solidify grasp the basics of frame relay. After that, we’ll guide you through some simple frame-relay implementations.
Introduction to Frame relay
As a CCNA, you’ll need to understand the basics of the frame relay technology and be able to configure it in simple scenarios. First, understand that Frame relay is a packet-switched technology. From everything you’ve learned so far, just telling you this should make you immediately realize several things about it:
You won’t be using the encapsulation hdlc or encapsulation ppp command to configure it.
Frame relay doesn’t work like a point-to-point leased line (although it can be made to look and act like one).
Frame relay is usually less expensive than leased lines are, but there are some sacrifices to make to get those savings.
So, why would you even consider using frame relay? Take a look at the picture below to get an idea of what a network looked like before frame relay. Now check out the next picture. You can see that there’s now only one connection between the corporate router and the frame relay switch. That saves some major cash!
If, for example, you had to add seven remote sites to the corporate office and had only one free serial port on your router it’s frame relay to the rescue! Of course, we should probably mentioned that you now also have one single point of failure, which is not so good. But frame relay is used to save money, not to make a network more resilient.
Coming up, we are going to cover the Frame relay technology information you need to know about when studying the CCNA objectives.
Committed Information Rate (CIR)
Frame Relay provides a packet-switched network to many different customers at the same time. This is a really good thing because it spreads the cost of the switches among many customers. But remember, frame relay is based on the assumption that all customers won’t ever need to transmit data constantly, and all at the same time.
Frame relay works by providing a portion of dedicated bandwidth to each user, and it also allows the user to exceed their guaranteed bandwidth if resources on the telco network happen to be available. So basically, frame relay providers allow customers to buy a lower amount of bandwidth than what they really use. There are two separate bandwidth specifications with frame relay:
Access rate: the maximum speed at which the Frame Relay interface can transmit.
CIR: The maximum bandwidth of data guaranteed to be delivered. In reality, it’s the average amount that the service provider will allow you to transmit.
If these two values are the same, the frame relay connection is pretty much just like a leased line. But they can also be set to different values. Here’s an example: let’s say you buy an access rate of T1 (1.54Mbps) and a CIR of 256Kbps. By doing this, the first 256Kbps of traffic you send is guaranteed to be delivered. Anything beyond that is called a “burst” a transmission that exceeds your guaranteed 256Kbps rate, and ban is any amount up to the T1 access rate (if that amount is in your contract). If your combined committed burst (the basis for your CIR) and excess burst sizes, known as the MBR or maximum burst rate when combined, exceed the access rate, you can pretty much say goodbye to your additional traffic. It will most likely be dropped, although this really depends on the subscription level of a particular service provider.
In a perfect world, this always works beautifully but remember that little word guarantee? As in a guaranteed rate of 256Kbps, to be exact? This means that any burst of data you send that exceeds your guaranteed 256Kbps rate will be delivered on something called a “best-effort” basis of delivery. Or maybe not if your telco’s equipment doesn’t have the capacity to deliver it at any time you transmitted, then your frames will be discarded, and the DTE will be notified. Timing is everything you can scream data out at six times your guaranteed rate of 256Kbps (T1) only if your telco has the capacity available on its equipment at that moment. Remember that “oversubscription” we talked about? Well, here it is in action!
Frame Relay Encapsulation Types
When configuring frame relay on Cisco routers, you need to specify it as an encapsulation on serial interfaces. As we said earlier, you can’t use HDLC or PPP with frame relay. When you configure frame relay, you specify an encapsulation of frame relay (as shown in the following output). But unlike HDLC or PPP, with frame relay, there are two encapsulation types: Cisco and IETF (Internet Engineering Task Force). The following router output shows these two different encapsulation methods when frame relay is chosen on your cisco router:
routerA(config)#int s0
routerA(config-if)#encapsulation frame-relay ?
ietf use RFC1490 encapsulation
<cr>The default encapsulation is Cisco unless you manually type in ietf, and Cisco is the type to use when connecting two Cisco devices. You’d opt for the IETF-type encapsulation if you needed to connect a Cisco device to a non-Cisco device with Frame relay. Whichever you choose, make sure that the frame relay encapsulation is the same on both ends.
Virtual circuits
Frame relay operates using virtual circuits as opposed to the actual circuits that leased lines use. These virtual circuits are what link together the thousands of devices connected to the provider’s “cloud”. Frame relay provides a virtual circuit between your two DTE devices, making them appear to be connected via a circuit when in reality, they’re dumping their frames into a large, shared infrastructure. You never see the complexity of what’s actually happening inside the cloud because you only have a virtual circuit.
And on top of all that, there are two types of virtual circuits permanent and switched. Permanent Virtual Circuits (PVCs) are by far the most common types in use today. What “permanent” means here is that the telco creates the mappings inside their gear and as long as you pay the bill, they’ll remain in place.
Switched virtual circuits (SVCs) are more like a phone call. The virtual circuit is established when data needs to be transmitted, then it’s taken down when the data transfer is complete.
Data Link Connection Identifiers (DLCIs)
Frame relay PVCs are identified to DTE end devices by Data Link connection identifiers (DLCIs). A-frame relay service provider typically assigns DLCI values, which are used on frame relay interfaces to distinguish between different virtual circuits. Because many virtual circuits can be terminated on one multipoint frame relay interface, many DLCIs are often affiliated with it.
Let us explain suppose you have a central HQ with three branch offices. If you were to connect each branch office to HQ using a T1, you would need three serial interfaces on your routers at HQ, one for each T1. Simple, right? Well, suppose you use Frame Relay PVCs instead. You could have a T1 at each branch connected to a service provider and only a single T1 at HQ. there would be three PVCs on the single T1 at HQ, one going to each branch. And even though there’s only a signal interface and a signal CSU/DSU, the three PVCs function as three separate circuits. Remember what we said about saving money? How much for two additional T1 interfaces and a pair of CSU/DSUs? Answer: A lot! So, why not just go ahead and ask for a percentage of the savings in your bonus?
Okay, before we go on, we want to define Inverse ARP (IARP) and discuss how it’s used with the DLCIs IFrame Relay network. Yes, it is somewhat similar to ARP in the fact that it maps a DLCI to an IP address kind of like ARP does with MAC addresses to IP addresses. And even though you can’t configure IARP, you can disable it. It runs on a Frame relay router and maps the DLCI to an IP address for Frame relay so it knows how to get to the Frame relay switch. You can see IP-to-DLCI mappings with the show frame-relay map command.
But if you have a non-Cisco router living in your network and it doesn’t support IARP, then you’re stuck with having to statically provide IP-to-DLCI mappings with the frame-relay map command something we’ll demonstrate here.
Let’s talk about DLCIs a bit more. Their locally significant global significance requires the entire network to use the LMI extensions that offer global significance. This is why you’ll mostly find global DLCIs only in private networks.
But the DLCI doesn’t have to be globally significant for it to be functional in getting a frame across the network. Let me explain: When Router A wants to send a frame to Router B, it looks up the IARP or manual mappings of the DLCI to the IP address it’s trying to get to. Equipped with the DLCI, it then sends the frame out with the DLCI value is found in the DLCI field of the FR header. The provider’s ingress switch gets this frame and does a look upon the DLCI/physical port combination it observes. Associated with that combination, it finds a new “locally significant” (meaning, between itself and the next-hop switch) DLCI to use in the header, and in the same entry in its table, it finds an outgoing physical port. This happens all the way to Router B. so basically, you actually could say that the DLCI Router A identifies the entire virtual circuit to Router B, even though every DLCI between every pair of devices could be completely different. The big point here is that Router A is unaware of these differences. That’s what makes the DLCI locally significant. So make a mental note that DLCIs really is used by the telco to “find” the other end of your PVC.
To discover why DLCIs are considered locally significant, take a look at the picture below. In the picture, DLCI 100 is considered locally significant to Router A and identifies the circuit between Router A and its ingress Frame Relay switch. DLCI 200 would identify the circuit between Router B and its ingress Frame Relay switch.
DLCI numbers are used to identify a PVC that is typically assigned by the provider and start at 16.
You configure a DLCI number to be applied to an interface like this:
RouterA(config-if)#frame-relay interface-dlci ?
<16-1007> Define a DLCI as part of the current subinterface
routerA(config-if)#frame-relay interface-dlci 16
local management Interface (LMI)
local Management Interface (LMI) is a signaling standard used between your router and the first frame relay switch it’s connected to. It allows for passing information about the operation and status of the virtual circuit between the provider’s network and the DTE (your router). It communicates information about the following:
- KeepAlives: These verify that data is flowing.
- Multicasting: This is an optional extension of the LMI specification that allows, for example, the efficient distribution of routing information and ARP requests over a Frame Relay network. Multicasting uses the reserved DLCIs from 1019 through 1022.
- Global Addressing: This provides global significance to DLCIs, allowing the Frame Relay cloud to work exactly like a LAN.
- Status of virtual Circuits: This provides DLCI status. This status inquiries and messages are used as keepalives when there is no regular LMI traffic to send.
But remember, LMI is no communication between your routers; it’s communication between your router and the nearest frame relay switch. So it’s entirely possible that the router on one end of a PVC is actively receiving LMI while the router on the other end of the PVC is not. And of course, PVCs won’t work with one end down. (we say this to clarify the local nature of LMI communications.)
There are three different types of LMI message formats: Cisco, ANSI, and Q.933A. the different kinds in use depend on both the type and configuration of the telco’s switching gear, so it’s imperative that you configure your router for the correct format, which should be provided by the telco.
On Cisco equipment, the default type is, surprise, Cisco, but you still might have to change to ANSI or Q.933A depending on what your service provider tells you. The three different LMI types are shown in the following router output:
routerA(config-if)#frame-relay lmi-type ?
cisco
ansi q933aAs seen in the output, all three standard LMI signaling formats are supported. Here’s a description of each:
Cisco: LMI defined by the Gang of Four (default). The Local Management Interface (LMI) was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation and became known as the Gang-of-Four LMI, or Cisco LMI.
ANSI: Annex D included with ANSI standard T1.617.
ITU-T(Q.933A): Annex A included in the ITU-T standard and defined by using the Q.933a command keyword.
Routers receive LMI information from the service provider’s frame relay switch on a frame-encapsulated interface and update the virtual circuit status to one of three different states.
Active State: Everything is up, and routers can exchange information.
Inactive State: The router’s interface is up and working with a connection to the switching office, but the remote router isn’t up.
Deleted State: No LMI information is being received on the interface from the switch, which could be due to a mapping problem or a line failure.
Frame Relay congestion control
Remember back to our talk about CIR? From that, it should be obvious that the lower your CIR is set, the greater the risk is that your data will become toast. This can be easily avoided if you have just one key piece of information when and when not to transmit that huge burst! This begs the question, is there any way for us to find out when our telco’s shared infrastructure is free and clear and when it’s crammed and jammed? Also, if there is a way to spy this out, how do you do it? Well, that’s exactly what we are going to talk about next how the frame relay switch notifies the DTE of congestion problems and address those very important questions. Here are the three congestions bits and their meanings:
- Discard Eligibility (DE): A you know, when you burst (transmit packets beyond the CIR of a PVC), any packets exceeding the CIR are eligible to be discarded if the provider’s network is congested at the time. Because of this, the excessive bits are marked with a Discard Eligibility (DE) bit in the Frame Relay header. And if the provider’s network happens to be congested, the frame relay switch will discard the packets with the first DE bit set. So if your bandwidth is configured with a CIR of zero, the DE will always be on.
- Forward Explicit Congestion Notification (FECN): When the Frame Relay network recognizes congestion in the cloud, the switch will set the Forward Explicit Congestion Notification (FECN) bit to 1 in a frame relay packet header. This will indicate to the destination DTE that the path the frame just traversed is congested.
- Backward Explicit Congestion Notification (BECN): When the switch detects congestion in the frame relay network, it’ll set the Backward Explicit Congestion Notification (BECN) bit in a Frame Relay frame that’s destined for the source router. This notifies the router that congestion is ahead. But the Cisco router won’t take action on this congestion information unless you tell them to.
Troubleshooting Using Frame Relay Congestion Control
routerA#sh frame-relay pvc
PVC statistics for interface serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI=100, DLCI USAGE=LOCAL, PVC STATUS=ACTIVE, INTERFACE=Serial0/0
Input pkts 1300 output pkts 1270 in bytes 21212000
Out bytes 21802000 dropped pkts 4 in pkts dropped 147
Out pkts dropped 0 out bytes dropped 0 in FECN pkts 147
In BECN pkts 192 out FECN pkts 147
Out BECN pkts 259 in DE pkts 0 out DE pkts 214
Out bcast pkts 0 out bcast bytes 0
Pvc create time 00:00:06, last time pvc status changed 00:00:06
Pod1R1#Now let’s say all your users are whining about the fact that their Frame Relay connection to the corporate site is super slow. Because you strongly suspect that the link is overloaded, you verify the Frame Relay congestion control information with the show frame-relay pvc command and get this:
What you want to look for is the in BECN pkts 192 output because this is what’s telling the local router that traffic sent to the corporate site is experiencing congestion. BECN means that the path that a frame took to “return” to you is congested.
Frame Relay implementation and Monitoring
as we have said, there are a ton of Frame relay commands and configuration options, but we are going to zero in on the ones you really need to know when studying for the CCNA exam objectives. We are going to start with one of the simplest configuration options two routers with a single PVC between them. Next, we’ll show you a more complex configuration using subinterfaces, and demonstrate some of the monitoring commands available to verify the configuration.
Single Interface
Let’s get started by looking at a simple example. Say that we just want to connect two routers with a single PVC. Here’s how that configuration would look:
routerA#config t
enter configuration commands, one per line. End with CNTL/Z.
routerA(config)#int 0/0
routerA(config-if)#encapsulation frame-relay
routerA(config-if)#ip address 172.16.20.1 255.255.255.0
routerA(config-if)#frame-relay lmi-type ansi
routerA(config-if)#frame-relay interface-dlci 101
routerA(config-if)#^Z
routerA#The first step is to specify the encapsulation as Frame Relay. Notice that since we didn’t specify a particular encapsulation type either Cisco or IETF the Cisco default type was used. If the router were non-Cisco, we wouldn’t specify IETF. Next, we assigned an IP address to the interface, then specified the LMI type of ANSI (the default being Cisco) based on information provided by the telecommunications provider. Finally, we added the DLCI of 101, which indicates the PVC we want to use (again, given to me by my ISP) and assumes there’s only one PVC on this physical interface.
That’s all there is to it if both sides are configured correctly, the circuit will come up.
Sub Interfaces
You probably know by now that we can have multiple virtual circuits on a single serial interface and yet treat each as a separate interface we did mention this earlier. We can make this happen by creating subinterfaces. Think of a sub-interface as a logical interface defined by the IOS software. Several sub interfaces will share a single hardware interface, yet for configuration purposes, they operate as if they were separate physical interfaces, something known as multiplexing.
To configure a router in a Frame Relay network so it will avoid split-horizon issues by not permitting routing updates, just configure a separate sub-interface for each PVC, with a unique DLCI and subnet assigned to the subinterface.
You define sub interfaces using a command like int s0.subinterface number. First, you have to set the encapsulation on the physical serial interface, and then you can define the sub-interfaces generally one subinterface per PVC. Here’s an example:
routerA(config)#int s0
routerA(config-if)#encapsulation frame-relay
routerA(config-if)#int s0.?
<0-4294967295> serial interface number
routerA(config-if)#int s0.16 ?
multipoint treat as a multipoint link
point-to-pointn treat as a point-to-point link
routerA(config-if)#int s0.16 point-to-pointyou can define a serious amount of subinterfaces on any given physical interface, but keep in mind that there are only about a thousand available DLCIs. In the preceding example, we chose to use sub interface 16 because that represents the DLCI number assigned to that PVC by the carrier. There are two types of subinterfaces.
- Point-to-Point: Used when a single virtual circuit connects one router to another. Each point-to-point subinterface requires its own subnet.
- Multipoint: This is when the router is the center of a star of virtual circuits that are using a single subnet for all router’s serial interfaces connected to the frame switch. You’ll usually find this implementation with the hub router in this mode and the spoke routers in the physical interface (always point-to-point) or point-to-point subinterface mode.
Next, we’ll show you an example of a production router running multiple subinterfaces. In the following output, notice that the subinterface number matches the DLCI number, not a requirement, but it majorly helps you administer the interfaces.
Interface serial0
No ip address (notice there is no IP address on the physical interface!)
No ip directed-broadcast encapsulation frame-relay
!
Interface serial0.102 point-to-point ip address 10.1.12.1 255.255.255.0
No id directed-broadcast
Frame-relay interface-dlci 102
!
Interface serial0.103 point-to-point
Ip address 10.1.13.1 255.255.255.0
No ip directed broadcast
Frame-relay interface-dlci 103
!
Interface serial0.104 point-to-point
Ip address 10.1.14.1 255.255.255.0
No ip directed-broadcast
Frame-relay interface-dlci 104
!
Interface serial0.104 point-to-point
Ip address 10.1.15.1 255.255.255.0
No ip directed-broadcast
Frame-relay interface-dlci 105
!Notice that there’s no LMI type defined. This means that the routers are either running the Cisco default or they’re using auto-detect (if running Cisco IOS version 11.2 or newer). We also want to point out that each interface maps to a single DLCI and is defined as a separate subnet. Remember point-to-point subinterfaces solve split-horizon issues well.
Monitoring Frame Relay
Several commands are used frequently to check the status of your interfaces and PVC’s once you have frame-relay encapsulation set up and running. To list them, use the show frame ? command, as seen here:
routerA#show frame ?
end-to-end frame-relay end-to-end VC information
fragment show frame relay fragmentation information
ip show frame relay IP statistics
lapf show frame relay lapf status/statistics
lmi show frame relay lmi statistics
map frame-relay map table
pvc show frame relay pvc statistics
qos-autosense show frame relay qos-autosense information
route show frame relay route
svc show frame relay SVC stuff
traffic frame-relay protocol statistics
vofr show frame relay VoFR statisticsthe most common parameters that you view with the show frame-relay command are lmi, pvc, and map.
Now, let’s take a look at the most frequently used commands and the information they provide.
The show frame-relay lmi command
The show frame-relay lmi command will give you the LMI traffic statistics exchanged between the local router and the Frame Relay switch. Here’s an example:
Router#show frame lmi
LMI statistics for interface serial0/0 (Frame Relay DTE)
LMI TYPE = CISCO
Invalid unnumbered info 0 Invalid Prot Disc 0
Invalid dummy call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num status msgs rcvd 0
Num update Status Rcvd 0 Num status Timeouts 0
Router#The router output from the show frame-relay lmi command shows you any LMI errors, plus the LMI type.
The show frame pvc command
The show frame pvc command will present you with a list of all configured PVCs and DLCI numbers. It provides the status of each PVC connection and traffic statistics too. It will also give you the number of BECN and FECN packets received on the router per PVC.
Here is an example:
routerA#show frame pvc
PVC statistics for interface serial0 (Frame Relay DTE)
DLCI=16, DLCI USAGE=LOCAL, PVC STATUS=ACTIVE,
INTERFACE=Serial0.1
Input pkts 50977876 output pkts 41822892
In bytes 3137403144
Out bytes 3408047602 dropped pkts 5
In FECN pkts 0
In BECN pkts 0 out FECN pkts 0 out BECN pkts 0
In DE pkts 9393 out DE pkts 0
Pvc create time 7w3d, last time pvc status changed 7w3d
DLCI=18, DLCI USAGE=LOCAL, PVC STATUS=ACTIVE,
INTERFACE=serial0.3
Input pkts 30572401 output pkts 31139837
In bytes 1797291100
Out bytes 3227181474 dropped pkts 5
In FECN pkts 0
In BECN pkts 0 out FECN pkts 0 out BECN pkts 0
In DE pkts 28 out DE pkts 0
Pvc create time 7w3d, last time pvc status changed 7w3dIf you only want to see information about PVC 16, you can type the command show frame-relay pvc 16.
The show interface command
You can use the show interface command to check for LMI traffic. The show interface command displays information about the encapsulation, as well as Layer 2 and Layer 3 information. It also displays line, protocol, DLCI, and LMI information. Check it out.
RouterA#show int s0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely
255/255, load 2/255
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
LMI enq sent 451751, LMI stat recvd 451750, LMI upd recvd
164, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 0/0,
Interface broadcasts 839294The LMI DLCI above is used to define the type of LMI being used. If it happens to be 1023, it’s the default LMI type of Cisco. If LMI DLCI is zero, then it’s the ANSI LMI type (Q.933A uses 0 as well). If LMI DLCI is anything other than 0 or 1023, it’s a 911 call your provider; they’ve got major issues!
The show frame map command
The show frame map command displays the Network layer to DLCI mappings. Here’s how that looks like:
routerB#show frame map
serial0 (up): ipx 20.0007.7842.3575 dlci 16(0x10, 0x400),
dynamic, broadcast, status defined, active
Serial0 (up): ip 172.116.20.1 dlci 16(0x10, 0x400),
Dynamic, broadcast, status defined, active
Serial1 (up): ipx 40.0007.7842.153a dlci 17(0x11, 0x410),
Dynamic, broadcast, status defined, active
Serial1 (up): ip 172.16.40.2 dlci 17(0x11, 0x410),
Dynamic, broadcast, status defined, activeNotice that the serial interfaces have two mappings one for IP and one for IPX. Also important is that the Network layer addresses were resolved with the dynamic protocol Inverse ARP (IARP). After the DLCI number is listed, you can see some numbers in parentheses. The first one is 0x10, which is the hex equivalent for the DLCI number 16, used on serial 0. And the next 0x11 is the hex for DLCI 17 used on serial 1. The second numbers, 0x400 and 0x410, are the DLCI numbers configured in the Frame Relay frame. They are different because of the way the bits are spread out in the frame.
The debug frame lmi command
The debug frame lmi command will show output on the router consoles by default (as with any debug command). The information this command gives you will enable you to verify and troubleshoot the Frame Relay connection by helping you determine whether the router and switch are exchanging the correct LMI information. Here’s an example:
Router#debug frame-relay lmi
Serial3/1 (in): status, myseq 214
RT IE 1, length 1, type 0
KA IE 3, length 2, yourseq 214, myseq 214
PVC IE 0x7, length 0x6, dlci 130, status 0x2, bw 0
Serial3/1 (out): StEnq, myseq 215, yourscreen 214, DTE up
Datagramstart=0x1959DF4, datagramsize=13
FR encap=0xFCF10309
00 75 01 01 01 03 02 D7 D6
Serial3/1 (in): status, myseq 215
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 215, myseq 215
Serial3/1 (out):StEnq, myseq 216, yourscreen 215, DTE up
Datagramstart = 0x1959DF4, datagramsize=13
FR encap=0xFCF10309
00 75 01 01 01 03 02 D8 D7Troubleshooting Frame Relay Networks
Troubleshooting Frame Relay networks aren’t any harder than troubleshooting any other type of network as long as you know what to look for, which is what we are going to cover now. We’ll go over some basic problems that commonly occur in Frame Relay configuration and how to solve them.
First on the list are serial encapsulation problems. As you learned recently, there are two frame relay encapsulations: Cisco and IETF. Cisco is the default, and it means that you have a Cisco Router on each end of the Frame Relay network. If you don’t have a Cisco router on the remote end of your Frame relay network, then you need to run the IETF encapsulation as shown here:
routerA(config)#int s0
routerA(config-if)#encapsulation frame-relay ?
ietf Use RFC1490 encapsulation
<cr>
routerA(config-if)#encapsulation frame-relay ietfonce you verify that you’re using the correct encapsulation, you then need to check out your Frame Relay mappings. For example, take a look at the following picture:
So why can’t’ Router A talk to Router B across the frame relay network? To find that out, take a close look at the frame-relay map statement. See the problem now? You cannot use a remote DLCI to communicate to Frame Relay switch; you must use your DLCI number! The mapping should have included DLCI 100 instead of DLCI 200.
Now that you know how to ensure that you have the correct Frame Relay encapsulation and that DLCIs are only locally significant, let’s look into some routing protocol problems typically associated with frame relay. See if you can find a problem with the two configurations in the picture below.
Hmmm, well, the configs look pretty good. Actually, they look great, so what’s the problem? Well, remember that Frame Relay is a non-broadcast multi-access (NBMA) network by default, meaning that it doesn’t send any broadcasts across the PVC. So, because the mapping statements do not have the broadcast argument at the end of the line, broadcasts, like RIP updates, won’t be sent across the PVC.