10.2.1 Packet Tracer – Troubleshoot Multiarea OSPFv3 Answers
Packet Tracer – Troubleshoot Multiarea OSPFv3 (Answers Version)
Answers Note: Red font color or gray highlights indicate text that appears in the instructor copy only.
Addressing Table
Device |
Interface |
IPv6 Global Unicast Address |
IPv6 Link-local Address |
ISP |
GigabitEthernet0/0 |
2001:db8:c1:1::1/64 |
fe80::c1 |
ASBR |
GigabitEthernet0/0 |
2001:db8:c1:1::2/64 |
fe80::7 |
ASBR |
Serial0/0/0 |
2001:db8:a8ea:f0a::1 |
fe80::7 |
ASBR |
Serial0/0/1 |
2001:db8:a8ea:f0b::1 |
fe80::7 |
ABR1 |
Serial0/0/0 |
2001:db8:a8ea:f0a::2 |
fe80::5 |
ABR1 |
GigabitEthernet0/1 |
2001:db8:a8ea:1a::1 |
fe80::5 |
ABR2 |
Serial0/0/1 |
2001:db8:a8ea:f0b::2 |
fe80::6 |
ABR2 |
GigabitEthernet0/1 |
2001:db8:a8ea:2a::1 |
fe80::6 |
R1 |
GigabitEthernet0/1 |
2001:db8:a8ea:1a::2 |
fe80::1 |
R1 |
GigabitEthernet0/0 |
2001:db8:a8ea:1c::1 |
fe80::1 |
R1 |
Loopback0 |
2001:db8:a8ea:1b::1 |
fe80::1 |
R2 |
GigabitEthernet0/0 |
2001:db8:a8ea:1c::2 |
fe80::2 |
R2 |
Loopback1 |
2001:db8:a8ea:1d::1 |
fe80::2 |
R3 |
GigabitEthernet0/1 |
2001:db8:a8ea:2a::2 |
fe80::3 |
R3 |
GigabitEthernet0/0 |
2001:db8:a8ea:2b::1 |
fe80::3 |
R4 |
GigabitEthernet0/0 |
2001:db8:a8ea:2b::2 |
fe80::4 |
R4 |
GigabitEthernet0/1 |
2001:db8:a8ea:2c::1 |
fe80::4 |
Objectives
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.
Instructions
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.
- 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.
Question:
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?
Type your answers here.
The R2 OSPFv3 routing process is enabled and the interfaces are configured for area 1.
- 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.
Question:
Is the R1 OSPFv3 routing process configuration present and correct? Has OSPFv3 been activated on the G0/0 interface and set to Area1?
Type your answers here.
Yes.
- 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
Question:
Is there a mismatch or incorrect configuration on either the R1 or R2 hello-interval or dead-interval timers?
Type your answers here.
Yes, the R2 interface G0/0 timers are mismatched and incorrect.
- 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
Question:
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?
Type your answers here.
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.
- 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.
Question:
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?
Type your answers here.
The ABR2 OSPFv3 routing process has been enabled, but a router-id has not been set. The interfaces have been configured correctly.
- 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
Question:
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?
Type your answers here.
Yes, there are successful adjacency changes with Nbr 7.7.7.7 and Nbr 3.3.3.3.
- 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
Question:
Look at the output of the show ipv6 ospf database command. What information would signal the presence of R4?
Type your answers here.
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.
- 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.
Question:
Is there an IPv6 default route configured on ASBR? Does the OSPFv3 routing process configuration have a default-information originate line present?
Type your answers here.
Yes ASBR has an ipv6 default route to ::/0, but the IPv6 OSPF 10 routing process does not contain a default-information originate line.
- 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
- Check the IPv6 routing tables of ABR1 and ABR2 to see if the default route was discovered through OSPFv3.
Question:
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.
Type your answers here.
Yes. OE2 ::/0 [110/1] via FE80::7, Serial0/0/0.