Frame Relay configuration commands
Let’s look at a basic Frame Relay configuration with just two endpoints, headquarters and branch. In this case how many PVCs will we have? Just headquarters and branch, so one, one PVC.
First and foremost, we have to ensure that our addressing is correct. And here’s the immutable thing you can never get away with or away from, you’re in the same PVC, have to be in the same subnet. So are we in the same subnet? Absolutely! Could they have used the /30 mask? Yes but there is nothing wrong with this. Don’t go ooh, that’s wrong, no, they’re in the same subnet that is what we care about. So Layer 3 addressing looks fine to me, but I want you to go back up look at that kind of interface we’re on for a moment, kind of interface, it’s serial, right? What’s the default Layer 2 language that we’re running on that serial interface? Oh that would be HDLC, Cisco’s proprietary implementation of HDLC.
So that’s not going to work. Remember, two different encapsulations aren’t going to talk to one another, so we need to change it to Frame Relay as our Layer 2 language. So think about the commands that set like PPP, for instance, encapsulation PPP, encapsulation HDLC, encapsulation frame-relay works here. So we would’ve been able to do question mark and seen Frame Relay in the list, chosen that. Now there is something more you need to understand about this one, you definitely want to pay attention here. How many kinds of Frame Relay encapsulations could we have with this command? I mean there’s more than what meets the eye here like transformers, there’s more going on.
Two – we have Cisco and we have Internet Engineering Task Force, or IETF. Think about when we’d use each one. Cisco between Cisco devices, Cisco proprietary, that is the default. So if you type in encapsulation frame-relay and you don’t specify Cisco, it is using Cisco. IETF, open standard utilized between devices from different vendors, a Cisco router, a router from a different vendor, encapsulation frame-relay IETF. Does it have to be the same on both sides? Yeah I can’t do encapsulation frame-relay on my Cisco router, encapsulation frame-relay IETF on the other router. No, no, they have to be speaking the same language, make sure it’s the same on both sides. Now what are the ways that mapping can occur? We said with inverse ARP or statically. I don’t see a command here for inverse ARP, what’s going on?
HQ(router)#interface Serial0/0/0
HQ(router-if)#ip address 10.1.1.1 255.255.255.0
HQ(router-if)#encapsulation frame-relay
HQ(router-if)#bandwidth 64
Branch(router)#interface Serial0/0/0
Branch(router-if)#ip address 10.1.1.1 255.255.255.0
Branch(router-if)#encapsulation frame-relay
Branch(router-if)#bandwidth 64
Well we’re using inverse ARP by default. The way to think about it is every PVC is going to have inverse ARP on by default, it’s a per PVC thing; only have one. And remember what we told you about when it can work in your benefit, only in a point-to-point situation that really means only when there’s one PVC total on the Frame Relay cloud for you. So this in fact, works because we expect one PVC. So inverse ARP is going to perform a mapping and I in fact don’t even see my DLCIs in the config, but I’m getting them through LMI. So what would happen is, this, just to reiterate what we’ve learned. LMI is going to give us, for instance DLCI 100 on the far side, on the left-hand side, and 200 on the right-hand side, then inverse ARP would send those advertisements out via that message-in-a-bottle functionality, and then branch would get a mapping. The mapping would say on DLCI 200, the right-hand side on DLCI 200 to get to 10.1.1.1, go out DLCI 200, okay. So inverse ARP is going to work for us.
So what must happen for inverse ARP to work? Remember, what it is, it’s the message in the bottle, “Hello, I am 10.1.1.1.” So folks if you turn on Frame Relay encapsulation, but there is no IP address on the interface, inverse ARP will not happen, you need an IP address to use inverse ARP. So you need both an IP address and encapsulation frame-relay for inverse ARP to happen.
Now we’re likely to be running dynamic routing protocols across this link and we are still affected by the default bandwidth that is attached to serial interfaces. Do you remember what it is? It’s going be that of a T1; 1,544 in kbps. It is a T1 speed. And if our committed information rate, or CIR, is not T1, we want to affect the bandwidth, we want to affect the bandwidth parameter so that our routing protocols understand how fast this is because in today’s networks we may be backing up something with Frame Relay, this may not be the primary way to go, that’s the reality. We may have our primary pathway through an Internet Protocol Security, or IPSec, tunnel across the Internet and then back that up with Frame Relay.
We would want an accurate metric to be reflected there and usually, a backup is going to have a bad metric. Bandwidth 64 if that’s our CIR, that would be correct and that wouldn’t lie to our routing protocols. Sometimes, we lie to our routing protocols, but we don’t want to make a habit of it and we don’t want to do it accidentally, either. So this is a great basic config for Frame Relay. It’ll get the job done, but in the real world, we can be faced with some more complexities than just what is on this page because this is just, you know, a one-PVC scenario.
So let’s modify our config just a bit here. Instead of using inverse ARP, let’s do a static Frame Relay map, so let’s statically map our local DLCI to the remote IP address. But what are some of the reasons why we would want to use a static map as opposed to relying on inverse ARP?
Well there are a few. First, the topology. This is the biggest one. In a hub and spoke like topology, in a partial-mesh topology, you are not going to learn about IP addresses, which are not directly out as a PVC. The way that the message in a bottle works is it washes up on the shore once. For advertising our IP address, like a hub router, is not going to scatter that to the other spokes. So spoke routers wouldn’t know the other spokes, very similar to the way that the split horizon works, in fact. It isn’t technically talked about, a split horizon. But the fact remains, the topology is hurting us in basically the same way. It’s also possible that our provider could be giving us an erroneous mapping, an extra DLCI, fact on some CCIE labs they will do that. But we want to put this in, I like it. I don’t like to do things extra, but this is one of those things, it’s just like the right thing to do. So let’s walk you through this command. It’s a long command, it’s a great command to know. In fact, we’ll teach you some other things too.
HQ(router-if) #frame-relay map ip 10.1.1.2 100 broadcast
Branch(router-if)#frame-relay map ip 10.1.1.1 200 broadcast
So we do frame-relay map ip, frame-relay map ip, let’s talk about that for structure. Frame Relay says, “Hey, I want to do something with Frame Relay”, it demands the encapsulation frame-relay command to be on. Map says, “I’m going to tell you how to map Layer 2 of the DLCI to the Layer 3 of something else.” IP says, “IPv4.” Then we marry the IPv4 address of the far side. Far side IP address – local DLCI. It’s exactly what goes on here, far side IP address. This is not our IP address, the router knows that. The router doesn’t necessarily know what IP address it gets to when it crosses, okay.
Now that’s the core command. Broadcast tacked onto it says the pseudobroadcast that we were talking about, pseudobroadcast, okay. That’s an interesting word, you know, good luck spelling pseudobroadcast, but any case, there’s a reason why we do that. If we want our dynamic routing protocol to be able to work without doing things like manually specifying neighbors, you’ve got to do that broadcast command, so it’s the right thing to do.
Wait, my dynamic routing protocols don’t use broadcast. So to form neighbor adjacencies, they use multicast.
Oh yeah, okay, so that’s a great point. The thing is though the pseudobroadcast functionality kills two birds with one stone, not like we want to be killing birds, but reality is that it’s also going to be affecting the multicast functionality also.
So if you’re ever looking at a topology, you’re looking at frame-relay map statements and for some reason, routing is not working or neighborships aren’t being formed, remember broadcast. That’s why we do it, to support our dynamic routing protocols. So it supports broadcast capabilities as well as multicasting over that PVC.
Point-to-point Frame Relay Configuration
So let’s set up a point-to-point configuration here. Notice the topology hub-and-spoke. Notice we have subinterfaces on HQ – 0.110, 0.120. Notice the DLCIs associated for those interfaces. Just look at the topology right now and not the config, just get an idea of what’s happening here on HQ.
Let’s go down to the config now. Main interface no ip address, we’re not using the main interface here. But we do have to define our encapsulation method on that main interface and what is it? It’s Frame Relay. And then we define our subinterfaces now, serial 0.110, it’s point-to-point. We have to define it as a point-to-point subinterface because we can also have multipoint subinterfaces, which we’ll see shortly. IP address is associated with those specific subinterfaces, bandwidth parameters, all right. Nothing overly special so far, except for the fact that we’ve defined the encapsulation method on that main interface and we defined our point-to-point, nothing else, it’s pretty straightforward. But now we see this command frame-relay interface-dlci. Okay that’s new, that is definitely new, we have not seen that.
HQ(router)#interface Serial0/0/0
HQ(router-if)#no ip address
HQ(router-if)#encapsulation frame-relay
HQ(router-if)#interface Serial0/0/0.110 point-to-point
HQ(router-subif)#ip address 10.1.1.1 255.255.255.252
HQ(router-subif)#bandwidth 64
HQ(router-subif)#frame-relay interface-dlci 110
HQ(router-subif)#interface Serial0/0/0.120 point-to-point
HQ(router-subif)#ip address 10.1.1.5 255.255.255.252
HQ(router-subif)#bandwidth 64
HQ(router-subif)#frame-relay interface-dlci 120
I want you to think that this is really similar to the frame-relay map command, it’s not the same though, but I want you to think about a challenge that we have. The challenge is this, LMI gives us our DLCIs, we’ve established that, right? LMI gives us our DLCIs. Here’s the problem though, they kind of wash up on the physical interface. The router is not capable nor should it be capable of then reallocating those dynamically to the subinterfaces that we’re creating, it’s not going to be able to do that, it doesn’t know which DLCI that subinterface is built for until you tell it. So then we marry the PVC that maps to DLCI 110, to the subnet of 10.1.1.1 with a /30 mask, we marry those two together here. And frame-relay interface-dlci is what marries that DLCI to that subinterface. Absolutely critical command. Now could you put in frame-relay map ip? No, surprisingly not. Here’s why because we don’t need Layer 2 resolution in a point-to-point scenario just like with PPP and HDLC, we didn’t have that challenge because it’s point-to-point. If you know you have to send to the other side of that subnet, something else in that subnet, you just launch it and you hope it gets there, so there’s no frame-relay map command in this case. Now I want you to see something, we’ve got a convention here, you should be mindful of this convention, we’ve mapped the subinterface ID to the DLCI. It’s not a requirement whatsoever, so why do we do it? For administrative purposes. Think about this, you’re looking at the output and you see serial 0/0/0.110. Do you have to guess which DLCI is supposed to be associated with that? No, it should be 110 because you have made it that way, it’s not a requirement, but we do it to keep ourselves straight.
Now I would ask you how many PVCs is this router terminating? Two. Two PVCs, one for each subinterface.
So you’re going to build out, if you’re terminating three PVCs with three DLCIs, you’d have three subinterfaces. You’d figure out what subnet goes with them and then you’d follow this configuration to its completion. And we can see that the next PVC with DLCI 120 is in a different subnet, our block size is four.
So that was HQ’s config. What about BR1 and BR2? Pretty similar, except, make sure you associate the proper DLCI with your subinterface. So in this case, BR1 is using 110 for that PVC and BR2 is using 210.
BR1(router)#interface Serial0/0/0
BR1(router-if)#no ip address
BR1(router-if)#encapsulation frame-relay
BR1(router-if)#interface Serial0/0/0.110 point-to-point
BR1(router-subif)#ip address 10.1.1.2 255.255.255.252
BR1(router-subif)#bandwidth 64
BR1(router-subif)#frame-relay interface-dlci 110
BR2(router)#interface Serial0/0/0
BR2(router-if)#no ip address
BR2(router-if)#encapsulation frame-relay
BR2(router-if)#interface Serial0/0/0.210 point-to-point
BR2(router-subif)#ip address 10.1.1.6 255.255.255.252
BR2(router-subif)#bandwidth 64
BR2(router-subif)#frame-relay interface-dlci 210
Let’s get real for a moment here. Now we’re at a place where there is only one PVC being terminated, on the spoke routers that’s the case. Would you have been able to make this work in the major interface? It’s kind of a yes and no answer. I want you to think that if you do use one kind of subinterface, you want to be consistent here on both sides of that PVC and the big reason why is because routing protocols interpolate that. They look at the kind of subinterface you have and that controls the way that they’re going to work, OSPF is the biggest offender of this. So you don’t want a multipoint on one side of a neighborship and point-to-point on the other, that’s a recipe for disaster. Okay, you want those two to match. But ultimately, this is a great config, you would be able to change the things like DLCIs, change your IP addressing, you would be able to apply this to your own environment and work like a champ. No split horizon because we’ve broken it apart into subinterfaces on the headquarters’ side.
Multipoint Frame Relay Configuration
The point-to-point config is really superior. Multipoint, on the other hand, is a reality for some and I personally do like it. I like it because I’ll have to configure loads and loads of subinterfaces. So if I’m setting up a laboratory, for instance, I’m probably going to go with multipoint and just make that work from here. Now in this case, we’ve done a very similar config.
Let’s walk you through syntactically and then let’s talk about some of the consequences as well. We’ve gone into serial interface, no ip address there because we want to put it all on the subinterfaces. We turn on encapsulation frame-relay because you can’t even say what kind of subinterface it is until Frame Relay is your encapsulation type. Then you configure the subinterface, the multipoint subinterface.
HQ(router)#interface Serial0/0/0
HQ(router-if)#no ip address
HQ(router-if)#encapsulation frame-relay
HQ(router-if)#interface Serial0/0/0.1 multipoint
HQ(router-subif)#ip address 10.1.1.1 255.255.255.0
HQ(router-subif)#bandwidth 64
HQ(router-subif)#frame-relay map ip 10.1.1.2 110 broadcast
HQ(router-subif)#frame-relay map ip 10.1.1.3 120 broadcast
Now remember how this works, multiple PVCs in the same subnet. Two PVCs, in this case, so you choose the subnet, you choose the host portion allocated appropriately, and I want you to notice, are these three routers in the same subnet? They are, .1, .2, .3 on the same subnet, looks good, chosen a bandwidth of 64. The reality here is you would want to have the aggregate committed information rate, or CIR, bandwidth, like you take the two CIRs, add them together on the hub router. There is more to it than that, but that would be the appropriate thing to do just if you’re winging a config and you’re not following some white paper. Then you map to the far side IP addresses. Remember, the local DLCI to far side IP address, so DLCI 110 on my router takes me to .2, 120 on my router takes me to .3. Notice that we’re not putting in like 210 to get to .3, that’s what we were teaching you.
Okay, now here’s the reality. This would be an okay config if we had to mix and match subinterface types. And that is, in fact, sometimes the real-world case, multipoint in some and point to point on others. If you are going to just stick with multipoint behavior, you’re, in fact, better off with it done on the major interface. If that’s the case, you’d have the split horizon issue. If you do it on the major interface, Cisco helps you and turns off split horizon for you. Okay, so are we getting any benefit from putting it on multipoint? No. But we’re teaching you the syntax and if you have a hybrid, multipoint in some, point-to-point in other, then this could work out to your benefit.
So let’s look at that multipoint config on the main interface, but we’ll do it on BR1 and BR2. It’s looking pretty similar, isn’t it? Take a good look at that, interface Serial0/0/0, main interface, encapsulation frame-relay, ip address, is it in the same subnet as HQ? Yeah it’s also in the same subnet as BR2 as well, it’s bandwidth parameter. But what I really want to focus on here is the Frame Relay map statements at BR1 and BR2. Wow! Two Frame Relay map statements on BR1 and two Frame Relay map statements on BR2, let’s see who are they pointing to. BR1 – Let’s look at the first Frame Relay map statement, it says DLCI 110, right? That’s on our local DLCI and it’s pointing to 10.1.1.1, who is that? It’s HQ.
BR1(router)#interface Serial0/0/0
BR1(router-if)#encapsulation frame-relay
BR1(router-subif)#ip address 10.1.1.2 255.255.255.0
BR1(router-subif)#bandwidth 64
BR1(router-subif)#frame-relay map ip 10.1.1.1 110 broadcast
BR1(router-subif)#frame-relay map ip 10.1.1.3 110
BR2(router)#interface Serial0/0/0
BR2(router-if)#encapsulation frame-relay
BR2(router-subif)#ip address 10.1.1.3 255.255.255.0
BR2(router-subif)#bandwidth 64
BR2(router-subif)#frame-relay map ip 10.1.1.1 210 broadcast
BR2(router-subif)#frame-relay map ip 10.1.1.2 210
Look at the next Frame Relay map statement, DLCI 110 as well, but now it’s pointing to 10.1.1.3, but it’s using the same DLCI. This can cause some confusion here, what are we trying to do on BR1 with these two Frame Relay map statements? One is pointing to HQ, one is pointing to BR2, but they’re using the same DLCI.
So who is confused? Not the router, router understands this, it’s us that’s confused. What this means is, hey, I can get to both IP addresses if I launch traffic out of my local DLCI of 110. Remember what we taught you? If we don’t have a direct connection, we’re going to have to go through our local PVC to get to the hub and then the hub will bounce our traffic out at different PVC to get there, which is exactly what we we’re configuring our devices to do. We’re going to send it to 110, it’s going to go to HQ, HQ bounces it off of its DLCI 120 over to the other device assuming we’re going from the BR1 to BR2, okay?
So this is a great config and I’m also noticing something that’s really elegant here. I want you to notice the absence of the broadcast keyword on the second map statement, and frankly, I’m impressed. I’m impressed because lay people and even experts will put in a broadcast keyword twice for the same DLCI. So it’s extra, it makes the router work just a little bit extra, and if you want to show your skills, you never put on the broadcast keyword more than once on a DLCI, otherwise you generate some extra traffic and it can be seen with a debug.
Folks, think about what the broadcast keyword is for, for that pseudo broadcast. What did we state earlier? Make sure the broadcast keyword is specified if you want to form neighbor adjacencies, EIGRP, OSPF, so you want to support multicast and broadcast traffic on that PVC. Just think about it from a dynamic routing protocol perspective. Is BR1 going to form a neighbor adjacency with BR2? Never, never, we don’t have a PVC to BR2, we only have it to HQ. So from a dynamic routing protocol perspective, what’s the use to sending an additional multicast out 110 hoping that it gets to 10.1.1.3? We don’t need to, but we only need to send that multicast out DLCI 110 to get to 10.1.1.1. We don’t need it to get to BR2, that’s from a dynamic routing protocol perspective.
But remember that pseudo broadcast where we make a copy of that broadcast and send it down each PVC. Well if I put the broadcast keyword here for the same DLCI multiple times, we make a copy and then we’d send that copy down the same PVC, wasting resources, wasting traffic. So as we said, very elegant, only put it where it’s absolutely necessary, that broadcast keyword.
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
