IPv6 and OSPFv3

By stretch | Monday, September 1, 2008 at 6:29 a.m. UTC

This short lab should provide some exposure to configuring OSPF for IPv6 under IOS. OSPFv3 is to IPv6 as OSPFv2 is to IPv4, and the two OSPF versions are not compatible with one another. The two protocols can be run simultaneously to support parallel (but separate) IPv6 and IPv4 routing domains, but the lab provided here will cover only OSPFv3.


IPv6 Addressing

The first step in base configuration is to enable IPv6 unicast routing:

R1(config)# ipv6 unicast-routing

Next we'll need to assign IPv6 addresses to the necessary interfaces. IPv6 stateless address autoconfiguration (RFC 4862) allows the interface ID portion of the address to be automatically formed from an EUI-64 address. We'll take advantage of this by appending the eui-64 keyword to the ipv6 address command and leaving the interface ID portion of the IPv6 address zeroed.

R1(config)# interface f0/1
R1(config-if)# ipv6 address 2001:db8:0:12::/64 eui-64

Although we could address our serial interfaces in the same manner, setting the interface ID manually makes it easier to define the static frame relay mappings. We'll also have create frame relay mappings for the link-local (FE80::/10) addresses, so we may as well manually specify the interface IDs of those addresses as well.

R1(config)# interface s1/0
R1(config-if)# ipv6 address 2001:db8::1/64
R1(config-if)# ipv6 address fe80::1 link-local

Creating IPv6 frame relay mappings is very similar to the commands issued for IPv4 addresses. The most important detail to remember is that link-local interface addresses must also be mapped, as all OSPFv3 communication takes places across these addresses.

R1(config-if)# encapsulation frame-relay
R1(config-if)# no frame-relay inverse-arp
R1(config-if)# frame-relay map ipv6 2001:db8::3 103
R1(config-if)# frame-relay map ipv6 2001:db8::2 103
R1(config-if)# frame-relay map ipv6 fe80::3 103 broadcast
R1(config-if)# frame-relay map ipv6 fe80::2 103

We can verify that each interface has both a link-local address and our configured global unicast address assigned:

R1# show ipv6 interface brief
FastEthernet0/1            [up/up]
Serial1/0                  [up/up]

Likewise, we can verify our frame relay mappings as we would with IPv4:

R1# show frame-relay map | include Serial1/0
Serial1/0 (up): ipv6 FE80::2 dlci 103(0x67,0x1870), static,
Serial1/0 (up): ipv6 FE80::3 dlci 103(0x67,0x1870), static,
Serial1/0 (up): ipv6 2001:DB8::2 dlci 103(0x67,0x1870), static,
Serial1/0 (up): ipv6 2001:DB8::3 dlci 103(0x67,0x1870), static,

Once all interfaces on routers have been addressed, it's a good idea to verify connectivity across individual links before moving onto OSPF configuration. You can ping global unicast IPv6 addresses just like IPv4 addresses, but notice that you are prompted for the outgoing interface when pinging a link-local address. This is because the router has no way of knowing which link you want to reach.

R1# ping fe80::2
Output Interface: serial1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::2, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/36 ms

Configuring OSPFv3

OSPFv3 differs from its predecessor in a number of ways, as we'll see in the following configurations. The first step, of course, is to enable the OSPF process:

R1(config)# ipv6 router ospf 1

If you have console logging enabled, you may notice this message pop up:

%OSPFv3-4-NORTRID: OSPFv3 process 1 could not pick a router-id,
please configure manually

Although OSPFv3 deals solely with IPv6 addresses, it still uses 32-bit router IDs, which are expressed in dotted-decimal (IPv4) format. Since we haven't configured any IPv4 interfaces in our lab, we'll need to define the OSPFv3 router IDs manually on each router:

R1(config-rtr)# router-id

Although formatted as an IPv4 address, the router ID is an arbitrary value used to identify an OSPF router to its neighbors.

Since the 2001:db8:0:3::/64 and 2001:db8:0:4::/64 subnets have no neighboring OSPFv3 routers, we'll designate the F0/1 interfaces on R3 and R4 as passive to protect against malicious or accidental adjacency formation.

R3(config-rtr)# passive-interface f0/1
R4(config-rtr)# passive-interface f0/1

Next we'll need to assign interfaces to OSPF areas. Unlike OSPFv2, which used the network command under the router process to assign subnets to areas, OSPFv3 area assignments are made under interface configuration.

R1(config)# interface s1/0
R1(config-if)# ipv6 ospf 1 area 0
R1(config-if)# interface f0/1
R1(config-if)# ipv6 ospf 1 area 1

Be sure to set the DR priorities appropriately for frame relay interfaces, to ensure that R3 (the multipoint hub) becomes the DR. You might also want to set the priorities for the other two frame relay routers to zero.

R3(config)# interface s1/0
R3(config-if)# ipv6 ospf priority 100

