An Oldie But A Goodie: MLPPPoFR Configuration
- By Joe Astorino
- May 22, 2012
- 18 Comments
Introduction
“Alright this is an oldie…well an oldie where I come from” — Marty McFly
I ran into a situation today that got me thinking about getting the rust off and configuring MLPPPoFR (PPP Multilink over Frame-Relay for the uninitiated). I ordered a bundle of T1 lines for a remote site. Traditionally, the TELCO I have been using as of late has given me a straight up MLPPP handoff, but today I received an order confirmation, and they were referencing such fun terms as “PVC” and even assigned me a DLCI. Hmmmm…as is usual with the TELCO, not much is clear yet as far as how they want to terminate things, but I figured I’d be ready. I had not configured this in quite some time, so I quickly labbed things up and decided to share. It is probably fairly unlikely I would have to actually implement this…after all most things at the customer end are made to be dead simple, but it is always fun to tinker : )
For sake of brevity and laziness, I’m not going to even give you guys a network diagram today…yeah I know, I’m slipping. The topology is simple. We have R6 connected to R9 via two serial interfaces, s2/0 and s2/1. We will run MLPPP over Frame-Relay.
Understanding MLPPPoFR
Multilink PPP over frame-relay is really a mesh of a few different technologies. It is important to understand each of them individually, so that when we put them together, everything connects for you. It is easy to let this technology confuse you, and even more so if you don’t understand the individual pieces. So, what are the pieces? PPP over Frame-Relay and PPP Multilink (MLPPP). Let’s look at each individually, then look at combining them.
PPP over Frame-Relay
The first piece is understanding simple PPP over frame-relay. Forget about the bundling of circuits for a minute, and just think about what you would do to run plain PPP over frame-relay. From an OSI model standpoint, this is just having a frame-relay L2 header and frame-relay as a L2 transport mechanism, but instead of having IP directly on top of the frame-relay, the frame-relay carries PPP, which in turn carries IP (or your favorite routed protocol). Why would you want to do this? Most of the time for security reasons. PPP can run authentication protocols like PAP and CHAP to help secure things, while frame-relay on it’s own cannot accomplish this. If you wanted to run PPP over frame-relay it might look something like this
interface virtual-template 1 ip address 10.1.1.1 255.255.255.252 ! interface s0/0 encapsulation frame-relay no frame-relay inverse-arp no shutdown ! interface s0/0.101 point-to-point frame-relay interface-dlci 101 ppp virtual-template1 no shutdown
In this configuration, the virtual-template is really what is running PPP, and we logically link that template to the frame-relay PVC with DLCI number 101 by tagging on the “ppp virtual-template1” on to the end of the frame-relay interface-dlci command. What this says is basically “If I have packets that need to go out s0/0.101, encapsulate those IP packets into PPP, then encapsulate the PPP into frame-relay, and send it out DLCI 101”.
PPP Multilink (MLPPP)
The second piece to this puzzle is understanding PPP Multilink, or MLPPP. MLPPP takes multiple PPP links and bundles them into a single logical link. It would traditionally look something like this
interface multilink1 ip address 10.1.1.1 255.255.255.252 ppp multilink ppp multilink group 1 ! interface s0/0 encasulation ppp ppp multilink ppp multilink group 1 no shutdown ! interface s0/1 encasulation ppp ppp multilink ppp multilink group 1 no shutdown
Putting It Together: MLPPPoFR
Now we take these two technologies, combine them, and make a baby called MLPPPoFR. Here are the basic steps. Of course you can tweak the PPP part, the frame-relay part or both, but this is what you need at a bare minimum.
Actually, there are a few “gotcha” caveats to this configuration. First, realize I don’t actually have a frame-relay switch between these two routers…thus in reality this is really MLPPP over back-to-back frame-relay. Because there is no frame-relay switch, and because the frame-relay switch typically provides DLCI information via LMI, we must disable LMI via no keepalive and we must use the same DLCI on each side of the respective circuits. Simple enough. Also, I went ahead and added CHAP authentication for good measure to demonstrate the PPP capabilities here. One other thing to remember is that technically frame-relay traffic-shaping is required for this configuration, so you must enable it or the IOS will bark at you. Keep this in mind in potential real world rollouts because by default frame-relay traffic-shaping shapes your PVC to 56k. That could be a bad day at the office if misconfigured : )
First, we have our PPP multilink interface again. Again, we run IP on the logical PPP bundle here. Because the multilink bundle is running PPP, any PPP specific configurations would go here, including CHAP. Note that technically you could put your authentication on the virtual-template…either way works.
Next, we have a virtual-template interface. This is what we will use to bind the frame-relay interfaces to PPP, just like in plain PPPoFR.
Finally, we have the physical interfaces. This looks identical to the PPPoFR configuration — we link the DLCI to a virtual-template. The only real difference is that now the virtual-template itself is linked to a PPP multilink group. Remember, the virtual-template is just that — a template. For every DLCI you tie to the PPP side of the configuration by referencing virtual-template1, a separate dynamic virtual-access interface gets created. That is why you can reference the same virtual-template interface from two interfaces.
Here is the configuration for R6:
username R9 password cisco ! interface Multilink1 ip address 10.0.69.6 255.255.255.0 ppp authentication chap ppp multilink ppp multilink group 1 ! interface Virtual-Template1 no ip address ppp multilink ppp multilink group 1 ! interface Serial2/0 no ip address encapsulation frame-relay no keepalive serial restart-delay 0 frame-relay traffic-shaping frame-relay interface-dlci 69 ppp Virtual-Template1 no frame-relay inverse-arp ! interface Serial2/1 no ip address encapsulation frame-relay no keepalive serial restart-delay 0 frame-relay traffic-shaping frame-relay interface-dlci 96 ppp Virtual-Template1 no frame-relay inverse-arp
Here we have R9 at the other end:
interface Multilink1 ip address 10.0.69.9 255.255.255.0 ppp chap password 0 cisco ppp multilink ppp multilink group 1 ! interface Virtual-Template1 no ip address ppp multilink ppp multilink group 1 ! interface Serial2/0 no ip address encapsulation frame-relay no keepalive serial restart-delay 0 frame-relay traffic-shaping frame-relay interface-dlci 69 ppp Virtual-Template1 no frame-relay inverse-arp ! interface Serial2/1 no ip address encapsulation frame-relay no keepalive serial restart-delay 0 frame-relay traffic-shaping frame-relay interface-dlci 96 ppp Virtual-Template1 no frame-relay inverse-arp
Verification
R6#sh ip int brie | i Serial2\/[01]|Mu|Vi Serial2/0 unassigned YES NVRAM up up Serial2/1 unassigned YES NVRAM up up Multilink1 10.0.69.6 YES NVRAM up up Virtual-Access1 unassigned YES TFTP up up Virtual-Template1 unassigned YES NVRAM down down Virtual-Access2 unassigned YES TFTP up up Virtual-Access3 unassigned YES unset down down
That looks good..Notice that both serial links, the multilink, and two virtual-access interfaces are up/up but tha the virtual-template and virtual-access3 are down. Why? Virtual-template will always show down/down because it is just a placeholder. The configuration there essentially is cloned to the virtual-template interfaces when they come up. The virtual-template3 is down because we have “ppp multilink group 1” under the virtual-template interface so technically it is showing as an inactive member of the bundle but that’s OK and normal.
What about the PPP aspect of things?
R6#show ppp multilink
Multilink1
Bundle name: R9
Remote Username: R9
Remote Endpoint Discriminator: [1] R9
Local Username: R6
Local Endpoint Discriminator: [1] R6
Bundle up for 00:18:58, total bandwidth 56, load 1/255
Receive buffer limit 24000 bytes, frag timeout 3428 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x32 received sequence, 0x32 sent sequence
Member links: 2 active, 1 inactive (max not set, min not set)
Vi1, since 00:18:58
Vi2, since 00:18:58
Vt1 (inactive)
No inactive multilink interfaces
Looks great! We have 2 active links (the virtual-access interfaces). Can we ping?
R6#ping 10.0.69.9 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.69.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 128/262/688 ms
Aside from the dismal response times, we are good…but hey man for dynamips not too bad : )
Summary
MLPPP over Frame-Relay is truly a marriage of a couple different technologies — PPP, frame-relay, PPP over frame-relay, and PPP multilink. Like many things in network engineering, and the CCIE lab, understanding the individual technologies and how they work is key to understanding the more complex derivatives of those technologies. Hopefully this was helpful for you all. Until next time, keep studying hard boys and girls
Hi Joe,
Great post! I have a quick question. You mentioned that by default frame-relay traffic-shaping shapes your PVC to 56k. In your example above you haven’t configured a frame-relay map-class, so in that case are both PVCs shaped to 56k as a result?
Yes. See below for verification. If you configure FRTS and do not apply a map class all the DLCIs associated with the interface are shaped to 56Kbps by default.
R6#sh traffic-shape Interface Se2/0 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 69 56000 875 7000 0 125 875 - Interface Se2/1 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 96 56000 875 7000 0 125 875 -Thanks Joe.
One last question.. Why does the output of ‘show ppp multilink’ state ‘total bandwidth 56’?
Because the bandwidth of the multilink interface is 56Kbps. I don’t have time to research that right at the moment, but it is likely a result of the 56Kbps traffic shaping that is taking place.
Joe,
I have just discovered your blog, great work! I am shooting for the R&S title in January and been reading through your blog and picked up a few gems of knowledge. It is always good to get different perspective on things
All the best
Roger
UK
Roger,
Best of luck to you in January buddy!
Hi Joe,
Great article, thanks. Why does FRTS need to be enabled? I tried labbing this with a shaper on the Virtual interface and my verification looked OK. Am I going nuts? Does this look like it has worked to you?
Rack7R4#sh ppp multilink
Virtual-Access3
Bundle name: Rack7R5
Remote Endpoint Discriminator: [1] Rack7R5
Local Endpoint Discriminator: [1] Rack7R4
Bundle up for 00:25:35, total bandwidth 100000, load 1/255
Receive buffer limit 12192 bytes, frag timeout 1000 ms
Interleaving enabled
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0xB1 received sequence, 0x14C sent sequence
Member links: 1 (max not set, min not set)
Vi1, since 00:25:36, 125000 weight, 1496 frag size
No inactive multilink interfaces
Rack7R4#sh policy-map int virtual-access 3
Virtual-Access3
Service-policy output: SHAPER
Class-map: class-default (match-any)
229 packets, 80140 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 229/84442
shape (peak) cir 256000, bc 2560, be 2560
target shape rate 512000
Service-policy : MLPPP_LLQ
queue stats for all priority classes:
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: VOICE_BEARER (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Priority: 56 kbps, burst bytes 1500, b/w exceed drops: 0
Class-map: VOICE_SIGNALING (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth remaining 5% (10 kbps)
Class-map: class-default (match-any)
229 packets, 80140 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 229/84442
bandwidth remaining 95% (190 kbps)
HI Joe,
great post and easy to follow. I have one question though, why do you need to have two different DLCIs on the two serial links on the same router? Why can’t you just 69 on both interfaces?
thanks
interface Serial2/0
frame-relay interface-dlci 69 ppp Virtual-Template1
interface Serial2/1
frame-relay interface-dlci 96 ppp Virtual-Template1
You could use the same DLCI if you wanted, I just chose not to.
thanks for your response. I spent most of my day reading through your blog. Very nice posts and you explain the concepts really nicely.
Hi joe,
Great post. It makes sense to me this way but I have see implementation and indeed tested it without having to create the multilink interface, just adding the ppp multilink command under the virtual template does the trick. What is the difference in the two implementations?
interface Serial0/1/0
no ip address
encapsulation frame-relay
frame-relay class MLP
frame-relay traffic-shaping
frame-relay interface-dlci 204 ppp Virtual-Template1
frame-relay interface-dlci 205 ppp Virtual-Template1
frame-relay interface-dlci 206 ppp Virtual-Template1
frame-relay interface-dlci 214 ppp Virtual-Template1
frame-relay interface-dlci 215 ppp Virtual-Template1
frame-relay interface-dlci 216 ppp Virtual-Template1
frame-relay interface-dlci 224 ppp Virtual-Template1
frame-relay interface-dlci 225 ppp Virtual-Template1
frame-relay interface-dlci 226 ppp Virtual-Template1
no frame-relay inverse-arp
!
!
interface Virtual-Template1
bandwidth 128
ip address 1.1.1.1 255.255.255.0
ppp authentication chap
ppp multilink
ppp multilink links minimum 3 mandatory
!
Is it because in your case you’re bundling different physical interfaces and my example my pvc terminate on the same physical interface?
The other question i have is what happens if I don’t create the multilink at all in my example? As far as conncectivity is concerned it seems fine, I can still ping things. All of my interface-dlci command are referencing the same virtual-template 1 anyway. Thanks
Hey Fulvio,
That’s another way to do it.
HAAAA!!!!!! 4 hours on this man, 4 hours and the answer is “For some reason”, what “for some reason???????”
I am referring to lab 8 volume 3 ipexpert, where the connectivity is MLPPPoFR and we run OSPF over it, it’s your video in the solution and that is a quote from you.
They shouldn’t design lab like that as Cisco would put something in the lab that “for some reason” doesn’t work. Sorry.
Anyway in the last 4 hours I discovered that if you change the ospf type to point-to-multipoint, you do get the routes, bust still no connectivty, look at this:
O 191.100.5.200 [110/783] via 200.1.245.4, 00:00:46, Virtual-Access14
O 191.100.4.200 [110/783] via 200.1.245.4, 00:00:46, Virtual-Access14
O 191.100.11.200 [110/783] via 200.1.245.4, 00:00:46, Virtual-Access14
R2(config-if)#do sh ip ospf n
Neighbor ID Pri State Dead Time Address Interface
40.40.40.6 0 FULL/ – 00:01:51 200.1.245.6 Virtual-Access14
40.40.40.4 0 FULL/ – 00:01:34 200.1.245.4 Virtual-Access16
The routes are pointing at 200.1.245.4, 00:00:46, Virtual-Access14 but the adjacency on 14 is with 40.6, so no connecvity. Worth 4 hours of my revision time? I doubt it :-(
I have to say this but I am finding a big gap between INE and IPExpert, just my opinion.
Instead of putting the IP address on the virtual-template interface itself, try creating a loopback interface with the IP you had on the virtual-template and doing “ip unnumbered lo0” on the virtual-template.
This blog was not directly related to any IPexpert labs. I just do this for fun. If you want official support for IPexpert labs, you should really post on their Online Study List (OSL) form or contact support. I have not worked there in 3 years and am not affiliated with them. Also, you put 4 hours of troubleshooting into a task and you learned something — It’s time well spent. That is what you should be doing when studying for your CCIE. If I had a dollar for every time I spent hour after hour after hour debugging and questioning vendor workbook solutions during my CCIE prep I would be very rich. That is part of the journey.
Also, check out this link. Ultimately, you are going to want to have the virtual-template interface as ip unnumbered pointing to a loopback interface. That was also the solution in the lab you were mentioning. I believe it has to do with the fact that when you have the ip on the virtual-template itself you are really cloning a bunch of virtual-access interfaces that have the same IP address on them which can get confusing for the router. As you saw, you can end up sending traffic out the wrong place because routes get associated with the wrong virtual-access interfaces
http://cciepursuit.wordpress.com/2008/09/21/ios-error-with-ospf-point-to-multipoint-network-in-pppofr-hub-and-spoke-topology/
Thanks for reply Joe, I appreciate it. Yes using the loopback works. I’ll read what’s on the link you sent. Thanks
Hi Joe,
Have you quit blogging? We all miss your posts!!
Please come back!!!
Hai joe,
your explanations are quite easy to easy to understand…many thanks….