Posts Tagged ‘Frame-relay’

INE 10 day bootcamp – Review

September 4, 2012 10 comments

I’m back from London and it’s been a great experience. Many readers are interested in what
the bootcamp is like. It is a big investment to go for so it is understandable that you
want to know if it will be worth it. I’ll start by describing the teacher and his teaching

Brian Dennis is a well known and respected man in the network industry. He is CCIE #2210
and has 5x CCIEs. That is among the very best in the world. Brian is not one of those
academic guys that only knows what is written in a book. He as a solid background in the
industry which means he can explain WHY things are the way they are and not just stating
facts without any reasoning behind it. There will be NO powerpoints, it is CLI only and
although he has a topology he is using the configurations are not prebuilt. He will do
them live which means there will be issues, which is GOOD. You get to see a 5x CCIE
troubleshooting and since he hasn’t prepared the faults before you will see how he would
troubleshoot a live problem which is very good practice for the TS lab in the CCIE lab.
Brian is a strong believer in that there are no tips and tricks. If you have an
instructor teaching you all these tips and tricks then that instructor is a fake.
If you know the technology there are no tips and tricks. Sure he can teach you some
useful commands but there are no tips and tricks in routing protocols.

Jeremy Brown is the bootcamp coordinator. He’s a very nice guy and he will help you
with any queries you have about the bootcamp. If you are attending you will be
talking to him for sure.

When you start the class the first day you will be handed a folder with paper and
a pen and some contact information. Brian will introduce himself and give some
general guidelines and explain how the real lab works with TS section and
configuration section etc. Then everyone gets to introduce themselves. My class
had a lot of nationalities, Bolivia, France, Venezuela, Sweden, UK, Ireland,
Norway, Hungary were all represented.

The bootcamp runs from 9 AM in the morning to about 19-20 PM in the evening.
There will be some 15 minute breaks and a lunch break for 1.5h. It is long
days indeed so make sure to get enough sleep in the evening. This is a pure
learning experience, leave the partying for another time. If you want to
have some fun there will be time in the weekend for that.

The first day is about layer two. Since the configuration is built from
scratch it makes sense to start out with layer two. The topology used
is based on Cisco 360 with 5 routers and 4 switches. The routers are ISR
routers and the switches are 3560’s. It is good that this topology is
used since that is very similar to what is being used in the real lab.
When attending the bootcamp you are expected to have a good knowledge
of protocols and that you have watched the INE ATC videos. This is so
that you don’t get overwhelmed by the information in the bootcamp.
The layer two section focused on MST, PPP and frame relay and
spanning tree features like BPDU guard, BPDU filter etc. One advice
that Brian gave is to try to mix in things like PPP, PPPoE, PPPoFR
etc in your labs so that you get used to using these technologies.

Later in the week we moved on to IGPs. OSPF will be the main topic.
This is natural since OSPF will guaranteed be in your lab and you
REALLY need to know OSPF to pass the lab. Brian is an OSPF
machine, he knows the LSDB like the back of his hand. He is very
methodical and will confirm each step and show you in the LSDB
what we are seeing and why we are seeing it. He’s not one of
those guys that clears the routing table when he runs into a
glitch, he will explain how and why it is there. He had a very
good section about the forwarding address, this is an important
part of OSPF and Brian explained why it is used. He had a very
good analogy with BGP where basically if the FA is not set then
you are using next-hop-self and if it is set then the next-hop
is preserved. He also had a good explanation of the capability
transit feature and he did some great diagrams showing which
LSAs go where. This is basic knowledge but he put it so well in
that diagram. We also talked about virtual links and things like
that. One good command he showed was the show ip ospf rib
command. EIGRP and RIP will be shorter sections, he will only
show some more advanced configuration since these protocols are
a bit simpler to understand. For EIGRP he showed hot do do
unequal cost load balancing and how to calculate the metric
if you want to get a certain ratio. He showed how to do
offset-list, leak maps and authentication.

After we were done with IGPs we moved on to route redistribution.
This topic alone is enough to provide a good bootcamp experience.
Brian will in detail explain the difference between control plane
and data plane loops and why loops can occur. The important thing
to remember is that we are trying to protect the routes with a
high AD from being learned in a protocol with a lower AD. Usually
RIP is involved or EIGRP external routes since those have a high
AD. Brian will show you how to take any INE Vol2 lab topology
diagram and just look at it and identify potential issues.
This is a very good practice and when you can look at a diagram
and know what to do without even thinking about configuration
yet then you are in a good place. Brian will with his diagrams
show you where every command lives like the OSPF LSDB, OSPF RIB,
RIB, FIB etc. This is very good practice to make sure you have
a full understanding of what is going on.

