OSPFv3 routers use their link-local addresses as the source of hello packets. No IPv6 prefix information is contained in hello packets. Multiple IPv6 addresses can be configured on a link. None of the addresses are defined as secondary addresses, as is done with IPv4 to configure multiple addresses on a single link. Two routers will become adjacent even if no IPv6 prefix is common between the neighbors except the link-local address. This is different from OSPFv2 for IPv4. OSPFv2 neighbors will only become adjacent if the neighbors belong to the same IP subnet, and the common subnet is configured as the primary IP address on the neighboring interfaces. In Figure 9-15, Hedwig is configured with both 2001:db8:0:4::/64 and 2001:db8:0:5::/64 on its Ethernet interface. Pigwidgeon is configured with 2001:db8:0:5::/64 and Crookshanks is configured with 2001:db8:0:4::/64 on their Ethernet interfaces. Example 9-5 shows that Crookshanks is adjacent to both Hedwig (10.1.1.1) and Pigwidgeon (10.1.3.1). Pigwidgeon is the backup designated router.
Example 9-5 show ipv6 ospf neighbor shows Crookshanks's neighbors are all in the FULL state, even though they don't share a common IPv6 prefix, other then the link-local address.
Crookshanks#show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 10.1.1.1 1 FULL/DROTHER 00:00:30 3 Ethernet0/0 10.1.3.1 1 FULL/BDR 00:00:37 3 Ethernet0/0 Crookshanks#
Other parameters must match between two neighbors before they will become adjacent. These parameters are the same as IPv4: The neighbors must share the same area id, they must have the same Hello interval and dead time, and they both must have the same value in the E-bit, indicating whether the area is a stub area or not. An OSPFv3 packet must also have the same Instance ID as the receiving interface, or the OSPFv3 packets will be dropped. Instance ID will be discussed later in this chapter, in the case study, Multiple Instances on a Link.
OSPFv3 uses a 32-bit number for a Router ID. If IPv4 is configured on the router, by default, the RID is chosen in the same way it is by OSPFv2 for IPv4. The highest IPv4 address configured on a loopback interface will become the RID, or if no loopback interfaces are configured, the highest address on any other interface will become the RID.
IPv6 neighbors are always known by their RIDs, unlike IPv4, where point-to-point network neighbors are known by RIDs and broadcast, NBMA and point-to-multipoint network neighbors are known by their interface IP addresses. The neighbor IDs shown in Example 9-5 show that the router IDs are obtained from configured IPv4 addresses.
If IPv4 is not configured in the network, and you don't want to configure IPv4 just to establish a router ID, the router ID must be configured using the IPv6 OSPF routing process command router-id before the OSPF process will start.
When OSPFv3 is configured on an interface, the routing process is created. Interface parameters, such as the cost of a link, are modified at the interface configuration, but global parameters are modified at the OSPF process level.
Case Study: Stub Areas
The ipv6 router ospf command takes you into the global process configuration mode, just as router ospf does for IPv4. The same configuration customization can be done with IPv6 as with IPv4. Stub, NSSA, and totally stubby are supported and configured in the exact same way as for OSPFv2 for IPv4, using the area stub, area nssa, and area stub no-summary commands. Area 1 in Figure 9-15 is configured as a totally stubby area with the configurations in Example 9-6 and Example 9-7 at Hedwig and Scabbers.
Example 9-6 On Hedwig, area 1 is configured as a totally stubby area. no-summary is only configured on the ABR.
ipv6 router ospf 1 area 1 stub no-summary
Example 9-7 Area 1 on Scabbers is also configured as a stub because all routers in the stub area must be configured as a stub.
ipv6 router ospf 1 area 1 stub
Example 9-8 shows Scabbers's IPv6 route table before area 1 becomes totally stubby, and Example 9-9 shows the route table of Scabbers as part of the totally stubby area.
Example 9-8 The IPv6 route table at Scabbers contains 10 OSPF entries, all known via Hedwig.
Scabbers#show ipv6 route
IPv6 Routing Table - 16 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
OI 2001:DB8:0:4::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:5::/64 [110/74]
via FE80::202:FDFF:FE5A:E40, Serial0/0
C 2001:DB8:0:8::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:8::2/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:9::/64 [0/0]
via ::, Ethernet0/0
L 2001:DB8:0:9::2/128 [0/0]
via ::, Ethernet0/0
OI 2001:DB8:0:10::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:11::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:12::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:13::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:200::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:201::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:202::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
OI 2001:DB8:0:203::/64 [110/138]
via FE80::202:FDFF:FE5A:E40, Serial0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Scabbers#
Example 9-9 As part of a totally stubby area, Scabbers now has only a single OSPF entry, the default route.
Scabbers#show ipv6 route
IPv6 Routing Table - 7 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
OI ::/0 [110/65]
via FE80::202:FDFF:FE5A:E40, Serial0/0
C 2001:DB8:0:8::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:0:8::2/128 [0/0]
via ::, Serial0/0
C 2001:DB8:0:9::/64 [0/0]
via ::, Ethernet0/0
L 2001:DB8:0:9::2/128 [0/0]
via ::, Ethernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Scabbers#
Case Study: Multiple Instances on a Link
A new router, Hermes, has been added to the Ethernet segment in Figure 9-16. The desired OSPF design is to separate Pigwidgeon's and Hermes's OSPFv3 traffic from Hedwig's and Crookshanks's traffic. As the configuration stands, the DR and BDR are chosen among the four routers, and each router becomes adjacent with the DR and BDR. OSPFv3 Hellos contain a field for an Instance ID. The Instance ID can be used to segment the two OSPF processes running on the LAN segment. The Instance ID received in a Hello packet must match the Instance ID configured on the receiving interface or the Hello packet will be discarded. Instance ID 0 is used when none other is specified. By configuring Pigwidgeon and Hermes with a different Instance ID than is configured on Hedwig and Crookshanks, the desired adjacencies will be established.
A new router is added to the network of
Pigwidgeon's configuration is modified as displayed in Example 9-10.
Example 9-10 Pigwidgeon's Instance ID is modified from the default of 0 to create a distinct OSPF process on the Ethernet.
interface Ethernet 0/0 ipv6 address 2001:db8:0:5::3/64 ipv6 ospf 1 area 0 instance 1
Pigwidgeon's Instance ID is changed from the default of 0 to 1. Hedwig and Crookshanks continue to use the default Instance ID of zero. Hermes is configured similarly to Pigwidgeon to use instance ID 1. Looking at the IPv6 OSPF configuration running on Hermes's Ethernet0/0 interface, shown in Example 9-11, only Pigwidgeon (10.1.3.1) is adjacent.
Example 9-11 Hermes's IPv6 OSPF Ethernet interface configuration shows that Pigwidgeon, the only other router on the Ethernet segment using instance ID 1, is adjacent.
Hermes#show ipv6 ospf interface ethernet 0/0 Ethernet0/0 is up, line protocol is up Link Local Address FE80::206:28FF:FEB6:5BC0, Interface ID 3 Area 0, Process ID 1, Instance ID 1, Router ID 10.1.5.1 Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 10.1.5.1, local address FE80::206:28FF:FEB6:5BC0 Backup Designated router (ID) 10.1.3.1, local address FE80::201:42FF:FE79:E500 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:09 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 1, maximum is 4 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 10.1.3.1 (Backup Designated Router) Suppress hello for 0 neighbor(s) Hermes#
Although multiple OSPFv3 processes can run on a router, only a single process or instance can run on an interface.
Case Study: OSPFv3 on NBMA Networks
OSPFv3 on NBMA networks has the same configuration options as does OSPFv2, that is, the network, from OSPF's point of view, can remain NBMA, can be configured as broadcast or point-to-multipoint, or point-to-point networks can be configured using subinterfaces. Point-to-point links are straightforward to configure. They are configured the same way as routers connected directly via serial links. Hedwig and Scabbers, in the first case study in this chapter, called "A basic OSPFv3 configuration," are configured with directly connected serial links. If these two routers were connected with point-to-point Frame-relay subinterfaces, the OSPFv3 configuration would remain the same. The NBMA, broadcast, and point-to-multipoint networks will be discussed in this section.
Before OSPFv3 can learn about neighbors, the neighbor addresses that OSPF will use must be associated with specific virtual circuits traversing the NBMA network. Frame Relay maps are created to identify a remote IPv6 address with one of the PVCs connected to the local router.[2] Because IPv6 can have multiple addresses configured on a single interface, many map statements for each PVC might be required. All OSPFv3 packets use the Link-local address as the source address. It is also the link-local address that is used as the destination address for unicast OSPFv3 packets, and as the next-hop to which to forward a packet when routing. At a minimum, therefore, the link-local addresses must be mapped. Figure 9-17 shows a Frame Relay network with four attached routers.
Several options exist for configuring OSPFv3 for IPv6 on this Frame Relay network.
The first method of configuring the routers for OSPFv3 is to manually configure OSPFv3 neighbors. The remote routers' link-local addresses are mapped to the correct DLCI, and the IPv6 OSPFv3 neighbors are defined, both as part of the interface's configuration. Skrewt's configuration is shown in Example 9-12.
Example 9-12 OSPFv3 neighbors are configured on Skrewt manually.
interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf 1 area 1 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 ipv6 ospf neighbor fe80::206:28ff:feb6:5bc0 priority 5 ipv6 ospf neighbor fe80::202:fdff:fe5a:e40 priority 10 ipv6 ospf neighbor fe80::201:42ff:fe79:e500
Notice that the Link-local addresses are used in the frame-relay map statements and in the ospf neighbor statements. To specify which routers are to become the DR and BDR, assign priorities using an optional keyword with ipv6 ospf neighbor command.
Another configuration option is to enable OSPFv3 to dynamically discover neighbors. Two configuration items are required: The OSPF network gets defined as a broadcast network using the command ipv6 ospf network broadcast, and the frame-relay map statements are configured to forward broadcasts over the PVC using the broadcast keyword on the map statement. Skrewt's configuration changes to Example 9-13.
Example 9-13 Skrewt's PVCs are configured as broadcast PVCs, and the OSPFv3 network running over the Frame Relay link is configured as a broadcast network.
interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network broadcast ipv6 ospf 1 area 1 ipv6 ospf priority 20 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast
The other routers on the multiaccess network are configured similarly. Notice that there is no longer any need to define IPv6 OSPF neighbors. If the underlying NBMA network is not fully meshed (a PVC from every router to every other router), the DR and BDR must be carefully selected. Both the DR and BDRs must have full virtual circuit connectivity to every other router so the correct adjacencies are formed. Use the interface command ipv6 ospf priority to specify a high priority on the router you wish to be the DR. This method of assigning the DR is discussed in the case study, OSPF on NBMA Networks, in Chapter 8. Example 9-14 shows Skrewt's IPv6 OSPF configuration on serial 0/0.
Example 9-14 An interface's OSPFv3 for IPv6 configuration is displayed using the show ipv6 ospf interface command.
Skrewt#show ipv6 ospf interface serial 0/0 Serial0/0 is up, line protocol is up Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4 Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 20 Designated Router (ID) 1.1.1.1, local address FE80::207:85FF:FE6B:EA20 Backup Designated router (ID) 10.1.3.1, local address FE80::202:FDFF:FE5A:E40 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 1, maximum is 4 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 3, Adjacent neighbor count is 3 Adjacent with neighbor 10.1.1.23 Adjacent with neighbor 10.1.3.1 (Backup Designated Router) Adjacent with neighbor 192.2.2.9 Suppress hello for 0 neighbor(s) Skrewt#