Since our frame relay cloud is a non-broadcast multiaccess (NBMA) link, we'll need to manually configure our OSPF neighbors on the hub. Like area assignment, this is done under interface configuration. Each neighbor must be listed with its link-local address.

R3(config-if)# ipv6 ospf neighbor fe80::1
R3(config-if)# ipv6 ospf neighbor fe80::2

Notice that the priority and neighbor configurations do not specify the OSPF process like the area assignments do; if multiple OSPFv3 processes are running, interface priority and neighbor configurations affect all of them.

Area configuration is still performed under the OSPF process. Here we'll configure area 2 as a stub since it has only one connection to the backbone. (This won't have any affect on our internal OSPF routes, but will cause the ABR R3 to inject a default route into the the area.) Be sure to apply the stub configuration to both routers 3 and 4.

R3(config)# ipv6 router ospf 1
R3(config-rtr)# area 2 stub
R4(config)# ipv6 router ospf 1
R4(config-rtr)# area 2 stub


If everything is configured properly, all routers should now have full reachability via IPv6. We can inspect a router's neighbor adjacencies with the show ipv6 ospf neighbor command:

R3# show ipv6 ospf neighbor

Neighbor ID   Pri   State          Dead Time  Interface ID  Interface         1   FULL/BDR       00:01:34   6             Serial1/0         1   FULL/DROTHER   00:01:44   6             Serial1/0         1   FULL/DR        00:00:33   4             FastEthernet0/0

Similarly, we can inspect the IPv6 routing table of R4 to verify it has received all OSPF routes, including the default route (::/0) injected into area 2 from R3.

R4# show ipv6 route
IPv6 Routing Table - 10 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
   U - Per-user Static route
   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
OI  ::/0 [110/11]
 via FE80::C003:48FF:FE10:0, FastEthernet0/0
OI  2001:DB8::/64 [110/74]
 via FE80::C003:48FF:FE10:0, FastEthernet0/0
O   2001:DB8:0:3::/64 [110/20]
 via FE80::C003:48FF:FE10:0, FastEthernet0/0
C   2001:DB8:0:4::/64 [0/0]
 via ::, FastEthernet0/1
L   2001:DB8:0:4:C004:48FF:FE10:1/128 [0/0]
 via ::, FastEthernet0/1
OI  2001:DB8:0:12::/64 [110/84]
 via FE80::C003:48FF:FE10:0, FastEthernet0/0
C   2001:DB8:0:34::/64 [0/0]
 via ::, FastEthernet0/0
L   2001:DB8:0:34:C004:48FF:FE10:0/128 [0/0]
 via ::, FastEthernet0/0
L   FE80::/10 [0/0]
 via ::, Null0
L   FF00::/8 [0/0]
 via ::, Null0

Beyond what was demonstrated here, you'll find the majority of OSPFv3 configuration commands are nearly identical to those of its predecessor. If you've configured OSPFv2 routing in the past and have a solid grasp of IPv6, OSPFv3 shouldn't give you any trouble.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in IPv6, Routing


Kevin (guest)
September 2, 2008 at 3:01 p.m. UTC

Missing some important configuration! R3 needs sub-interfaces!

September 2, 2008 at 3:09 p.m. UTC

@Kevin: The frame relay DLCIs aren't configured as individual point-to-point links; R3 only needs a single point-to-multipoint interface (the physical interface).

Kevin (guest)
September 2, 2008 at 3:47 p.m. UTC

Sorry Stretch, I guess the 3725s don't support!

September 2, 2008 at 4:11 p.m. UTC

It's not a matter of hardware support; in fact, I used 3725s in my lab as I was writing this. Read up on frame relay configuration. Here's the configuration on R3 for reference:

interface Serial1/0
 encapsulation frame-relay
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8::3/64
 ipv6 ospf priority 100
 ipv6 ospf neighbor FE80::2
 ipv6 ospf neighbor FE80::1
 ipv6 ospf 1 area 0
 frame-relay map ipv6 FE80::2 302 broadcast
 frame-relay map ipv6 2001:DB8::2 302 broadcast
 frame-relay map ipv6 2001:DB8::1 301 broadcast
 frame-relay map ipv6 FE80::1 301 broadcast
 no frame-relay inverse-arp

Ron (guest)
September 2, 2008 at 5:11 p.m. UTC

Stretch thanks!

llma (guest)
September 2, 2008 at 9:41 p.m. UTC

Stretch ! Thanks. Could you post your recommendation for frame relay hub-and-spoke configuration using GNS3 ? Thanks again..

mohamed abdel rahman (guest)
April 8, 2013 at 2:31 p.m. UTC

Dear Stretch,

 very nice discussing realy thank you very much

Best Regards
Mohamed Abdel Rahman

dudos (guest)
August 4, 2013 at 3:31 a.m. UTC

Good work here, but no setup config about your FRAME-RELAY SWITCH device or did you just pick a frame-relay switch that needs no configuration other than configuring the DLCI numbers? i would like to see how to do that through a manual configuration.

Comments have closed for this article due to its age.