Archive

Archive for the ‘Frame relay’ Category

OSPF – Non Broadcast and Point to Multipoint

May 4, 2014 2 comments

Introduction

There was a discussion on a forum about the point to multipoint network type in
OSPF. What is the purpose of it and why are /32 endpoints advertised? To understand
the solution we must first understand the problem. This topology has a NBMA network
where R1 is the hub. R1 has been elected the hub due to having the highest priority.

Topology

NBMA Networks

When using the network type non broadcast, which is the default for main interfaces
with frame relay enabled, a DR and BDR is elected. When using a hub and spoke
topology it is important that the hub is elected the DR. Why is this? If a
spoke is elected the DR the flooding process will fail. On broadcast and non broadcast
segments the DROTHERs flood the LSAs to the DR/BDR and then the DR floods them to
the other DROTHERs on the segment.

The routing has already been setup, R2 and R3 are advertising a loopback each, they
are 2.2.2.2/32 and 3.3.3.3/32 respectively. First we will have a look at the router
LSAs that are generated.

R2#sh ip ospf data router 3.3.3.3

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 118
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 3.3.3.3
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000006
  Checksum: 0x5849
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 3.3.3.3
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.0.1
     (Link Data) Router Interface address: 10.0.0.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

Interfaces that are connected and don’t have an OSPF adjacency are considered
stub networks. These are advertised with the network and the mask. There is
also a transit network that contains the IP of the DR and the local routers IP
for that network. Note that there is no network mask within this LSA.

If we have a look at the routing table of R2, the next-hop to reach 3.3.3.3/32
is 10.0.0.3.

R2#sh ip route 3.3.3.3                
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 10.0.0.3 on Serial1/0, 00:34:24 ago
  Routing Descriptor Blocks:
  * 10.0.0.3, from 3.3.3.3, 00:34:24 ago, via Serial1/0
      Route metric is 65, traffic share count is 1

On broadcast and non broadcast segments all routers are assumed to be fully
meshed but here we have a hub and spoke topology. When R2 needs to send traffic
to R3 it will try to encapsulate the frame but it does not know which DLCI to
use for 10.0.0.3 because there is no frame mapping for that.

R2#sh frame map
Serial1/0 (up): ip 10.0.0.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active

If we debug the sending of frame relay frames we will see that the encapsulation
is failing.

R2#debug frame-relay packet
Frame Relay packet debugging is on
R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

*Mar  1 00:42:30.495: Serial1/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 84
*Mar  1 00:42:32.303: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:34.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:36.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:38.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:40.299: Serial1/0:Encaps failed--no map entry link 7(IP).
Success rate is 0 percent (0/5)

The layer 3 topology is not consistent with the layer 2 topology. The layer 3 is
assumed to be fully meshed but our layer 2 is in fact hub and spoke.

The next-hop is not changed on broadcast and non broadcast segments because
all routers are assumed to be fully meshed.

Solving the Inconsistency

One way of solving the inconsistency is by adding static mappings for
the IP of R2 and R3 respectively to the correct DLCI.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#frame map ip 10.0.0.3 201
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s1/0
R3(config-if)#frame map ip 10.0.0.2 301
R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/51/76 ms

This solved our problem but requires manual intervention and if new routers are
added then new mappings would have to be added as well. Before we leave the
network type non-broadcast there is one more thing I would like to point out.

Network LSA

What is the role of the network LSA? It is twofold, it conveys both topology
information and reachability information. If we look at the network LSA that R1
generates.

R2#sh ip ospf data net 10.0.0.1

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 634
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.0.0.1 (address of Designated Router)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000003
  Checksum: 0x46C6
  Length: 36
  Network Mask: /24
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3

We see all of the attached routers and also the network mask for the segment.
This network LSA will be converted by R4 into a type3 summary LSA. If we look
from R5’s perspective we can see this prefix.

R5#sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets

O IA    10.0.0.0 [110/84] via 45.45.45.45, 00:45:27, FastEthernet0/0
R5#sh ip ospf data sum 10.0.0.0

            OSPF Router with ID (5.5.5.5) (Process ID 1)

                Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 831
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.0.0.0 (summary Network Number)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000002
  Checksum: 0x7364
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 74 

R5 can reach this network which is demonstrated by the ping.

R5#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/64/72 ms

What would happen if R2 or R3 became the DR instead of R1? Let’s try it out.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf prio 1
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#ip ospf prio 100
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s1/0
R3(config-if)#ip ospf prio 0

Then clear the process to see the effect.

The segment has now been split into two. R2 does not know about R3 so we have
a segment with R1 and R2 and then a segment with R1 and R3. This can be seen
from the neighbor table and from the network LSA that is generated.

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           1   FULL/DR         00:00:31    14.14.14.4      FastEthernet0/0
2.2.2.2         100   FULL/DR         00:01:44    10.0.0.2        Serial1/0
3.3.3.3           0   FULL/DROTHER    00:01:45    10.0.0.3        Serial1/0
R1#sh ip ospf data net 10.0.0.2

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 600
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.0.0.2 (address of Designated Router)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x43D6
  Length: 32
  Network Mask: /24
        Attached Router: 2.2.2.2
        Attached Router: 1.1.1.1

