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:
- Mismatched MTU
- Corrupted link-state request
packet
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: - R3
is an ASBR and is redistributing RIP routes into OSPF.
- R4 is running RIP with R3.
- R4 is learning
200.200.200.0/24 through RIP.
- R2 is running OSPF with
R3.
- R2 is the ABR.
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: - Do
not summarize at the ABR.
- 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