8.2.1 Packet Tracer – Troubleshoot Multiarea OSPFv2 Answers

• Recommend

Packet Tracer – Troubleshoot Multiarea OSPFv2 (Answers Version)

Answers Note: Red font color or gray highlights indicate text that appears in the instructor copy only.

Addressing Table

Objectives

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. You must troubleshoot the problem, fix the multiarea OSPFv2 implementation, and restore communication throughout the network. To do this, use the Addressing Table. In Area 1, communication to the 192.168.4.0/24 network is down, and 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.

Instructions

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.

1. Because R2 is not forming an adjacency with R1, open a terminal 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 OSPF router process configuration present and correct? Are the network statements, including subnets, wildcard bits and area numbers correct?

Type your answers here.

The R2 OSPF routing configuration appears to be correct.

2. 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.

Question:

Is the R2 hello timer interval configuration set to the default setting? Is the dead time interval 4 x the hello time interval? Are hellos being sent?

Type your answers here.

The R2 timer interval configuration is default at hello 10 and dead 40. Hellos are being sent.

3. If the R2 configuration and settings are correct, then the problem of not forming and adjacency must lay with R1. Open a terminal on R1 and check the network interface and OSPFv2 configurations in the running-configuration.

Question:

Are the R1 network interfaces configured correctly? Is there a problem in the R1 OSPFv2 routing process configuration that would cause an adjacency failure?

Type your answers here.

The R1 interfaces are configured correctly. R1’s OSPFv2 routing process has a passive-interface command configured on interface G0/0.

4. Correct the configuration error on R1.

R1# configure terminal

R1(config)# router ospf 1

R1(config-router)# no passive-interface G0/0

5. If the problem has been corrected, R1 should receive a syslog message to the console showing an OSPF adjacency change from loading to full.

Question:

Did a syslog message appear in the R1 console reporting an OSPF adjacency change?

Type your answers here.

Yes, the syslog message was: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL.

Step 2:Check the router configurations in Area 2.

1. 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.

Question:

Does the ABR2 routing table show the presence of the 172.16.1.64/24 and 172.16.1.96/24 networks?

Type your answers here.

No.

2. Check to see if ABR2 has established an OSPFv2 neighbor adjacency with R3.

Question:

Does ABR2 show two OSPF neighbors? Which neighbor ID signifies R3 and how do you know this?

Type your answers here.

Yes. ABR2 shows two neighbors with neighbor IDs 3.3.3.3 and 7.7.7.7. R3 is neighbor ID 3.3.3.3 because it shows it is connected on interface G0/1.

3. Because ABR2 has formed a neighbor relationship with R3, the problem may lay with the OSPFv2 configurations on either R3 or R4. Open a console on R3 and check the OSPFv2 configurations in the running-configuration.

Question:

Are there any problems with the R3 OSPFv2 routing process configurations?

Type your answers here.

Yes, the network statement for the 172.16.1.64 network is incorrectly configured in Area 0 instead of Area 2.

4. 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

Question:

Did a syslog message appear in the R3 console reporting an OSPF adjacency change? What does this signify?

Type your answers here.

Yes, the syslog message was: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on GigabitEthernet0/0 from LOADING to FULL. This signifies that an adjacency was formed with R4.

5. Verify that the R3 routing table has routes to all of the networks in all of the OSPF areas.

Question:

Are any routes missing? If so, which ones?

Type your answers here.

Yes, the routes to the 192.168.x.x networks are missing.

6. 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.

Question:

R3# configure terminal

R3(config)# no router ospf 1

R3(config)# router ospf 1

R3(config-router)# router-id 3.3.3.3

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

7. Now verify that the R3 routing table has learned the OSPF interarea summary route to the 192.168.0.0/21 subnet.

Question:

Is the OSPF interarea route to the 192.168.0.0/21 subnet in the routing table?

Type your answers here.

Yes

• Recommend