IPv6: OSPFv3 Konfigurasi
The configuration options of OSPFv3 are the same as those for OSPFv2. Process IDs and areas need to be specified. Interfaces and addresses need to be included in the process. Areas can be defined as stubs, totally stubby or not so stubby area (NSSA). Prefixes can be summarized between areas. OSPFv3 can be configured over demand circuits and on NBMA networks. Much of the configuration for OSPFv3 is the same as for OSPFv2. An IPv6 keyword is added in some cases, and an IPv6 prefix or address is used in place of the IPv4 subnet or address. This section contains case studies that show the OSPFv3 configurations that are different from OSPFv2 and some that are very similar, but need to be emphasized.
Case Study: A Basic OSPFv3 Configuration
The configuration of OSPFv3 is similar to OSPFv2 with two exceptions. Recall from Chapter 8 that to configure OSPFv2 on a router and an interface, you first create the OSPF process using the router ospf command. Then, you specify address ranges that encompass interface addresses that are to participate in OSPF, using the network area command. The interfaces configured with IPv4 addresses that fall within the address range specified with the network area command participate in OSPFv2. If an interface has an IPv4 address that is not part of the address range, that interface, or that address (if there is more then one IPv4 address on an interface) will not participate in the OSPFv2 process. OSPFv3 for IPv6 is enabled by specifying an OSPF process ID and an area at the interface configuration level. If an OSPFv3 process has not yet been created, it is created automatically. All IPv6 addresses configured on the interface are included in the specified OSPF process.
Figure 9-15 displays an OSPFv3 network.
Figure 9-15. Example of an OSPFv3 network.[View full size image] Hedwig's and Pigwidgeon's configurations are displayed in Example 9-1 and Example 9-2.
Example 9-1. OSPFv3 is configured on Hedwig with the interface command ipv6 ospf 1 area 1.
interface Serial 0/0 ipv6 address 2001:db8:0:8::1/64 ipv6 ospf 1 area 1 interface Ethernet0/0 ipv6 address 2001:db8:0:4::1/64 ipv6 ospf 1 area 0
Example 9-2. Pigwidgeon is configured for OSPFv3.
interface Ethernet 0/0 ipv6 address 2001:db8:0:5::3/64 ipv6 ospf 1 area 0 interface Serial 0/0ipv6 address 2001:db8:0:10::1/64 ipv6 ospf 1 area 0
The command ipv6 ospf area enables OSPFv3 on Serial0/0 and Ethernet0/0, places Hedwig's serial interface in area 1 and the Ethernet interface in area 0, and creates the OSPFv3 process with ID '1' on the router, as shown in Example 9-3. With OSPFv2, two commands are required to accomplish the same tasks: the router ospf 1 command creates the OSPF process, then the network area command enables OSPFv2 on interfaces. One thing to note, though, is that the network area command can enable OSPFv2 on multiple interfaces with the single command, whereas the ipv6 ospf area command has to be configured on each interface that will be running OSPFv3.
Example 9-3. show ipv6 protocol displays the OSPF for IPv6 process ID and the interfaces configured in each area on the router.
Hedwig#show ipv6 protocol IPv6 Routing Protocol is "connected" IPv6 Routing Protocol is "static" IPv6 Routing Protocol is "ospf 1" Interfaces (Area 0): Ethernet0/0 Interfaces (Area 1): Serial0/0 Redistribution: None Hedwig#
All IPv6 addresses on an interface are included in the OSPF process thatis created on the interface. For example, a second IPv6 address is added to Hedwig's Ethernet port in Example 9-4.
Example 9-4. A second IPv6 address is added to Hedwig's Ethernet0/0. Both IPv6 addresses are included in the OSPFv3 process because OSPFv3 is configured on that interface.
interface Ethernet0/0 ipv6 address 2001:db8:0:4::1/64 ipv6 address 2001:db8:0:5::1/64 ipv6 ospf 1 area 0
This second address is included automatically in the OSPFv3 process that is configured on the interface. No additional OSPFv3 commands need to be entered to make the new address part of the routing process. IPv6 addresses on an interface cannot be selectively included in OSPFv3. Either all the addresses are included, by configuring the interface with OSPFv3, or OSPFV3 is not configured on the interface and none of the addresses are included.
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 isconfigured 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 10.1.1.1 10.1.3.1 Crookshanks# Pri 1 1 State FULL/DROTHER FULL/BDR Dead Time 00:00:30 00:00:37 Interface ID 3 3
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 IPaddresses. 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 bestub 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 - IS O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - 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/0OI 2001:DB8:0:11::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:12::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:13::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:200::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:201::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:202::/64 [110/138] via FE80::202:FDFF:FE5A:E40, OI 2001:DB8:0:203::/64 [110/138] via FE80::202:FDFF:FE5A:E40, L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0 Scabbers# Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0
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 - IS O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -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.
Figure 9-16. A new router is added to the network of Figure 9-15.
[View full size image]
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.
Although multiple OSPFv3 processes can run on a router, only a single process or instance can run on an interface.process or instance can run on an interface. 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 Backup Designated router (ID) 10.1.3.1, local address FE80::2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra 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#
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 asrouters 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. [2]
IPv4 uses Frame Relay inverse ARP to dynamically map addresses. IPv6's functionality to dynamically map addresses to Frame Relay PVCs is not supported in IOS at the time of this writing.
Figure 9-17. Several options exist for configuring OSPFv3 for IPv6 on this Frame Relay network.
[View full size image]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 everyother 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: Backup Designated router (ID) 10.1.3.1, local address FE80::2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra 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#
Note that the network type is BROADCAST. Also note that the neighbor count is 3, and there are 3 adjacent neighbors. This router is the DR, so it has become adjacent to all other routers on the network. The neighbors that are not DR or BDR, such as Flobberworm, have three neighbors, butonly two adjacent neighbors, as shown in Example 9-15, because routers on broadcast networks become adjacent to the DR and BDR only. Example 9-15. With four routers on a broadcast network, a non-DR or BDR router will have three neighbors, but only be fully adjacent to two of the neighbors.
Flobberworm#show ipv6 ospf neighbor Neighbor ID 1.1.1.1 10.1.1.23 10.1.3.1 Flobberworm# Pri 20 1 15 State FULL/DR 2WAY/DROTHER FULL/BDR Dead Time 00:00:36 00:00:36 00:00:37 Interface ID 3 3 3
To avoid the DR/BDR election process, the OSPF network type can be changed to point-to-multipoint, as can be seen in Skrewt's modified configuration in Example 9-16.
Example 9-16. Skrewt's configuration shows that the PVCs continue to broadcast, and that the OSPFv3 network type has been changed to point-to-multipoint.
Interface Serial 0/0 encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64 ipv6 ospf network point-to-multipoint 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
Skrewt's IPv6 OSPF interface configuration (Example 9-17) shows that the default timers are different for point-to-multipoint networks then they are for broadcast networks. Hellos are sent every 30 seconds on point-to- multipoint networks and every 10 seconds on broadcast networks. The OSPFv3 interface configuration also does not show any DR, and the router is adjacent with all three neighbors.
Example 9-17. The IPv6 OSPF interface configuration of an OSPF point-to-multipoint network is displayed with the command show ipv6 ospf interface.
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 POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Ret Hello due in 00:00:13 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 2, 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 Adjacent with neighbor 192.2.2.9 Suppress hello for 0 neighbor(s) Skrewt#
An NBMA network configured as an OSPF point-to-multipoint networkneed not have a full mesh of underlying PVCs. Figure 9-18 shows that some PVCs have been removed from the network in Figure 9-17. The map statement for DLCI 202 has been removed from Skrewt in Example 9-18.
Figure 9-18. The network of Figure 9-17, with some PVCs removed.
[View full size image]
Example 9-18. Skrewt's Frame Relay configuration maps IPv6 addresses to the remaining two PVCs.
interface Serial0/0 no ip address encapsulation frame-relay ipv6 address 2001:DB8:0:1::1/64ipv6 ospf network point-to-multipoint ipv6 ospf priority 20 ipv6 ospf 1 area 1 frame-relay map ipv6 FE80::201:42FF:FE79:E500 203 broadcast frame-relay map ipv6 FE80::206:28FF:FEB6:5BC0 201 broadcast
Hippogriff and the IPv6 prefixes known to Hippogriff are all accessible from Skrewt, as can be seen in Skrewt's IPv6 route table shown in Example 9-19. Skrewt and Hippogriff are both adjacent to both Thestral and Flobberworm, and Hippogriff's IPv6 serial0/0 IPv6 address, 2001:db8:0:1::3, in addition to the IPv6 prefixes advertised by Hippogriff, are routed to via Skrewt's serial0/0 interface, and to the next-hop link- local addresses FE80::206:28FF:FEB6:5BC0 and FE80::201:42FF:FE79:E500.
Example 9-19. Skrewt's route table shows that even the router that does not have a connected PVC to Skrewt is still accessible via the routers that do have connected PVCs in the point-to-multipoint network.
Skrewt#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 - IS O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -O 2001:DB8:0:1::3/128 [110/128] via FE80::206:28FF:FEB6:5BC0, via FE80::201:42FF:FE79:E500, O 2001:DB8:0:1::4/128 [110/64] via FE80::201:42FF:FE79:E500, O 2001:DB8:0:5::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, O 2001:DB8:0:A::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, via FE80::201:42FF:FE79:E500, O 2001:DB8:0:B::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, via FE80::201:42FF:FE79:E500, O 2001:DB8:0:C::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, via FE80::201:42FF:FE79:E500, O 2001:DB8:0:D::/64 [110/138] via FE80::206:28FF:FEB6:5BC0, via FE80::201:42FF:FE79:E500, O 2001:DB8:0:50::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, O 2001:DB8:0:51::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, O 2001:DB8:0:52::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, O 2001:DB8:0:53::/64 [110/74] via FE80::206:28FF:FEB6:5BC0, L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0 Skrewt# Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0
The IPv6 addresses 2001:db8:0:1::2/64, 2001:db8:0:1::3/64, and 2001:db8:0:1::4/64, that have been configured on the Frame Relay point- to-multipoint interfaces are all advertised by OSPF with 128-bit prefixto-multipoint interfaces are all advertised by OSPF with 128-bit prefix lengths. These addresses, along with the other IPv6 prefixes advertised by Hippogriff into OSPF, are reachable via the link-local addresses of Skrewt's two adjacent routers.