This also means that SPF can’t run properly because R3 is now not connected to
the topology because it’s not part of the network LSA for 10.0.0.0/24. This
means that R5 can’t ping R3.

R5#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

It can still reach R1 and R2 though.

R5#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/52/84 ms
R5#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/66/84 ms

So the network LSA is used both for building the SPF topology and for reachibility
information.

Point to Multipoint Network

There is a point to multipoint network type. This overcomes the limitations of
partially meshed networks by accomplishing two things. The first thing that happens
is that when a LSA is received on an interface, the next-hop is changed to IP of
the router LSA that the local router is connecting to. In our case this is 10.0.0.1.

R2#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 129, type intra area
  Last update from 10.0.0.1 on Serial1/0, 00:03:59 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 3.3.3.3, 00:03:59 ago, via Serial1/0
      Route metric is 129, traffic share count is 1
R2#sh ip ospf data router 1.1.1.1

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 483
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000018
  Checksum: 0x6E61
  Length: 72
  Number of Links: 4

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 14.14.14.4
     (Link Data) Router Interface address: 14.14.14.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 10.0.0.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.0.0.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.0.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

This is described in RFC 2328.

If the destination is a router which connects to the
calculating router via a Point-to-MultiPoint network, the
destination's next hop IP address(es) can be determined by
examining the destination's router-LSA: each link pointing
back to the calculating router and having a Link Data field
belonging to the Point-to-MultiPoint network provides an IP
address of the next hop router.

From the router LSA above you can see that each router in the point to multipoint
network advertises a stub network with a /32 mask. On point to multipoint segments
the network is described as a collection of point to point links. With a regular
point to point network the stub network is described with the actual mask of
the interface that is running OSPF. What is the use of these /32 routes?
First let’s test the reachability.

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/60/72 ms
R2#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/76 ms
R2#show ip route 10.0.0.3
Routing entry for 10.0.0.3/32
  Known via "ospf 1", distance 110, metric 128, type intra area
  Last update from 10.0.0.1 on Serial1/0, 00:12:41 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 3.3.3.3, 00:12:41 ago, via Serial1/0
      Route metric is 128, traffic share count is 1

Full reachability. What happens if we filter the /32 route to R3 on R2?

R2(config)#ip prefix-list DENY_R3 deny 10.0.0.3/32         
R2(config)#ip prefix-list DENY_R3 permit 0.0.0.0/0 le 32   
R2(config)#router ospf 1
R2(config-router)#distribute-list prefix DENY_R3 in

The host route to R3 is now gone. The route to R3 is known via the connected
network.

R2#show ip route 10.0.0.3
Routing entry for 10.0.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial1/0
      Route metric is 0, traffic share count is 1

What about reachability?

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/57/84 ms
R2#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The ping went through when we used the loopback as a source. That is because
R3 still has a host route to R2 in its routing table. We couldn’t ping 10.0.0.3
though? Why? Because without the host route pointing to a next-hop of 10.0.0.1,
R2 will try to see what DLCI to use when encapsulating the frame to 10.0.0.3
and there is no mapping for this. If we ping R2’s loopback from R3 sourcing
with the 10.0.0.3 IP, it will fail for the same reason.

R3#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Conclusion

OSPF has various network types that accomplish different things.
The point to multi point network type is used to overcome limitations at
layer 2. The network is described as a collection of point to point links
where each router advertises a stub network with a /32 mask. By doing this
the spokes can maintain connectivity between each other when sourcing traffic
from the interface connected to their common network.

The next-hop is also changed on incoming LSAs to the IP contained in the router
LSA from the router that originated the LSA. This solves the next hop issue
on non broadcast networks where the next hop is maintained because full mesh
connectivity is assumed.

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.

R1

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]
FE80::C001:8FF:FEE0:0
2001:CC1E:1:1::1

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

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

R2

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

R3

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

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-af)#exit
R1(config-router)#bgp router-id 1.1.1.1

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

R2

R2(config)#ipv6 unicast-routing
R2(config)#router bgp 100
R2(config-router)#bgp router-id 2.2.2.2
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 1.1.1.1, 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
2001:CC1E:1:1::2
                                  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

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

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 1.1.1.1
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
*>i2001:CC1E:11:1::/64
                                                     2001:CC1E:1:1::2
                                                                                            0        100           0           i
*> 2001:CC1E:12:1::/64
                                                     2001:CC1E:1:1::3
                                                                                            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
output.

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(config-if)#^Z
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
R1#

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
R1(config-rtr)#router-id 1.1.1.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-subif)#exit
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2

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(config-if)#^Z
R1#debug ipv6 packet
IPv6 unicast packet debugging is on
R1#
*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 1.1.1.1
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 2.2.2.2
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
R2(config-subif)#

And finally we have a working peering.

*Mar 1 09:16:27.185: %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 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: , ,