translating the unicast. The debug ip ospf adj command can help diagnose these problems, as shown in Figure , which indicates an MTU interface mismatch. OSPF Stuck in LOADING
In the LOADING state, routers send link-state request packets. During the adjacency, if a router receives an outdated or missing link-state advertisement (LSA), it requests that LSA by sending a link-state request packet. Neighbors that do not transition beyond this state are most likely exchanging corrupted LSAs. This problem is usually accompanied by a "%OSPF-4-BADLSA" console message. Since this is not a common problem, it is recommend that the network administrator contacts the Cisco TAC. If a neighbor does not reply or a neighbor reply never reaches the local router, the router will also be stuck in the LOADING state. The most common possible causes of the problem are: The output of show ip ospf neighbor indicates that the R2 neighbor is stuck in LOADING. The debug ip ospf adj command can help diagnose these problems. Command output can indicate an MTU interface mismatch. Command output can also indicate a possible problem due to packet corruption.
Content 5.7 Troubleshooting OSPF 5.7.3 One side of point-to-point link is unnumbered Figure shows a network setup in which the R1 serial link is unnumbered to loopback interface, while the R2 serial link is numbered. When OSPF creates a router LSA for point-to-point links, it adheres to the following rule to fill the Link ID and Link Data fields within the router LSA. The Link Data field for unnumbered point-to-point links should have a MIB-II Index value. Because the link data value of the numbered interface does not match that of the unnumbered interface, this creates a discrepancy in the OSPF database. Debugs and Verification
Figure shows the discrepancy in the OSPF database. The R1 router LSA shows the MIB-II IfIndex value in the Link Data field for Serial 0, while the R2 router LSA shows the router serial interface in the Link Data Field. Figure shows the configuration on both R1 and R2, with the R1 serial interface unnumbered to a loopback address, and the R2 serial interface numbered. Solution
To fix this problem, both sides need to be either a numbered point-to-point link or an unnumbered point-to-point link. Figure shows the new configuration that solves this problem.
Content 5.7 Troubleshooting OSPF 5.7.4 ABR not generating Type 4 summary LSA One of the functions of a Type 4 summary LSA is to announce the reachability of an ASBR to other areas. The Type 4 LSA is not required if the ASBR exists in the same area. The ASBR does not generate the Type 4 summary LSA if it is not connected to area 0. To generate a summary LSA of Type 3 or Type 4, a router must have a connection to area 0. As a result, the external routes will not be installed in the network. Figure shows a network in which R3 redistributes RIP routes into OSPF. Figure shows that R1 is not installing the external route 200.200.200.0/24 into the routing table. Debugs and Verification
The output of show ip ospf database external command in Figure shows that the route exists in the external OSPF database of router R1. However, the output of show ip ospf database asbr-summary command in Figure shows that there is no Type 4 LSA for this route. The next logical step is to go on the ABR and see if it is indeed an ABR. If it is an ABR it will generate a summary LSA of Type 3 or Type 4. If it is not an ABR, it will not generate that summary. The output of the show ip ospf command in Figure shows that router R2, which is between two areas and may look like an ABR, is not identifying itself as an ABR. If R2 were an ABR, the output would display that is an “Area Border Router.” Note: All areas in an OSPF autonomous system must be physically or virtually connected to the backbone area (area 0). For a router to be an ABR, one of its interfaces must be part of area 0. Solution
In this example, router R2 does not generate the Type 4 summary LSA because it is not connected to area 0. To generate a summary LSA of Type 3 or Type 4, a router must have a connection into area 0. To solve this problem, router R2 must be connected to area 0, either physically or virtually by creating a virtual link, as shown in Figure . By configuring a virtual link on R2, the router is now virtually connected to area 0; therefore, it now considers itself an ABR. After connecting R2 to area 0, the output of show ip ospf shows that it is now an ABR. After the configuration change on R2, as shown in Figure , R1 is now generating a Type 4 summary LSA into area 3. Because the Type 4 LSA is now being received, R1 installs the external route 200.200.200.0/24 into its routing table.
Content 5.7 Troubleshooting OSPF 5.7.5 Forwarding address is not known through the intra-area or interarea route When OSPF learns an external LSA, it makes sure that the forwarding address is known through an OSPF intra-area or interarea route before it installs the route into the routing table. In accordance with the RFC 2328 standard, if the forwarding address is not known through an intra-area or interarea route, OSPF will not install the route in the routing table. Figure shows a network with the following specifications: The network is experiencing a problem of external routes not getting installed in the routing table. Figure shows the output of show ip route for 200.200.200.0/24 on router R1. This network resides in a RIP domain. Because RIP is being redistributed into OSPF on router R3, all OSPF routers should see this external OSPF route. However, router R1 is not seeing it in its routing table. Debugs and Verification
Figure shows the external LSA for 200.200.200.0/24 on R1. The output of the show ip ospf database external command shows that the external LSA exists in the OSPF database, but the route is still not being installed in the routing table. Note the forwarding address involved in this external LSA. Figure shows that the route to the forwarding address of 131.108.0.4, is known through an OSPF external route. The ABR is summarizing 131.108.0.0/24 with the area range command, so the more specific intra-area routes are summarized into one route. This range summarizes all routes under the 131.108.0.0/26 range. Figure shows that the ASBR is doing the redistribution from RIP into OSPF. It also shows that the connected networks in the range of 131.108.0.0/26 are being redistributed into OSPF because RIP owns those connected routes. This configuration redistributes 131.108.0.4/26, which is a connected interface on router R3. This subnet covers the forwarding address that appeared in Figure . Router R1 is seeing the forwarding address learned through OSPF external because R3 has redistribute connected under router ospf. This leaks a more specific route for the connected interfaces of R3. This also includes the forwarding address and subnet, which is 131.108.0.4/26. Also, the intra-area route for this subnet is suppressed by R2 because R2 is summarizing 131.108.0.0/16. Because the more specific route is always preferred, R1 prefers the more specific external route of 131.108.0.4/26 over the less specific summarized route of 131.108.0.0/16. Solution
The problem can be solved in one of two ways:
  1. Do not summarize at the ABR.
  2. Filter the connected subnet from being redistributed into OSPF at the ASBR.
To implement the first solution, remove the area range command on the ABR. To implement the second solution, add a filter to control the redistributed routes on the ASBR. A