BGP is of course an important topic and Brian is covering that
for sure. Brian starts by describing peering and goes through
some common misconceptions. BGP has no authentication,
wait for it…TCP has, this is a common misconception. It is
TCP providing the authentication of packets and not BGP.
He will explain concepts like hot potato vs cold potato routing.
He will show you the difference between disable-connected-check and
ebgp-multihop. He will teach you about route reflectors and
confederations and why you want to use the one or the other.
He will also explain MED in detail, something I found very useful,
explaining how deterministic MED works and always-compare-med.
He has such knowledge of everything and one thing I didn’t know
before is that networks in the BGP table are sorted by age where
the youngest network is listed first.

Building on BGP means MPLS comes naturally. These go hand in
hand and for the v4 CCIE lab you need to know MPLS. Brian
will of course explain the use of RD and RT. Remember that RD
only has a use in BGP. He shows where all the commands and
routes live and how to do troubleshooting for MPLS. The good
thing is that you will run into things that you didn’t maybe
think about and that will provide great troubleshooting. OSPF
is the most complicated PE-CE protocol and he will give you all
the details how to use Domain-ID, sham links and how the
external route tag and DN bit works.

First week is over. Time for some recovery. Have some fun and
go for some sightseeing or just do labs, the choice is yours.
Just make sure that you are well rested for when monday comes.

The second week started out with multicast. This was maybe my
favourite topic and I learned a lot from this section.
As I mentioned earlier Brian doesn’t believe in tips and tricks
and multicast is one of those topics where people have a lack
of understanding and that is why they go looking for tricks.
Multicast is 90% about PIM, you need to know PIM if you want
to be good with multicast. Brian shows common errors like having
a broken SPT or RPF failures and things like that. These usually
occur when hub and spoke frame relay is involved. With just a
few commands you can become very good with analyzing multicast.
Show ip pim interface, show ip pim neighbor,
show ip rpf x.x.x.x and show ip pim rp mapping will give you most
of the information you will need. The best thing about the
multicast section was that when we ran into errors Brian was very
methodical, instead of just pinging over and over he showed us
what was wrong and then cleared the mroute table, this will
make the mtree build again so that you always go back to a
well known state. It is probably common to have the correct
configuration but move away from it due to lack of patience
or lack of understanding of what is really going on.

Time for the killer topic, probably the most hated topic in
the entire blueprint for most candidates. You guessed it, it is
time for PfR. Where does this hate come from? Well it comes
from the fact that the 12.4 implementation of PfR is just so
incredibly bad. If I were to select one topic that is difficult
to study on your own and that you can really benefit from going
to a bootcamp then that would be PfR. Brian starts out with some
basic topologies and then moves on to some more advanced scenarios.
This topic runs for one day or even a bit more. You WILL run into
a lot of issues due to the implementation of PfR in 12.4. If you
have seen the PfR Vseminar then this will be a lot like that
with the added benefit that you can ask Brian questions of course.

The next big topic is QoS. Brian goes through frame relay
traffic shaping using both legacy syntax and MQC. He will go
through how to use policing and shaping. The coolest thing
about this part was how we configured values for policing
like Bc and then Brian showed by sending ICMP packets how the
token buckets are really working. You might be in for some
surprises here! No powerpoints here for sure! He will explain
the difference between single rate and dual rate policers and
why you would configure them for which scenarios. Then he will
go through the Catalyst QoS. This is a confusing section for
many since the Catalyst QoS is a bit convoluted. Brian shows
how the L2 QoS is very similar to MQC but the syntax is just
a bit strange. He shows how to use the priority queue and how
to use the share and shape queues for the SRR queues.

Whatever time is left will be spent on topics like EEM and
services that you would like to go through. If you feel that
you are weak in some service then this would be a good time to
ask Brian to go through it. I left the bootcamp at 3 PM on
friday and I probably missed a couple of hours in the end.
If you can find a later flight or go home on saturday that
could be a good option.

So now you have gone through a wall of text and you are
whondering what I think about it? Well if it wasn’t obvious
from my text then Yes! Go for it! Yes it costs to go and
with everything to account for like living expense and hotel,
yes it is costly. However if you look just at the price for the
bootcamp which is around 5990$. That is actually a good price,
if you consider that you can get 1500$ paid for your lab then
the cost is actually 4500$ Where I live one week of training
at Global Knowledge is usually around 3000$ for a week and
then often you get some Power Point guy reading slides or you
doing labs while the instructor is watching. The one thing I
found best about the bootcamp was that you learn how to think
at a higher level. Being a CCIE is not about knowing a lot of
commands, it is about thinking at a high level. You get to pick
the brain of a 5x CCIE with real world experience, you won’t
find many guys like that in the world and from what I’ve seen
I would rank Brian among the very best of them. The IGP, Multicast,
Redistribution, PfR sections were very good and you will learn a lot
for sure even if you were strong in these areas before.

