Difference between revisions of "IPv6: OSPFv3 Konfigurasi"
Onnowpurbo (talk | contribs) (Created page with "Configuring OSPFv3 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 includ...") |
Onnowpurbo (talk | contribs) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
− | |||
The configuration options of OSPFv3 are the same as those for OSPFv2. | The configuration options of OSPFv3 are the same as those for OSPFv2. | ||
Process IDs and areas need to be specified. Interfaces and addresses | Process IDs and areas need to be specified. Interfaces and addresses | ||
Line 11: | Line 10: | ||
are different from OSPFv2 and some that are very similar, but need to be | are different from OSPFv2 and some that are very similar, but need to be | ||
emphasized. | emphasized. | ||
− | Case Study: A Basic OSPFv3 Configuration | + | |
+ | ==Case Study: A Basic OSPFv3 Configuration== | ||
+ | |||
The configuration of OSPFv3 is similar to OSPFv2 with two exceptions. | The configuration of OSPFv3 is similar to OSPFv2 with two exceptions. | ||
Recall from Chapter 8 that to configure OSPFv2 on a router and an | Recall from Chapter 8 that to configure OSPFv2 on a router and an | ||
Line 26: | Line 27: | ||
yet been created, it is created automatically. All IPv6 addresses | yet been created, it is created automatically. All IPv6 addresses | ||
configured on the interface are included in the specified OSPF process. | configured on the interface are included in the specified OSPF process. | ||
+ | |||
Figure 9-15 displays an OSPFv3 network. | Figure 9-15 displays an OSPFv3 network. | ||
+ | |||
Figure 9-15. Example of an OSPFv3 network.[View full size image] | Figure 9-15. Example of an OSPFv3 network.[View full size image] | ||
Hedwig's and Pigwidgeon's configurations are displayed in Example 9-1 | Hedwig's and Pigwidgeon's configurations are displayed in Example 9-1 | ||
and Example 9-2. | and Example 9-2. | ||
+ | |||
Example 9-1. OSPFv3 is configured on Hedwig with the | Example 9-1. OSPFv3 is configured on Hedwig with the | ||
interface command ipv6 ospf 1 area 1. | interface command ipv6 ospf 1 area 1. | ||
− | interface Serial 0/0 | + | |
− | ipv6 address 2001:db8:0:8::1/64 | + | interface Serial 0/0 |
− | ipv6 ospf 1 area 1 | + | ipv6 address 2001:db8:0:8::1/64 |
− | interface Ethernet0/0 | + | ipv6 ospf 1 area 1 |
− | ipv6 address 2001:db8:0:4::1/64 | + | interface Ethernet0/0 |
− | ipv6 ospf 1 area 0 | + | ipv6 address 2001:db8:0:4::1/64 |
+ | ipv6 ospf 1 area 0 | ||
+ | |||
Example 9-2. Pigwidgeon is configured for OSPFv3. | Example 9-2. Pigwidgeon is configured for OSPFv3. | ||
− | interface Ethernet 0/0 | + | |
− | ipv6 address 2001:db8:0:5::3/64 | + | interface Ethernet 0/0 |
− | ipv6 ospf 1 area 0 | + | ipv6 address 2001:db8:0:5::3/64 |
− | interface Serial 0/0ipv6 address 2001:db8:0:10::1/64 | + | ipv6 ospf 1 area 0 |
− | 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 | The command ipv6 ospf area enables OSPFv3 on Serial0/0 and | ||
Ethernet0/0, places Hedwig's serial interface in area 1 and the Ethernet | Ethernet0/0, places Hedwig's serial interface in area 1 and the Ethernet | ||
Line 54: | Line 62: | ||
command, whereas the ipv6 ospf area command has to be configured | command, whereas the ipv6 ospf area command has to be configured | ||
on each interface that will be running OSPFv3. | on each interface that will be running OSPFv3. | ||
+ | |||
Example 9-3. show ipv6 protocol displays the OSPF for | Example 9-3. show ipv6 protocol displays the OSPF for | ||
IPv6 process ID and the interfaces configured in each area | IPv6 process ID and the interfaces configured in each area | ||
on the router. | on the router. | ||
− | Hedwig#show ipv6 protocol | + | |
− | IPv6 Routing Protocol is "connected" | + | Hedwig#show ipv6 protocol |
− | IPv6 Routing Protocol is "static" | + | IPv6 Routing Protocol is "connected" |
− | IPv6 Routing Protocol is "ospf 1" | + | IPv6 Routing Protocol is "static" |
− | Interfaces (Area 0): | + | IPv6 Routing Protocol is "ospf 1" |
− | Ethernet0/0 | + | Interfaces (Area 0): |
− | Interfaces (Area 1): | + | Ethernet0/0 |
− | Serial0/0 | + | Interfaces (Area 1): |
− | Redistribution: | + | Serial0/0 |
− | None | + | Redistribution: |
− | Hedwig# | + | 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 | 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. | to Hedwig's Ethernet port in Example 9-4. | ||
+ | |||
Example 9-4. A second IPv6 address is added to Hedwig's | Example 9-4. A second IPv6 address is added to Hedwig's | ||
Ethernet0/0. Both IPv6 addresses are included in the | Ethernet0/0. Both IPv6 addresses are included in the | ||
OSPFv3 process because OSPFv3 is configured on that | OSPFv3 process because OSPFv3 is configured on that | ||
interface. | interface. | ||
− | interface Ethernet0/0 | + | |
− | ipv6 address 2001:db8:0:4::1/64 | + | interface Ethernet0/0 |
− | ipv6 address 2001:db8:0:5::1/64 | + | ipv6 address 2001:db8:0:4::1/64 |
− | ipv6 ospf 1 area 0 | + | ipv6 address 2001:db8:0:5::1/64 |
+ | ipv6 ospf 1 area 0 | ||
+ | |||
This second address is included automatically in the OSPFv3 process | This second address is included automatically in the OSPFv3 process | ||
that is configured on the interface. No additional OSPFv3 commands | that is configured on the interface. No additional OSPFv3 commands | ||
Line 85: | Line 99: | ||
interface with OSPFv3, or OSPFV3 is not configured on the interface and | interface with OSPFv3, or OSPFV3 is not configured on the interface and | ||
none of the addresses are included. | none of the addresses are included. | ||
+ | |||
OSPFv3 routers use their link-local addresses as the source of hello | OSPFv3 routers use their link-local addresses as the source of hello | ||
packets. No IPv6 prefix information is contained in hello packets. Multiple | packets. No IPv6 prefix information is contained in hello packets. Multiple | ||
Line 96: | Line 111: | ||
neighboring interfaces. In Figure 9-15, Hedwig is configured with both | 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. | 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 | 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 | 9-5 shows that Crookshanks is adjacent to both Hedwig (10.1.1.1) and | ||
Line 103: | Line 119: | ||
though they don't share a common IPv6 prefix, other then | though they don't share a common IPv6 prefix, other then | ||
the link-local address. | the link-local address. | ||
− | Crookshanks#show ipv6 ospf neighbor | + | |
− | Neighbor ID | + | Crookshanks#show ipv6 ospf neighbor |
− | 10.1.1.1 | + | Neighbor ID |
− | 10.1.3.1 | + | 10.1.1.1 |
− | Crookshanks# | + | 10.1.3.1 |
− | Pri | + | Crookshanks# |
− | 1 | + | Pri |
− | 1 | + | 1 |
− | State | + | 1 |
− | FULL/DROTHER | + | State |
− | FULL/BDR | + | FULL/DROTHER |
− | Dead Time | + | FULL/BDR |
− | 00:00:30 | + | Dead Time |
− | 00:00:37 | + | 00:00:30 |
− | Interface ID | + | 00:00:37 |
− | 3 | + | Interface ID |
− | 3 | + | 3 |
+ | 3 | ||
+ | |||
Other parameters must match between two neighbors before they will | Other parameters must match between two neighbors before they will | ||
become adjacent. These parameters are the same as IPv4: The | become adjacent. These parameters are the same as IPv4: The | ||
Line 128: | Line 146: | ||
OSPFv3 packets will be dropped. Instance ID will be discussed later in | OSPFv3 packets will be dropped. Instance ID will be discussed later in | ||
this chapter, in the case study, Multiple Instances on a Link. | 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 | 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 | the router, by default, the RID is chosen in the same way it is by OSPFv2 | ||
Line 133: | Line 152: | ||
will become the RID, or if no loopback interfaces are configured, the | will become the RID, or if no loopback interfaces are configured, the | ||
highest address on any other interface will become the RID. | highest address on any other interface will become the RID. | ||
+ | |||
IPv6 neighbors are always known by their RIDs, unlike IPv4, where point- | IPv6 neighbors are always known by their RIDs, unlike IPv4, where point- | ||
to-point network neighbors are known by RIDs and broadcast, NBMA and | 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 | 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. | IDs are obtained from configured IPv4 addresses. | ||
+ | |||
If IPv4 is not configured in the network, and you don't want to configure | 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 | 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 | the IPv6 OSPF routing process command router-id before the OSPF | ||
process will start. | process will start. | ||
+ | |||
When OSPFv3 is configured on an interface, the routing process is | When OSPFv3 is configured on an interface, the routing process is | ||
created. Interface parameters, such as the cost of a link, are modified at | created. Interface parameters, such as the cost of a link, are modified at | ||
the interface configuration, but global parameters are modified at the | the interface configuration, but global parameters are modified at the | ||
OSPF process level. | OSPF process level. | ||
− | Case Study: Stub Areas | + | |
+ | ==Case Study: Stub Areas== | ||
+ | |||
The ipv6 router ospf command takes you into the global process | The ipv6 router ospf command takes you into the global process | ||
configuration mode, just as router ospf does for IPv4. The same | configuration mode, just as router ospf does for IPv4. The same | ||
Line 154: | Line 178: | ||
totally stubby area with the configurations in Example 9-6 and Example | totally stubby area with the configurations in Example 9-6 and Example | ||
9-7 at Hedwig and Scabbers. | 9-7 at Hedwig and Scabbers. | ||
+ | |||
Example 9-6. On Hedwig, area 1 is configured as a totally | Example 9-6. On Hedwig, area 1 is configured as a totally | ||
stubby area. no-summary is only configured on the ABR. | stubby area. no-summary is only configured on the ABR. | ||
− | ipv6 router ospf 1 | + | |
− | area 1 stub no-summary | + | ipv6 router ospf 1 |
+ | area 1 stub no-summary | ||
+ | |||
Example 9-7. Area 1 on Scabbers is also configured as a | 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 | stub because all routers in the stub area must bestub because all routers in the stub area must be | ||
configured as a stub. | configured as a stub. | ||
− | ipv6 router ospf 1 | + | |
− | area 1 stub | + | ipv6 router ospf 1 |
+ | area 1 stub | ||
+ | |||
Example 9-8 shows Scabbers's IPv6 route table before area 1 becomes | 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 | totally stubby, and Example 9-9 shows the route table of Scabbers as | ||
part of the totally stubby area. | part of the totally stubby area. | ||
+ | |||
Example 9-8. The IPv6 route table at Scabbers contains 10 | Example 9-8. The IPv6 route table at Scabbers contains 10 | ||
OSPF entries, all known via Hedwig. | OSPF entries, all known via Hedwig. | ||
− | Scabbers#show ipv6 route | + | |
− | IPv6 Routing Table - 16 entries | + | Scabbers#show ipv6 route |
− | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP | + | IPv6 Routing Table - 16 entries |
− | U - Per-user Static route | + | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP |
− | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS | + | U - Per-user Static route |
− | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - | + | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS |
− | ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 | + | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - |
− | OI 2001:DB8:0:4::/64 [110/74] | + | ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 |
− | via FE80::202:FDFF:FE5A:E40, Serial0/0 | + | OI 2001:DB8:0:4::/64 [110/74] |
− | OI 2001:DB8:0:5::/64 [110/74] | + | via FE80::202:FDFF:FE5A:E40, Serial0/0 |
− | via FE80::202:FDFF:FE5A:E40, Serial0/0 | + | OI 2001:DB8:0:5::/64 [110/74] |
− | C | + | via FE80::202:FDFF:FE5A:E40, Serial0/0 |
− | 2001:DB8:0:8::/64 [0/0] | + | C |
− | via ::, Serial0/0 | + | 2001:DB8:0:8::/64 [0/0] |
− | L | + | via ::, Serial0/0 |
− | 2001:DB8:0:8::2/128 [0/0] | + | L |
− | via ::, Serial0/0 | + | 2001:DB8:0:8::2/128 [0/0] |
− | C | + | via ::, Serial0/0 |
− | 2001:DB8:0:9::/64 [0/0] | + | C |
− | via ::, Ethernet0/0 | + | 2001:DB8:0:9::/64 [0/0] |
− | L | + | via ::, Ethernet0/0 |
− | 2001:DB8:0:9::2/128 [0/0] | + | L |
− | via ::, Ethernet0/0 | + | 2001:DB8:0:9::2/128 [0/0] |
− | OI 2001:DB8:0:10::/64 [110/138] | + | via ::, Ethernet0/0 |
− | via FE80::202:FDFF:FE5A:E40, Serial0/0OI | + | OI 2001:DB8:0:10::/64 [110/138] |
− | 2001:DB8:0:11::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, Serial0/0OI |
− | via FE80::202:FDFF:FE5A:E40, | + | 2001:DB8:0:11::/64 [110/138] |
− | OI 2001:DB8:0:12::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:12::/64 [110/138] |
− | OI 2001:DB8:0:13::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:13::/64 [110/138] |
− | OI 2001:DB8:0:200::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:200::/64 [110/138] |
− | OI 2001:DB8:0:201::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:201::/64 [110/138] |
− | OI 2001:DB8:0:202::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:202::/64 [110/138] |
− | OI 2001:DB8:0:203::/64 [110/138] | + | via FE80::202:FDFF:FE5A:E40, |
− | via FE80::202:FDFF:FE5A:E40, | + | OI 2001:DB8:0:203::/64 [110/138] |
− | L | + | via FE80::202:FDFF:FE5A:E40, |
− | FE80::/10 [0/0] | + | L |
− | via ::, Null0 | + | FE80::/10 [0/0] |
− | L | + | via ::, Null0 |
− | FF00::/8 [0/0] | + | L |
− | via ::, Null0 | + | FF00::/8 [0/0] |
− | Scabbers# | + | via ::, Null0 |
− | Serial0/0 | + | Scabbers# |
− | 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 | ||
+ | |||
Example 9-9. As part of a totally stubby area, Scabbers | Example 9-9. As part of a totally stubby area, Scabbers | ||
now has only a single OSPF entry, the default route. | now has only a single OSPF entry, the default route. | ||
− | Scabbers#show ipv6 route | + | |
− | IPv6 Routing Table - 7 entries | + | Scabbers#show ipv6 route |
− | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP | + | IPv6 Routing Table - 7 entries |
− | U - Per-user Static route | + | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP |
− | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS | + | U - Per-user Static route |
− | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -via ::, Serial0/0 | + | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS |
− | L | + | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -via ::, Serial0/0 |
− | 2001:DB8:0:8::2/128 [0/0] | + | L |
− | via ::, Serial0/0 | + | 2001:DB8:0:8::2/128 [0/0] |
− | C | + | via ::, Serial0/0 |
− | 2001:DB8:0:9::/64 [0/0] | + | C |
− | via ::, Ethernet0/0 | + | 2001:DB8:0:9::/64 [0/0] |
− | L | + | via ::, Ethernet0/0 |
− | 2001:DB8:0:9::2/128 [0/0] | + | L |
− | via ::, Ethernet0/0 | + | 2001:DB8:0:9::2/128 [0/0] |
− | L | + | via ::, Ethernet0/0 |
− | FE80::/10 [0/0] | + | L |
− | via ::, Null0 | + | FE80::/10 [0/0] |
− | L | + | via ::, Null0 |
− | FF00::/8 [0/0] | + | L |
− | via ::, Null0 | + | FF00::/8 [0/0] |
− | Scabbers# | + | via ::, Null0 |
− | Case Study: Multiple Instances on a Link | + | Scabbers# |
+ | |||
+ | ==Case Study: Multiple Instances on a Link== | ||
+ | |||
A new router, Hermes, has been added to the Ethernet segment in | 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 | Figure 9-16. The desired OSPF design is to separate Pigwidgeon's and | ||
Line 259: | Line 294: | ||
configured on Hedwig and Crookshanks, the desired adjacencies will be | configured on Hedwig and Crookshanks, the desired adjacencies will be | ||
established. | established. | ||
+ | |||
Figure 9-16. A new router is added to the network of Figure | Figure 9-16. A new router is added to the network of Figure | ||
− | 9-15.[View full size image] | + | 9-15. |
+ | |||
+ | [View full size image] | ||
+ | |||
Pigwidgeon's configuration is modified as displayed in Example 9-10. | Pigwidgeon's configuration is modified as displayed in Example 9-10. | ||
Example 9-10. Pigwidgeon's Instance ID is modified from | Example 9-10. Pigwidgeon's Instance ID is modified from | ||
the default of 0 to create a distinct OSPF process on the | the default of 0 to create a distinct OSPF process on the | ||
Ethernet. | Ethernet. | ||
− | interface Ethernet 0/0 | + | |
− | ipv6 address 2001:db8:0:5::3/64 | + | interface Ethernet 0/0 |
− | ipv6 ospf 1 area 0 instance 1 | + | 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 | 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 | and Crookshanks continue to use the default Instance ID of zero. Hermes | ||
Line 273: | Line 314: | ||
IPv6 OSPF configuration running on Hermes's Ethernet0/0 interface, | IPv6 OSPF configuration running on Hermes's Ethernet0/0 interface, | ||
shown in Example 9-11, only Pigwidgeon (10.1.3.1) is adjacent. | 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 | 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. | process or instance can run on an interface.process or instance can run on an interface. | ||
Line 278: | Line 320: | ||
configuration shows that Pigwidgeon, the only other router | configuration shows that Pigwidgeon, the only other router | ||
on the Ethernet segment using instance ID 1, is adjacent. | 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 | + | Hermes#show ipv6 ospf interface ethernet 0/0 |
− | Link Local Address FE80::206:28FF:FEB6:5BC0, Interface ID 3 | + | Ethernet0/0 is up, line protocol is up |
− | Area 0, Process ID 1, Instance ID 1, Router ID 10.1.5.1 | + | Link Local Address FE80::206:28FF:FEB6:5BC0, Interface ID 3 |
− | Network Type BROADCAST, Cost: 10 | + | Area 0, Process ID 1, Instance ID 1, Router ID 10.1.5.1 |
− | Transmit Delay is 1 sec, State DR, Priority 1 | + | Network Type BROADCAST, Cost: 10 |
− | Designated Router (ID) 10.1.5.1, local address FE80::206:28FF | + | Transmit Delay is 1 sec, State DR, Priority 1 |
− | Backup Designated router (ID) 10.1.3.1, local address FE80::2 | + | Designated Router (ID) 10.1.5.1, local address FE80::206:28FF |
− | Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra | + | Backup Designated router (ID) 10.1.3.1, local address FE80::2 |
− | Hello due in 00:00:09 | + | Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra |
− | Index 1/1/1, flood queue length 0 | + | Hello due in 00:00:09 |
− | Next 0x0(0)/0x0(0)/0x0(0) | + | Index 1/1/1, flood queue length 0 |
− | Last flood scan length is 1, maximum is 4 | + | Next 0x0(0)/0x0(0)/0x0(0) |
− | Last flood scan time is 0 msec, maximum is 0 msec | + | Last flood scan length is 1, maximum is 4 |
− | Neighbor Count is 1, Adjacent neighbor count is 1 | + | Last flood scan time is 0 msec, maximum is 0 msec |
− | Adjacent with neighbor 10.1.3.1 (Backup Designated Router) | + | Neighbor Count is 1, Adjacent neighbor count is 1 |
− | Suppress hello for 0 neighbor(s) | + | Adjacent with neighbor 10.1.3.1 (Backup Designated Router) |
− | Hermes# | + | Suppress hello for 0 neighbor(s) |
− | Case Study: OSPFv3 on NBMA Networks | + | Hermes# |
+ | |||
+ | ==Case Study: OSPFv3 on NBMA Networks== | ||
+ | |||
OSPFv3 on NBMA networks has the same configuration options as does | OSPFv3 on NBMA networks has the same configuration options as does | ||
OSPFv2, that is, the network, from OSPF's point of view, can remain | OSPFv2, that is, the network, from OSPF's point of view, can remain | ||
Line 311: | Line 356: | ||
the NBMA network. Frame Relay maps are created to identify a remote | 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] | IPv6 address with one of the PVCs connected to the local router. [2] | ||
+ | |||
Because IPv6 can have multiple addresses configured on a single | Because IPv6 can have multiple addresses configured on a single | ||
interface, many map statements for each PVC might be required. All | interface, many map statements for each PVC might be required. All | ||
Line 320: | Line 366: | ||
attached routers. | attached routers. | ||
[2] | [2] | ||
+ | |||
IPv4 uses Frame Relay inverse ARP to dynamically map addresses. IPv6's | 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 | functionality to dynamically map addresses to Frame Relay PVCs is not supported in IOS | ||
at the time of this writing. | at the time of this writing. | ||
+ | |||
Figure 9-17. Several options exist for configuring OSPFv3 | Figure 9-17. Several options exist for configuring OSPFv3 | ||
for IPv6 on this Frame Relay network. | for IPv6 on this Frame Relay network. | ||
+ | |||
[View full size image]The first method of configuring the routers for OSPFv3 is to manually | [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 | configure OSPFv3 neighbors. The remote routers' link-local addresses | ||
Line 330: | Line 379: | ||
defined, both as part of the interface's configuration. Skrewt's | defined, both as part of the interface's configuration. Skrewt's | ||
configuration is shown in Example 9-12. | configuration is shown in Example 9-12. | ||
+ | |||
Example 9-12. OSPFv3 neighbors are configured on Skrewt | Example 9-12. OSPFv3 neighbors are configured on Skrewt | ||
manually. | manually. | ||
− | interface Serial 0/0 | + | |
− | encapsulation frame-relay | + | interface Serial 0/0 |
− | ipv6 address 2001:DB8:0:1::1/64 | + | encapsulation frame-relay |
− | ipv6 ospf 1 area 1 | + | ipv6 address 2001:DB8:0:1::1/64 |
− | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 | + | ipv6 ospf 1 area 1 |
− | frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 | + | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 |
− | frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 | + | frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 |
− | ipv6 ospf neighbor fe80::206:28ff:feb6:5bc0 priority 5 | + | frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 |
− | ipv6 ospf neighbor fe80::202:fdff:fe5a:e40 priority 10 | + | ipv6 ospf neighbor fe80::206:28ff:feb6:5bc0 priority 5 |
− | ipv6 ospf neighbor fe80::201:42ff:fe79: | + | 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 | statements and in the ospf neighbor statements. To specify which | ||
routers are to become the DR and BDR, assign priorities using an | routers are to become the DR and BDR, assign priorities using an | ||
optional keyword with ipv6 ospf neighbor command. | optional keyword with ipv6 ospf neighbor command. | ||
+ | |||
Another configuration option is to enable OSPFv3 to dynamically | Another configuration option is to enable OSPFv3 to dynamically | ||
discover neighbors. Two configuration items are required: The OSPF | discover neighbors. Two configuration items are required: The OSPF | ||
Line 352: | Line 406: | ||
keyword on the map statement. Skrewt's configuration changes to | keyword on the map statement. Skrewt's configuration changes to | ||
Example 9-13. | Example 9-13. | ||
+ | |||
Example 9-13. Skrewt's PVCs are configured as broadcast | Example 9-13. Skrewt's PVCs are configured as broadcast | ||
PVCs, and the OSPFv3 network running over the Frame | PVCs, and the OSPFv3 network running over the Frame | ||
Relay link is configured as a broadcast network. | Relay link is configured as a broadcast network. | ||
− | interface Serial 0/0 | + | |
− | encapsulation frame-relay | + | interface Serial 0/0 |
− | ipv6 address 2001:DB8:0:1::1/64 | + | encapsulation frame-relay |
− | ipv6 ospf network broadcast | + | ipv6 address 2001:DB8:0:1::1/64 |
− | ipv6 ospf 1 area 1 | + | ipv6 ospf network broadcast |
− | ipv6 ospf priority 20 | + | ipv6 ospf 1 area 1 |
− | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast | + | ipv6 ospf priority 20 |
− | frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast | + | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast |
− | frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 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. | The other routers on the multiaccess network are configured similarly. | ||
Notice that there is no longer any need to define IPv6 OSPF neighbors. If | Notice that there is no longer any need to define IPv6 OSPF neighbors. If | ||
Line 373: | Line 430: | ||
case study, OSPF on NBMA Networks, in Chapter 8. Example 9-14 | case study, OSPF on NBMA Networks, in Chapter 8. Example 9-14 | ||
shows Skrewt's IPv6 OSPF configuration on serial 0/0. | shows Skrewt's IPv6 OSPF configuration on serial 0/0. | ||
+ | |||
Example 9-14. An interface's OSPFv3 for IPv6 configuration | Example 9-14. An interface's OSPFv3 for IPv6 configuration | ||
is displayed using the show ipv6 ospf interface command. | 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 | + | Skrewt#show ipv6 ospf interface serial 0/0 |
− | Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4 | + | Serial0/0 is up, line protocol is up |
− | Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 | + | Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4 |
− | Network Type BROADCAST, Cost: 64 | + | Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 |
− | Transmit Delay is 1 sec, State DR, Priority 20 | + | Network Type BROADCAST, Cost: 64 |
− | Designated Router (ID) 1.1.1.1, local address FE80::207:85FF: | + | Transmit Delay is 1 sec, State DR, Priority 20 |
− | Backup Designated router (ID) 10.1.3.1, local address FE80::2 | + | Designated Router (ID) 1.1.1.1, local address FE80::207:85FF: |
− | Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra | + | Backup Designated router (ID) 10.1.3.1, local address FE80::2 |
− | Hello due in 00:00:08 | + | Timer intervals configured, Hello 10, Dead 40, Wait 40, Retra |
− | Index 1/1/1, flood queue length 0 | + | Hello due in 00:00:08 |
− | Next 0x0(0)/0x0(0)/0x0(0) | + | Index 1/1/1, flood queue length 0 |
− | Last flood scan length is 1, maximum is 4 | + | Next 0x0(0)/0x0(0)/0x0(0) |
− | Last flood scan time is 0 msec, maximum is 4 msec | + | Last flood scan length is 1, maximum is 4 |
− | Neighbor Count is 3, Adjacent neighbor count is 3 | + | Last flood scan time is 0 msec, maximum is 4 msec |
− | Adjacent with neighbor 10.1.1.23 | + | Neighbor Count is 3, Adjacent neighbor count is 3 |
− | Adjacent with neighbor 10.1.3.1 (Backup Designated Router) | + | Adjacent with neighbor 10.1.1.23 |
− | Adjacent with neighbor 192.2.2.9 | + | Adjacent with neighbor 10.1.3.1 (Backup Designated Router) |
− | Suppress hello for 0 neighbor(s) | + | Adjacent with neighbor 192.2.2.9 |
− | Skrewt# | + | Suppress hello for 0 neighbor(s) |
+ | Skrewt# | ||
+ | |||
Note that the network type is BROADCAST. Also note that the neighbor | 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 | count is 3, and there are 3 adjacent neighbors. This router is the DR, so it | ||
Line 403: | Line 463: | ||
non-DR or BDR router will have three neighbors, but only | non-DR or BDR router will have three neighbors, but only | ||
be fully adjacent to two of the neighbors. | be fully adjacent to two of the neighbors. | ||
− | Flobberworm#show ipv6 ospf neighbor | + | |
− | Neighbor ID | + | Flobberworm#show ipv6 ospf neighbor |
− | 1.1.1.1 | + | Neighbor ID |
− | 10.1.1.23 | + | 1.1.1.1 |
− | 10.1.3.1 | + | 10.1.1.23 |
− | Flobberworm# | + | 10.1.3.1 |
− | Pri | + | Flobberworm# |
− | 20 | + | Pri |
− | 1 | + | 20 |
− | 15 | + | 1 |
− | State | + | 15 |
− | FULL/DR | + | State |
− | 2WAY/DROTHER | + | FULL/DR |
− | FULL/BDR | + | 2WAY/DROTHER |
− | Dead Time | + | FULL/BDR |
− | 00:00:36 | + | Dead Time |
− | 00:00:36 | + | 00:00:36 |
− | 00:00:37 | + | 00:00:36 |
− | Interface ID | + | 00:00:37 |
− | 3 | + | Interface ID |
− | 3 | + | 3 |
− | 3 | + | 3 |
+ | 3 | ||
+ | |||
To avoid the DR/BDR election process, the OSPF network type can be | 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 | changed to point-to-multipoint, as can be seen in Skrewt's modified | ||
configuration in Example 9-16. | configuration in Example 9-16. | ||
+ | |||
Example 9-16. Skrewt's configuration shows that the PVCs | Example 9-16. Skrewt's configuration shows that the PVCs | ||
continue to broadcast, and that the OSPFv3 network type | continue to broadcast, and that the OSPFv3 network type | ||
has been changed to point-to-multipoint. | has been changed to point-to-multipoint. | ||
− | Interface Serial 0/0 | + | |
− | encapsulation frame-relay | + | Interface Serial 0/0 |
− | ipv6 address 2001:DB8:0:1::1/64 | + | encapsulation frame-relay |
− | ipv6 ospf network point-to-multipoint | + | ipv6 address 2001:DB8:0:1::1/64 |
− | ipv6 ospf 1 area 1 | + | ipv6 ospf network point-to-multipoint |
− | ipv6 ospf priority 20 | + | ipv6 ospf 1 area 1 |
− | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast | + | ipv6 ospf priority 20 |
− | frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast | + | frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast |
− | frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 | + | 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 | 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- | are for broadcast networks. Hellos are sent every 30 seconds on point-to- | ||
Line 445: | Line 511: | ||
OSPFv3 interface configuration also does not show any DR, and the | OSPFv3 interface configuration also does not show any DR, and the | ||
router is adjacent with all three neighbors. | router is adjacent with all three neighbors. | ||
+ | |||
Example 9-17. The IPv6 OSPF interface configuration of an | Example 9-17. The IPv6 OSPF interface configuration of an | ||
OSPF point-to-multipoint network is displayed with the | OSPF point-to-multipoint network is displayed with the | ||
command show ipv6 ospf interface. | command show ipv6 ospf interface. | ||
− | Skrewt#show ipv6 ospf interface serial 0/0 | + | |
− | Serial0/0 is up, line protocol is up | + | Skrewt#show ipv6 ospf interface serial 0/0 |
− | Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4 | + | Serial0/0 is up, line protocol is up |
− | Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 | + | Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4 |
− | Network Type POINT_TO_MULTIPOINT, Cost: 64 | + | Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 |
− | Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, | + | Network Type POINT_TO_MULTIPOINT, Cost: 64 |
− | Timer intervals configured, Hello 30, Dead 120, Wait 120, Ret | + | Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, |
− | Hello due in 00:00:13 | + | Timer intervals configured, Hello 30, Dead 120, Wait 120, Ret |
− | Index 1/1/1, flood queue length 0 | + | Hello due in 00:00:13 |
− | Next 0x0(0)/0x0(0)/0x0(0) | + | Index 1/1/1, flood queue length 0 |
− | Last flood scan length is 2, maximum is 4 | + | Next 0x0(0)/0x0(0)/0x0(0) |
− | Last flood scan time is 0 msec, maximum is 4 msec | + | Last flood scan length is 2, maximum is 4 |
− | Neighbor Count is 3, Adjacent neighbor count is 3 | + | Last flood scan time is 0 msec, maximum is 4 msec |
− | Adjacent with neighbor 10.1.1.23 | + | Neighbor Count is 3, Adjacent neighbor count is 3 |
− | Adjacent with neighbor 10.1.3.1 | + | Adjacent with neighbor 10.1.1.23 |
− | Adjacent with neighbor 192.2.2.9 | + | Adjacent with neighbor 10.1.3.1 |
− | Suppress hello for 0 neighbor(s) | + | Adjacent with neighbor 192.2.2.9 |
− | Skrewt# | + | 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 | 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 | 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 | map statement for DLCI 202 has been removed from Skrewt in Example | ||
9-18. | 9-18. | ||
− | Figure 9-18. The network of Figure 9-17, with some PVCs | + | |
− | removed. | + | Figure 9-18. The network of Figure 9-17, with some PVCs removed. |
+ | |||
[View full size image] | [View full size image] | ||
+ | |||
Example 9-18. Skrewt's Frame Relay configuration maps | Example 9-18. Skrewt's Frame Relay configuration maps | ||
IPv6 addresses to the remaining two PVCs. | IPv6 addresses to the remaining two PVCs. | ||
− | interface Serial0/0 | + | |
− | no ip address | + | interface Serial0/0 |
− | encapsulation frame-relay | + | no ip address |
− | ipv6 address 2001:DB8:0:1::1/64ipv6 ospf network point-to-multipoint | + | encapsulation frame-relay |
− | ipv6 ospf priority 20 | + | ipv6 address 2001:DB8:0:1::1/64ipv6 ospf network point-to-multipoint |
− | ipv6 ospf 1 area 1 | + | ipv6 ospf priority 20 |
− | frame-relay map ipv6 FE80::201:42FF:FE79:E500 203 broadcast | + | ipv6 ospf 1 area 1 |
− | frame-relay map ipv6 FE80::206:28FF:FEB6:5BC0 201 broadcast | + | 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 | 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 | from Skrewt, as can be seen in Skrewt's IPv6 route table shown in | ||
Line 491: | Line 564: | ||
local addresses FE80::206:28FF:FEB6:5BC0 and | local addresses FE80::206:28FF:FEB6:5BC0 and | ||
FE80::201:42FF:FE79:E500. | FE80::201:42FF:FE79:E500. | ||
+ | |||
Example 9-19. Skrewt's route table shows that even the | Example 9-19. Skrewt's route table shows that even the | ||
router that does not have a connected PVC to Skrewt is | router that does not have a connected PVC to Skrewt is | ||
still accessible via the routers that do have connected | still accessible via the routers that do have connected | ||
PVCs in the point-to-multipoint network. | PVCs in the point-to-multipoint network. | ||
− | Skrewt#show ipv6 route | + | |
− | IPv6 Routing Table - 16 entries | + | Skrewt#show ipv6 route |
− | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP | + | IPv6 Routing Table - 16 entries |
− | U - Per-user Static route | + | Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP |
− | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS | + | U - Per-user Static route |
− | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -O | + | I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - IS |
− | 2001:DB8:0:1::3/128 [110/128] | + | O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 -O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:1::3/128 [110/128] |
− | via FE80::201:42FF:FE79:E500, | + | via FE80::206:28FF:FEB6:5BC0, |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:1::4/128 [110/64] | + | O |
− | via FE80::201:42FF:FE79:E500, | + | 2001:DB8:0:1::4/128 [110/64] |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:5::/64 [110/74] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:5::/64 [110/74] |
− | O | + | via FE80::206:28FF:FEB6:5BC0, |
− | 2001:DB8:0:A::/64 [110/138] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:A::/64 [110/138] |
− | via FE80::201:42FF:FE79:E500, | + | via FE80::206:28FF:FEB6:5BC0, |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:B::/64 [110/138] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:B::/64 [110/138] |
− | via FE80::201:42FF:FE79:E500, | + | via FE80::206:28FF:FEB6:5BC0, |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:C::/64 [110/138] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:C::/64 [110/138] |
− | via FE80::201:42FF:FE79:E500, | + | via FE80::206:28FF:FEB6:5BC0, |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:D::/64 [110/138] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:D::/64 [110/138] |
− | via FE80::201:42FF:FE79:E500, | + | via FE80::206:28FF:FEB6:5BC0, |
− | O | + | via FE80::201:42FF:FE79:E500, |
− | 2001:DB8:0:50::/64 [110/74] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:50::/64 [110/74] |
− | O | + | via FE80::206:28FF:FEB6:5BC0, |
− | 2001:DB8:0:51::/64 [110/74] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:51::/64 [110/74] |
− | O | + | via FE80::206:28FF:FEB6:5BC0, |
− | 2001:DB8:0:52::/64 [110/74] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:52::/64 [110/74] |
− | O | + | via FE80::206:28FF:FEB6:5BC0, |
− | 2001:DB8:0:53::/64 [110/74] | + | O |
− | via FE80::206:28FF:FEB6:5BC0, | + | 2001:DB8:0:53::/64 [110/74] |
− | L | + | via FE80::206:28FF:FEB6:5BC0, |
− | FE80::/10 [0/0] | + | L |
− | via ::, Null0 | + | FE80::/10 [0/0] |
− | L | + | via ::, Null0 |
− | FF00::/8 [0/0] | + | L |
− | via ::, Null0 | + | FF00::/8 [0/0] |
− | Skrewt# | + | via ::, Null0 |
− | Serial0/0 | + | 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 |
− | 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 | 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- | 2001:db8:0:1::4/64, that have been configured on the Frame Relay point- | ||
Line 567: | Line 643: | ||
by Hippogriff into OSPF, are reachable via the link-local addresses of | by Hippogriff into OSPF, are reachable via the link-local addresses of | ||
Skrewt's two adjacent routers. | Skrewt's two adjacent routers. | ||
− | |||
− | |||
− | |||
==Pranala Menarik== | ==Pranala Menarik== | ||
* [[IPv6: Advanced Routing]] | * [[IPv6: Advanced Routing]] |
Latest revision as of 09:10, 24 March 2019
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.