Frame-relay multilink (MFR) and MLPPPoFR

These topics are probably not very likely to appear at lab but it still good to at least have seen them once so you don’t get stumped if you should get a task like that at the lab.

Frame relay multilink (MFR) is defined in FRF.16.1 as defined by The Frame Relay Forum. See this URL for complete specification.

The basic idea is to take several frame-relay interfaces with the same DLCI and bundle them into one logical interface. Kind of like an Etherchannel. The reason I write this post is that the DOCCD isn’t really intuitive for this topic and there does not seem to be a lot of documentation how to configure this rather simple feature.

I will be using a simple topology where router R1 is dually connected to R2 and R3 is also dually connected to R2. R2 will be acting as the frame switch, we could have used a separate frame switch in Dynamips but this is a bit more fun and shows how to configure the SP side as well.

The configuration on the customer side is rather simple. First we create the logical interface which is named mfr and then a number. We will use number 1. All configuration like IP address and access-lists or anything like that goes to this interface.

Then we have to define which interfaces are part of the bundle. This is done with the encapsulation frame-relay mfr command.

Then we do the same thing on the other side but with a different IP address of course. Then we can verify that the link is up with show frame-relay multilink. We verify with a ping.

If you want to check that both links are being used then you can clear the counters and then do a ping. The number of packets should be equal or close to.

This is how a show frame pvc looks.

Note that the multilink interface is shown here instead of the physical interfaces. The MFR interface works the same way as a regular frame relay interface. Since I’m using a physical interface all DLCI’s will be mapped to it automatically and inverse ARP is used to resolve the remote layer 3 address to the local DLCI.

We also have the option of running the MFR interface on a subinterface, both as multipoint or point-to-point. Multipoint does not really make sense in this case but it can be done. The regular rules apply, if using multipoint we can either use a frame map statement or the frame-relay interface-dlci and rely on inverse ARP. For point-to-point interfaces we just use the frame-relay interface-dlci command as usual.

Now to the configuration of the FR switch. We enable frame-relay switching as usual. The configuration for the MFR is the same as for the customer side but we need to define that this interface is DCE and then we have the frame-relay route statements which map to the MFR interfaces instead of physical interfaces.

This is the configuration of R2.

Now we will look at MLPPPoFR which is another way of doing bundling of links by using PPP. First we start with the basic configuration. We bind the DLCI’s to the virtual template.

We do the same configuration on R2 and then we will configure the virtual-template to use multilink functionality.

You will see that several virtual-access have been created. We can verify with show ppp multilink command.

That is basically it. Now you know how to configure FRF.16 and MLPPPoFR.