Last Updated on April 23, 2018 by InfraExam
10.2.4.3 Packet Tracer – Troubleshoot Multiarea OSPFv2
Packet Tracer – Troubleshoot Multiarea OSPFv2 (Answer Version)
Answer Note: Red font color or gray highlights indicate text that appears in the Answer copy only.
|Device||Interface||IP Address||Subnet Mask|
Troubleshoot a multiarea OSPFv2 network.
Background / Scenario
A large organization has recently decided to change the network from single-area OSPFv2 to multiarea OSPFv2. 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 OSPFv2 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 IP addresses and subnet masks. You are told that in Area 1 communication to the 192.168.4.0/24 network is down and that router R2 is unable to form an OSPF adjacency with router R1. In Area 2, communication to the 172.16.1.64/27 and 172.16.1.96/24 networks has been lost and router R4 is unable to form an adjacency. Area 0 is behaving as expected.
Answer Note: Refer to the Answer Lab Manual for the procedures to initialize and reload devices.
Part 1: Use Show Commands to Troubleshoot OSPFv2 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 router configurations 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 OSPF router process configuration present and correct? Are the network statements, including subnets, wildcard bits and area numbers correct?
R2’s OSPF routing configuration appears to be correct.
b. On R2, issue a show ip ospf interface command to check the hello timer interval configuration and to verify that hello messages are being sent.
Is R2’s hello timer interval configuration set to the default setting? Is the dead time interval 4 x the hello time interval? Are hellos being sent?
R2’s timer interval configuration is default at hello 10 and dead 40. Hellos are being sent.
c. If R2’s configurations and settings are correct then the problem of not forming and adjacency must lay with R1. Console into R1 and check the network interface and OSPFv2 configurations in the running-configuration.
Are the R1 network interfaces configured correctly? Is there a problem in the R1 OSPFv2 routing process configuration that would cause an adjacency failure?
R1’s interfaces are configured correctly. R1’s OSPFv2 routing process has a passive-interface command configured on interface G0/0.
d. Correct the configuration error on R1.
R1# configure terminal R1(config)# router ospf 1 R1(config-router)# no passive-interface G0/0
e. If the problem has been corrected, R1 should receive a syslog message to the console showing an OSPF adjacency change from loading to full.
Did a syslog message appear in the R1 console reporting an OSPF adjacency change?
Yes, the syslog message was: %OSPF-5-ADJCHG: Process 1, Nbr 188.8.131.52 on GigabitEthernet0/0 from LOADING to FULL.
Step 2: Check the router configurations in Area 2.
a. Because it was reported that the network has lost contact with the Area 2 subnets 172.16.1.64/24 and 172.16.1.96/24, verify this at the Area 2 Border Router (ABR2) using the show ip route command.
Does the ABR2 routing table show the presence of the 172.16.1.64/24 and 172.16.1.96/24 networks?
b. Check to see if ABR2 has established an OSPFv2 neighbor adjacency with R3.
Does ABR2 show two OSPF neighbors? Which neighbor ID signifies R3 and how do you know this?
Yes. ABR2 shows two neighbors with neighbor IDs 184.108.40.206 and 220.127.116.11. R3 is neighbor ID 18.104.22.168 because it shows it is connected on interface G0/1.
c. Because ABR2 has formed a neighbor relationship with R3, the problem may lay with the OSPFv2 configurations on either R3 or R4. Console into R3 and check the OSPFv2 configurations in the running-configuration.
Are there any problems with the R3 OSPFv2 routing process configurations?
Yes, the network statement for the 172.16.1.64 network is incorrectly configured in Area 0 instead of Area 2.
d. To correct the problem, replace the OSPF routing process network statement that places the 172.16.1.64/24 subnet in Area 0 and change it to Area 2.
R3# configure terminal R3(config)# router ospf 1 R3(config-router)# no network 172.16.1.64 0.0.0.31 area 0 R3(config-router)# network 172.16.1.64 0.0.0.31 area 2
Did a syslog message appear in the R3 console reporting an OSPF adjacency change? What does this signify?
Yes, the syslog message was: %OSPF-5-ADJCHG: Process 1, Nbr 22.214.171.124 on GigabitEthernet0/0 from LOADING to FULL. This signifies that an adjacency was formed with R4.
e. Verify that the R3 routing table has routes to all of the networks in all of the OSPF areas.
Are any routes missing? If so, which ones?
Yes, the routes to the 192.168.x.x networks are missing.
f. It appears that R3 is missing the OSPFv2 interarea 192.168.0.0/21 summary route. To solve this problem, completely remove the OSPFv2 routing process from router R3 and then re-add it.
R3# configure terminal R3(config)# no router ospf 1 R3(config)# router ospf 1 R3(config-router)# router-id 126.96.36.199 R3(config-router)# network 172.16.1.32 0.0.0.31 area 2 R3(config-router)# network 172.16.1.64 0.0.0.31 area 2
g. Now verify that the R3 routing table has learned the OSPF interarea summary route to the 192.168.0.0/21 subnet.
Is the OSPF interarea route to the 192.168.0.0/21 subnet in the routing table?