Hopefully in class you will meet some new friends. I met some
people people in class I had only seen online before and also made
some new friends. I had a great time with David Rothera, Gian Paolo,
Jose Leitao, Susana and Harald. I also met Darren
for the first time, we have known each other online for a while now
but never met. I also had the chance to meet Patrick Barnes which is
another of my online friends 🙂

I’ve tried to cover as much as I can remember but always feel free
to ask questions in the comments section if you have anything you are
still thinking about.

Frame-relay multilink (MFR) and MLPPPoFR

February 9, 2012 Leave a comment

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.

Blueprint – sample frame-relay task

February 7, 2012 12 comments

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.

Frame-relay IPv6 speed drill

December 13, 2011 4 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.

IPv6 over frame relay

May 11, 2011 2 comments

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.


interface Serial0/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1::1/64
frame-relay map ipv6 2001:CC1E:1:1::2 102
frame-relay map ipv6 2001:CC1E:1:1::3 103

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.

interface Serial0/0
encapsulation frame-relay
frame-relay interface-dlci 201

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
static mapping.

interface Serial0/0
encapsulation frame-relay
interface Serial0/0.301 multipoint
ipv6 add 2001:CC1E:1:1::3/64
frame-relay map ipv6 2001:CC1E:1:1::1 301

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.

R1#sh ipv6 int brief
FastEthernet0/0 [administratively down/down]
Serial0/0 [up/up]

The link-local address is calculated based on the MAC address.

R1#sh int | i bia
Hardware is Gt96k FE, address is c201.08e0.0000 (bia c201.08e0.0000)
Hardware is Gt96k FE, address is c201.08e0.0001 (bia c201.08e0.0001)

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.

R1(config)#int s0/0
R1(config-if)#ipv6 add FE80::1 link-local

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.


R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:10:1::1/64


R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:11:1::2/64


R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:12:1::3/64

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.


R1(config)#ipv6 unicast-routing
R1(config)#router bgp 100
R1(config-router)#nei 2001:CC1E:1:1::2 remote-as 100
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#neighbor 2001:CC1E:1:1::2 activate
R1(config-router-af)#network 2001:CC1E:10:1::/64
R1(config-router)#bgp router-id

Notice that we need to set a router-ID because we have no IPv6 addresses
configured on the routers.


