Packet Tracer – Troubleshoot Multiarea OSPFv3 (Instructor Version)
Instructor Note: Red font color or gray highlights indicate text that appears in the instructor copy only.
Topology
Addressing Table
Objectives
- 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.
Instructor Note: Refer to the Instructor Lab Manual for the procedures to initialize and reload devices.
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?
R2’s OSPFv3 routing process is enabled and the interfaces are configured for area 1.
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?
Yes.
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, R2’s 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 1.1.1.1.
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?
ABR2’s 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 6.6.6.6 router-id.
ABR2# configure terminal ABR2(config)# ipv6 router ospf 10 ABR2(config-router)# router-id 6.6.6.6
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 7.7.7.7 and Nbr 3.3.3.3.
c. On ABR2, a Syslog message showing an adjacency change from LOADING to FULL with Nbr 3.3.3.3 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?
The router-id 4.4.4.4 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.
