10.2.1 Packet Tracer – Troubleshoot Multiarea OSPFv3 (Answers)
Instructor Note: Red font color or gray highlights indicate text that appears in the instructor copy only.
|Device||Interface||IPv6 Global Unicast Address||IPv6 Link-local Address|
Troubleshoot a multiarea OSPFv3 network
Background / Scenario
A large organization has recently implemented a multiarea OSPFv3 network. However, the network is no longer functioning correctly and communication through much of the network has failed. You must troubleshoot the problem, fix the multiarea OSPFv3 implementation, and restore communication throughout the network.
In Area 1, R2 is unable to form OSPF adjacencies. In Area 0 and Area 2, routers ABR2, R3 and R4 have not been able to form OSPF adjacencies. Finally, routers ABR1 and R1 have not received default route information.
Part 1: Use Show Commands to Troubleshoot OSPFv3 Area 1
In Part 1, use the symptoms of network failure reported in the Background / Scenario to begin troubleshooting configuration settings at the routers in Area 1.
Step 1: Check the R2 configuration in Area 1.
a. Because R2 is not forming an adjacency with R1, open a console on R2 and check its interface IP address configuration and its multiarea OSPFv2 configuration. Use the show running-config command to view the configuration.
Is the R2 OSPFv3 routing process configuration present and correct? Has OSPFv3 been activated on the G0/0 and Loopback 1 interfaces and have they been set to the correct Area?
The R2 OSPFv3 routing process is enabled and the interfaces are configured for area 1.
b. The R2 OSPFv3 configurations are correct. It is possible that OSPFv3 has not been configured on the R1 G0/0 interface. Open a console on R1 and issue a
show running-config command to check the G0/0 interface for the
ipv6 ospf 10 area 1 configuration.
Is the R1 OSPFv3 routing process configuration present and correct? Has OSPFv3 been activated on the G0/0 interface and set to Area1?
c. It is possible that the hello-interval and dead-interval timers have been altered from their default values of 10 seconds and 40 seconds respectively. A timer mismatch can cause the routers to not form adjacencies. If the dead-interval timer is not four times the value of the hello-interval timer, that could also cause the routers to not form adjacencies. Check the hello-interval and dead-interval timer values on R1 and R2.
R1# show ipv6 ospf interface g0/0 R2# show ipv6 ospf interface g0/0
Is there a mismatch or incorrect configuration on either the R1 or R2 hello-interval or dead-interval timers?
Yes, the R2 interface G0/0 timers are mismatched and incorrect.
d. Correct the hello-interval and dead-interval timer configuration errors on R2.
R2# configure terminal R2(config)# interface g0/0 R2(config-router)# ipv6 ospf hello-interval 10 R2(config-router)# ipv6 ospf dead-interval 40
If the problem has been corrected a syslog message should appear in the R2 console showing an OSPF adjacency change from LOADING to FULL. State if the problem has been corrected, and if so, what is the Nbr address?
Yes, there is a successful adjacency change to FULL with Nbr 22.214.171.124.
Step 2: Check the router configurations in Area 2 starting with ABR2.
a. Because it was reported that routers ABR2, R3 and R4 were all unable to form OSPFv3 adjacencies, open a console on the ABR2 border router to see why it is unable to form an adjacency with ASBR router.
Is the ABR2 OSPFv3 routing process configuration present and correct? Has OSPFv3 been activated on the S0/0/1 and G0/1 interfaces and have they been set to Area2?
The ABR2 OSPFv3 routing process has been enabled, but a router-id has not been set. The interfaces have been configured correctly.
b. OSPFv3 requires the presence of a 32bit dotted decimal router-id. Because ABR2 has no IPv4 addresses assigned to any of its interfaces, a router-id needs to be manually configured. Configure ABR2 with a 126.96.36.199 router-id.
ABR2# configure terminal ABR2(config)# ipv6 router ospf 10 ABR2(config-router)# router-id 188.8.131.52
If the problem has been corrected, syslog messages should appear in the console showing OSPF adjacency changes from LOADING to FULL. State if this is the case, and what neighbor Nbr addresses appear?
Yes, there are successful adjacency changes with Nbr 184.108.40.206 and Nbr 220.127.116.11.
c. On ABR2, a Syslog message showing an adjacency change from LOADING to FULL with Nbr 18.104.22.168 means that R3 is now participating in the OSPFv3 Area 2 process. Check that R4 has provided route information for its connected networks to the OSPFv3 topology database.
ABR2# show ipv6 ospf database
Look at the output of the
show ipv6 ospf database command. What information would signal the presence of R4?
The router-id 22.214.171.124 signifies the presence of R4 as well as the inclusion of the 2001:DB8:A8EA:2C::/64 network in the Area 2 section of the output.
Step 3: Check ASBR for OSPFv3 default route distribution.
a. Because ASBR is the edge router, it should have a static IPv6 default route configured. If so, it can distribute that route using OSPFv3 and a
default-information originate command.
Is there an IPv6 default route configured on ASBR? Does the OSPFv3 routing process configuration have a
default-information originate line present?
Yes ASBR has an ipv6 default route to ::/0, but the IPv6 OSPF 10 routing process does not contain a default-information originate line.
b. On ASBR, add a
default-information originate command to the OSPFv3 routing process.
ASBR# configure terminal ASBR2(config)# ipv6 router ospf 10 ABR2(config-router)# default-information originate
c. Check the IPv6 routing tables of ABR1 and ABR2 to see if the default route was discovered through OSPFv3.
Looking at the output of the
show ipv6 route, did the router learn of the default route from OSPFv3? If so, list the line or lines that signify this.
Yes. OE2 ::/0 [110/1] via FE80::7, Serial0/0/0.
Download 10.2.1 Packet Tracer – Troubleshoot Multiarea OSPFv3 PDF & PKA files: