Lab – Troubleshoot Multiarea OSPFv3
Troubleshoot a multiarea OSPFv3 network.
Background / Scenario
A large organization has recently decided to implement a multiarea OSPFv3 network. As a result, the network is no longer functioning correctly and communication through much of the network has failed. As a network administrator you must troubleshoot the problem, fix the multiarea OSPFv3 implementation, and restore communication throughout the network. To do this, you are given the Addressing Table above, showing all of the routers in the network including their interface IPv6 addresses. You are told that in Area 1, R2 is unable to form OSPF adjacencies. In Area 0 and Area 2, three routers ABR2, R3 and R4 have not been able to form OSPF adjacencies. Lastly, ABR1 and R1 have not received default route information.
Part 1: Use Show Commands to Troubleshoot OSPFv3 Area 1
In Part 1, using the particular symptoms of network failure reported in the Background / Scenario 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, console into R2 and check its interface IP address configuration and its multiarea OSPFv2 configuration. Use the show running-config command to view the configuration.
Is R2’s 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?
b. If R2’s OSPFv3 configurations are correct, it is possible that OSPFv3 has not been configured on the R1 G0/0 interface. Console into R1 and issue a show running-config command to check the G0/0 interface for the ipv6 ospf 10 area 1 configuration.
Is R1’s 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?
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?
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, console into the ABR2 border router to see why it is unable to form an adjacency with ASBR router.
Is ABR2’s 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?
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 184.108.40.206 router-id.
ABR2# configure terminal ABR2(config)# ipv6 router ospf 10 ABR2(config-router)# router-id 220.127.116.11
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?
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
Looking at the output of the show ipv6 ospf database command, what information would signal the presence of R4?
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?
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.