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.
So I’m going through the blueprint checking off everything before the lab. I know FR pretty well by now but there are always some details you forget. As I was going through FR again I thought about possible failure scenarios and restrictions that could be used at the lab. Here is a sample task I thought of.
Router R1 is running frame-relay on interface serial0/0. Via LMI 4 PVC’s have been learned, DLCI 102, 103, 104 and 105. Disable inverse ARP for all DCLI’s except 102. Do not use the no frame-relay inverse arp command. For this task you are allowed to create an additional interface.
Post solution in comments.
Going for the lab we need both speed and skills. I made a simple IPv6 frame-relay lab that should test your speed. Time yourself and post your time to configure in the comments. Just by looking at the time I could probably tell if you are typing manually or not. This is the scenario.
Routers R1, R2, R3 and R4 are connected to a frame-relay cloud. They are all spokes connecting to the hub R5. R1 has a DLCI 105 to R5 which is 501 from R5 POV. R2 has a DLCI that is 205 and 502 from R5 POV and so on. This is the task.
Configure all devices with a global address of 2001:1:0:1234::Y where Y is the device number.
Configure static mappings on all devices.
All devices should be able to ping each other.
Download the .net from here and then edit for your IOS version and working dir etc.
I didn’t time myself but I think I could do it in less than 2 minutes for sure. Later I will post some tips on how to improve speed.
This post will look at IPv6 over frame-relay and describe some of the small things
that differ compared to IPv4 and some gotchas.
We start out with the same topology as in my previous frame-relay post.
We configure routers R1, R2 and R3 to be in the subnet 2001:CC1E:1:1::/64.
Remember that the pool of global IPv6 unicast addresses comes from 2000::/3
which means that all today legit IPv6 addresses will start with a 2 or a 3.
I won’t say much about this config as this should be known to you if you read
my previous post on frame relay. We are using a physical interface so all DLCI’s
will be available to us. The first thing to notice about IPv6 over frame relay is that
there is no inverse ARP. This means that we need static mappings or the
frame-relay interface-dlci command on point-to-point interfaces.
We configure R2 and to mix things up a bit we use a point-to-point interface.
Since this is a point-to-point interface there is no need for static mappings.
R3 will use a multipoint interface but not the physical interface. We will use a
When we use IPv6 we always have a link-local address assigned to all IPv6 enbabled
interfaces. This can be seen with the show ipv6 interface brief command.
The link-local address is calculated based on the MAC address.
Our link-local address is based on the first MAC of this output. We want to use
an easier to remember address so we set the link local address to FE80::1 and
then the same on R2 and R3 but with ::2 and ::3.
Now it is time to do some routing. We start out with BGP. Knowing BGP is of
course a must when you are studying for the CCIE and the difference between
IPv4 and IPv6 is not that great. We need networks to announce so we create
some loopbacks on the routers.
Don’t you just love being able to have IP addresses with CCIE in them?
Time to setup BGP. We will be using AS 100 for R1 and R2. R3 will be in AS 300.
Notice that we need to set a router-ID because we have no IPv6 addresses
configured on the routers.
The session comes up and we receive one prefix.
Lets see if we have reachability.
Indeed we do, now lets setup peering between R1 and R3.
Now lets look at the BGP table on R1.
We can see R3′s loopback, nothing weird, yet…We have a next-hop of
2001:CC1E:1:1::3 which is expected. Now look at the show ipv6 route bgp
The route to 2001:CC1E:12:1::/64 has been resolved to a next-hop of FE80::3.
Do we have reachability to this network?
No, we don’t. We don’t have a mapping for the link-local address. Debug frame-relay
packet should confirm this.
Indeed, there is no mapping. Lets configure this.
Success, but the question still is why do we have a link-local next-hop for
R3′s loopback interface? RFC 2545 – Use of BGP-4 Multiprotocol extensions
for IPv6 Inter-Domain Routing gives us a hint.
We must announce the global next-hop and potentially a link-local one.
If the BGP peers share a common subnet the link-local address shall be included.
Why doesn’t the route to R2′s loopback have a link-local next-hop?
Once again, RFC 2545 gives us the answer.
If announcing to an internal peer, we may modify the next-hop by removing the
link-local address. R1 and R2 are in the same AS so they are internal peers.
Now we have seen how BGP works, what about IGPs? Lets try to configure
OSPF between R1 and R2.
The peering won’t be successful, why? We turn off the route-cache and debug IPv6 packets.
Let’s try a ping to FF02::5 which is the destination address of IPv6 OSPF packets.
No success, we can see that the packets are source from FE80::2 which must
be mapped. Also, we must have broadcast capability on one PVC, does it matter
which one? This is output from debug frame-relay packet when doing a ping to FF02::5
This shows us clearly that we have no broadcast capability. Lets look at what
frame-relay mappings we have, R2 is point-to-point only so no need for mappings there.
We don’t have a mapping for R2′s link-local address. We will need that and we
will also need broadcast capability for the PVC. To prove that we can add the
brodcast capability by configuring a map for the global address I will configure that.
Can we ping FF02::5 now?
Looking much better now. However, there is still no OSPF peering, why?
We have a mismatch in the network types. We will set both sides to broadcast.
And finally we have a working peering.
I hope this post has cleared some misconceptions about IPv6 over frame relay.
If you have any questions please post them in the comments section.
You can find the final configs for this lab here. You can find the topology for GNS3
in my earlier post on frame-relay.