R2(config)#ipv6 unicast-routing
R2(config)#router bgp 100
R2(config-router)#bgp router-id
R2(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#nei 2001:CC1E:1:1::1 activate
R2(config-router-af)#network 2001:CC1E:11:1::/64

The session comes up and we receive one prefix.

*Mar 1 10:12:46.853: %BGP-5-ADJCHANGE: neighbor 2001:CC1E:1:1::2 Up
R1#sh bgp ipv6 uni sum
BGP router identifier, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 304 bytes of memory
2 path entries using 152 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 860 total bytes of memory
BGP activity 3/1 prefixes, 3/1 paths, scan interval 60 secs
Neighbor                   V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
                                  4 100   8                8          3      0     0         00:04:03          1

Lets see if we have reachability.

R1#sh ipv6 route 2001:CC1E:11:1::/64
IPv6 Routing Table – 6 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
R1#ping 2001:CC1E:11:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:11:1::2, timeout is 2 seconds:

Indeed we do, now lets setup peering between R1 and R3.


R1(config-router)#nei 2001:CC1E:1:1::3 remote-as 300
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#nei 2001:CC1E:1:1::3 activate


R3(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R3(config-router)#address-family ipv6 unicast
R3(config-router-af)#nei 2001:CC1E:1:1::1 activate

Now lets look at the BGP table on R1.

R1#sh bgp ipv6 uni
BGP table version is 12, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network                                   Next Hop                         Metric    LocPrf    Weight    Path
*> 2001:CC1E:10:1::/64
                                                      ::                                   0                     32768       i
                                                                                            0        100           0           i
*> 2001:CC1E:12:1::/64
                                                                                            0                         0         300 i

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

R1#sh ipv6 route bgp
IPv6 Routing Table – 7 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
B 2001:CC1E:12:1::/64 [20/0]
via FE80::3, Serial0/0

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?

R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
Success rate is 0 percent (0/5)

No, we don’t. We don’t have a mapping for the link-local address. Debug frame-relay
packet should confirm this.

R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
*Mar 1 00:35:52.759: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:54.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:56.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:58.771: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:36:00.775: Serial0/0:Encaps failed–no map entry link 79(IPV6).
Success rate is 0 percent (0/5)

Indeed, there is no mapping. Lets configure this.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::3 103
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/37/88 ms

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.

A BGP speaker shall advertise to its peer in the Network Address of
Next Hop field the global IPv6 address of the next hop, potentially
followed by the link-local IPv6 address of the next hop.

We must announce the global next-hop and potentially a link-local one.

The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.

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.

As a consequence, a BGP speaker that advertises a route to an
internal peer may modify the Network Address of Next Hop field by
removing the link-local IPv6 address of the next hop.

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.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ipv6 ospf 1 area 0
R1(config)#ipv6 router ospf 1

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf 1 area 0
R2(config)#ipv6 router ospf 1

The peering won’t be successful, why? We turn off the route-cache and debug IPv6 packets.

R1(config)#int s0/0
R1(config-if)#no ip route-cache
R1#debug ipv6 packet
IPv6 unicast packet debugging is on
*Mar 1 08:59:20.181: IPV6: source FE80::2 (Serial0/0)
*Mar 1 08:59:20.185: dest FF02::5
*Mar 1 08:59:20.185: traffic class 224, flow 0x0, len 76+4, prot 89, hops 1, forward to ulp

Let’s try a ping to FF02::5 which is the destination address of IPv6 OSPF packets.

R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out
Success rate is 0 percent (0/5)
0 multicast replies and 0 errors.

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

R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping FF02::5
Output Interface:
*Mar 1 09:04:41.549: Serial0/0(i): dlci 102(0x1861), pkt type 0x86DD, datagramsize 80Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
*Mar 1 09:04:45.349: Serial0/0: broadcast search
*Mar 1 09:04:45.353: Serial0/0:encaps failed on broadcast for link 79(IPV6)
Request 0 timed out

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.

R1#sh run | i frame-relay map
frame-relay map ipv6 FE80::3 103
frame-relay map ipv6 2001:CC1E:1:1::3 103
frame-relay map ipv6 2001:CC1E:1:1::2 102

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.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::2 102
R1(config-if)#frame-relay map ipv6 2001:CC1E:1:1::2 102 broad

Can we ping FF02::5 now?

R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Reply to request 0 received from FE80::2, 40 ms
Reply to request 1 received from FE80::2, 52 ms
Reply to request 2 received from FE80::2, 96 ms
Reply to request 3 received from FE80::2, 40 ms
Reply to request 4 received from FE80::2, 128 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/71/128 ms
5 multicast replies and 0 errors.

Looking much better now. However, there is still no OSPF peering, why?

R1#sh ipv6 ospf interface
Serial0/0 is up, line protocol is up
Link Local Address FE80::1, Interface ID 6
Area 0, Process ID 1, Instance ID 0, Router ID
Network Type NON_BROADCAST, Cost: 64

R2#sh ipv6 ospf int
Serial0/0.201 is up, line protocol is up
Link Local Address FE80::2, Interface ID 14
Area 0, Process ID 1, Instance ID 0, Router ID
Network Type POINT_TO_POINT, Cost: 64

We have a mismatch in the network types. We will set both sides to broadcast.

R1(config)#int s0/0
R1(config-if)#ipv6 ospf network broadcast

R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf network broadcast

And finally we have a working peering.

*Mar 1 09:16:27.185: %OSPFv3-5-ADJCHG: Process 1, Nbr on Serial0/0.201 from LOADING to FULL, Loading Done

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.

Categories: Frame relay, IPv6 Tags: , ,

INE workbool vol1 labs 2.1 – 2.8

January 21, 2011 Leave a comment

Went through the frame-relay labs today. I have never used frame-relay in real life so although it wasn’t very difficult to configure I think I need to go through some videos and documentation to understand the details of inverse ARP and LMI. I know that LMI tells the DTE about the PVC’s available (DLCI’s) and that inverse ARP or static mappings is needed for the layer 3 to layer 2 resolution. I just need to work out which combos are available and how the DTE knows when using inverse ARP which DLCI to use when sending traffic out.

Update – computer crashed and frame-relay

October 14, 2010 Leave a comment

A week ago I had to send my laptop to service because it was behaving very badly. Also been really busy at work, implementing a new customer. I have done some studying, frame-relay is the topic right now. Although I recognize that the CCIE is a technology test and from that perspective frame-relay is a good technology to test I don’t really see the use for it. I live in Sweden and there is no frame-relay here, we have Ethernet and Gigabit links or faster pretty much everywhere and frame-relay just isn’t used any more. On the other hand frame-relay has some simularities with MPLS and I guess it’s never a bad thing to learn a technology and to have a feel for the history of networking. Are any of you still getting exposure to frame-relay?

Categories: Announcement Tags: