Troubleshooting OSPF Route Installation

Troubleshooting OSPF Route Installation

This section discusses the problems related to route installation. This means that OSPF routers have fully synchronized their databases with those of their neighbors but are not installing routes in the routing table.

After the route is in the database, there can be several reasons that the route is not installed in the database. This section discusses those reasons in detail and also tells how to solve these kinds of problems.

The most common reasons for OSPF failing to install routes in the routing table are as follows:

  • OSPF is not installing any routes in the routing table.
  • OSPF is not installing external routes in the routing table.

Problem: OSPF Not Installing Any Routes in the Routing Table

This is also a common problem in OSPF to find routes in the database but not in the routing table. When OSPF finds any kind of discrepancy in the database, it does not install any routes in the routing table. This section assumes that the sender is advertising the routes in the database. If the sender is not advertising the routes, or if the route is not even present in the database, troubleshoot that problem first. This was discussed in the previous section, for troubleshooting when OSPF is not advertising routes.

The most common possible causes of this problem are as follows:

  • The network type is mismatched.
  • IP addresses are flipped in dual serial-connected routers or a subnet/mask mismatch has occurred.
  • One side is a numbered and the other side is an unnumbered point-to-point link.
  • A distribute list is blocking the routes’ installation.
  • There is a broken PVC in a fully meshed Frame Relay network with the broadcast network type.

Figure 9-66 shows a network setup that produces the OSPF route installation problem. The cloud in the middle is irrelevant. It could be Frame relay, PPP HDLC, or something else, but it must be a point-to-point WAN link in this scenario.

Troubleshooting OSPF Route Installationfig9.66

Example 9-183 shows that R2 is not installing any routes in the routing table.

Example 9-183 R2 Has No Routes in Its Routing Table

OSPF Not Installing Any Routes in the Routing Table—Cause: Network Type Mismatch

A mismatched network type produces a discrepancy in the database, and OSPF will not install those routes in the routing table. This situation is common in NBMA networks in which one side has a point-to-point network type and the other side has a broadcast network type. This problem also occurs if one side is defined as a point-to-multipoint network and the other side is left as nonbroadcast.

In this example, one side is defined as broadcast and the other side is defined as point-to-point. When an interface network type is defined as broadcast, OSPF considers that link to be a transit link and puts that link in its router LSA as a transit link.

Figure 9-67 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.67

Debugs and Verification
Example 9-184 shows the interface configuration on both R1 and R2. The R1 serial interface network type is broadcast, while R2 uses the default network type, which is nonbroadcast.

Example 9-184 Network Types for R1 and R2

Example 9-185 shows the output of show ip ospf interface for the Serial 0 interface of both routers, which shows that there is a network type mismatch on both ends.

Example 9-185 Determining Whether R1 and R2 Have a Network Type Mismatch on the Serial 0 Interfaces

Example 9-186 shows the output of router LSAs on each router. The router LSA is complaining that the advertising router is unreachable. This is why the routers are not installing routes in the routing table.

Example 9-186 LSAs for R1 and R2 Indicate That the Advertising Router Is Unreachable

Solution
In this example, one side of a link is shown as a point-to-point link in the database, and the other side of the same link is shown as a transit link. This creates a discrepancy in the database and the router will not install anything in the routing table.

To fix this problem, change the network type of R1 back to its default, which is point-to-point. Example 9-187 shows how to change the network type back to point-to-point on R1.

Example 9-187 Changing Network Type Back to Point-to-Point

Example 9-188 shows the output of show ip ospf interface for the serial interface. It shows that the network type is point-to-point.

Example 9-188 Verifying That R1’s Serial 0 Interface Is of Network Type Point-to-Point

OSPF Not Installing Any Routes in the Routing Table—Cause: IP Addresses Are Flipped in Dual Serial-Connected Routers

The IP addressing on dual serial interfaces can cause this problem. OSPF forms a FULL adjacency because the neighbor is still reachable, but this creates a discrepancy in the OSPF database.

This also can happen when the wrong IP subnet or mask is assigned on one side. This creates a discrepancy in the OSPF database.

Figure 9-68 shows a network setup in which the addresses on the serial interfaces are flipped; for example, R1’s Serial 0 address is 131.108.1.1/24. The other end of this interface goes into Serial 0 of R2, which has the 131.108.2.1/24 address defined under Serial 0. A similar thing can be observed with the Serial 1 interface. This obviously looks like the addresses are flipped.

Troubleshooting OSPF Route Installationfig9.68

Example 9-190 shows that R2 is not installing any routes in the routing table because of the discrepancy in the database.

Example 9-190 R2 Is Not Installing Any OSPF Routes in Its Routing Table

Figure 9-69 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.69

Debugs and Verification
Example 9-191 shows the output of show ip ospf neighbor, which shows that OSPF is forming FULL adjacency on both serial links. The address column shows that the neighbor address and interface do not match. For example, in Example 9-191, R2 has two neighbors. Because R2’s Serial 0 address is in the range 131.108.2.0/24, as shown in Figure 9-68, the neighbor address on Serial 0 also should be in the same range, but it shows 131.108.1.1 as a neighbor on Serial 0.

Example 9-191 show ip ospf neighbor Command Output Indicates OSPF Adjacency Formation on R1’s Serial Links

Solution
To fix this problem, assign the IP address on the correct corresponding interface. Either change R1’s IP addresses on its serial links or change R2’s IP addresses on its serial links. In this example, R2’s serial links have been changed to match R1’s. Serial 0 IP addresses and Serial 1 IP addresses have been swapped, as shown in Example 9-192.

Example 9-192 Changing IP Addresses on R2’s Serial Links

Example 9-193 shows that after fixing this problem, R2 installs OSPF routes in its routing table.

Example 9-193 R2’s Routing Table Indicates That the Problem Has Been Resolved

OSPF Not Installing Any Routes in the Routing Table—Cause: One Side Is a Numbered and the Other Side Is an Unnumbered Point-to-Point Link

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 (see Table 9-1).

Table 9-1. Link ID and Link Data Values for OSPF Point-to-Point Numbered and Unnumbered Links Type Description Link ID Link Data
1 Point-to-point Numbered Neighbor’s router ID Interface IP address
1 Point-to-point Unnumbered Neighbor’s router ID MIB-II ifIndex value

Table 9-1 shows that the Link Data field for unnumbered point-to-point links should have an MIB-II ifIndex value. Because the link data value of the numbered interface does not match that of the unnumbered interface, this creates the discrepancy in the OSPF database.

Figure 9-70 shows a network setup in which the R1 serial link is unnumbered to a loopback interface, while the R2 serial link is numbered.

Troubleshooting OSPF Route Installationfig9.70

Figure 9-71 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.71

Debugs and Verification
Example 9-194 shows the discrepancy in the OSPF database. R1’s router LSA shows the MIB-II IfIndex value in the Link Data field for Serial 0, while R2’s router LSA shows the router’s serial interface address in the Link Data field.

Example 9-194 Checking the OSPF Database for a Discrepancy

Example 9-195 shows the configuration on both R1 and R2, which shows that R1’s serial interface is unnumbered to a loopback address, while R2’s serial interface is numbered.

Example 9-195 Serial Interface Configurations for R1 and R2

Solution
To fix this problem, make sure that both sides are either a numbered point-to-point link or an unnumbered point-to-point link. Example 9-196 shows the new configuration that fixes this problem. In this example, R1’s serial interface is assigned an IP address.

Example 9-196 Assigning an IP Address on R1’s Serial 0 Interface, Which Was Unnumbered Before

Example 9-197 shows that R2 installs routes in the routing table after this problem is fixed.

Example 9-197 Confirming OSPF Route Installation

OSPF Not Installing Any Routes in the Routing Table—Cause: Distribute List Is Blocking the Route Installation

OSPF is a link-state protocol. When it forms an adjacency with any neighbor, it synchronizes its database with that neighbor. Because of its link-state nature, filtering in OSPF is not possible.

Configuring distribute-list in prevents OSPF routes from being installed in the routing table. This doesn’t mean that the routes disappear from the OSPF database. It simply means that before OSPF installs the route into the routing table, it checks for the distribute list and installs only those networks that are permitted in the distribute list. However, it keeps the routes in the database.

Figure 9-72 shows a network setup in which OSPF is not installing any routes in the routing table. Specifically, Router 2 is not seeing any OSPF routes in its routing table.

Troubleshooting OSPF Route Installationfig9.72

Figure 9-73 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.73

Debugs and Verification
Example 9-198 shows the configuration on R2, which shows that R2 has distribute-list in configured and is not installing any OSPF routes in the routing table. Access list 1, which is used in the distribute list, allows only the 10/8 and 20/8 networks to be installed in the routing table. The remaining networks are implicitly denied. Example 9-198 also shows that the 131.108.3.0 network is not in the routing table because it is denied by the distribute list.

Example 9-198 R2 Configuration with a Distribute List

Solution
If a network is in the database but not in the routing table, make sure that the network is permitted in the distribute list.

Example 9-199 shows the new configuration that fixes this problem. In this configuration, network 131.108.3.0 is permitted.

Example 9-199 Configuring R2’s Distribute List to Permit the 131.108.3.0/24 Network

Example 9-200 shows that network 131.108.3.0/24 appears in the routing table after fixing the configuration on R2.

Example 9-200 Confirming That the 131.108.3.0 Route Is Installed

OSPF Not Installing Any Routes in the Routing Table—Cause: Broken PVC in a Fully Meshed Frame Relay Network with Broadcast Network Type

The OSPF network type broadcast should never be defined on a medium that is not fully meshed. Sometimes, the medium is fully meshed but the Layer 2 connectivity is not stable. In that case, when Layer 2 is broken, it creates an inconsistency and the medium becomes non–fully meshed again.

Figure 9-74 shows a network experiencing this problem. Before the PVC between R1 and R2 was broken, R2 was a DR and R3 was a BDR.

Troubleshooting OSPF Route Installationfig9.74

Example 9-201 shows that R1 is not installing any routes in the routing table.

Example 9-201 R1 Is Not Installing Any Routes

Figure 9-75 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.75

Debugs and Verification
Example 9-202 shows the configuration on R1, R2, and R3. The configuration shows that the network type is broadcast on all routers for the Frame Relay cloud.

Example 9-202 Confirming the Network Type on R1, R2, and R3

Example 9-203 shows the output of show ip ospf neighbor on all three routers. The output on R1 shows that it considers R2 to be the DR. However, the actual DR is R3, as shown in Figure 9-74, because it has the highest router ID. Because the link between R1 and R3 is broken, R1 declares R2 to be the DR.

Example 9-203 Determining the Designated Router

Example 9-204 shows the router LSA output on R1 displaying the router LSA for R1, R2, and R3. R1 still considers R2 the DR instead of R3. R1 shows that the Frame Relay link is a stub link because it couldn’t find any network LSA generated by R2 in the database. This Frame Relay link is defined as a transit link in both R2 and R3’s database. This creates a discrepancy in the OSPF database.

Example 9-204 OSPF Database on R1, R2, and R3 Shows Discrepancy

Solution
The solution in this case is to run a point-to-multipoint network type. With a point-to-multipoint network type, the flooding increases because no DR/BDR elected. If there is any connectivity problem, however, it will not create any black holes.

So, a trade-off exists between reliability and increased flooding. Selecting a point-to-multipoint network type over unstable Frame Relay links provides reliability, while selecting a broadcast net-work type creates inconsistencies whenever any Layer 2 instability occurs.

Example 9-205 shows the new configuration changes on R1, R2, and R3. The network type is now point-to-multipoint.

Example 9-205 Configuring R1, R2, and R3 with Point-to-Multipoint Interfaces

Example 9-206 shows that R1 starts learning OSPF routes from R2 after the configuration changes.

Example 9-206 Confirming That R1 Is Learning OSPF Routes from R2

Problem: OSPF Not Installing External Routes in the Routing Table

When OSPF redistributes any routes, whether connected, static, or from a different routing protocol, it generates a Type 5 LSA for those external routes. These Type 5 LSAs are flooded into every OSPF router, with the exception of those in stub and NSSA areas. Sometimes, the problem is that the external routes are in the OSPF database but are not being installed in the routing table.

The most common causes of this problem are as follows:

  • The forwarding address is not known through the intra-area or interarea route.
  • The ABR is not generating Type 4 summary LSAs.

OSPF Not Installing External Routes in the Routing Table—Cause: 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 it into the routing table. If the forwarding address is not know through an intra-area or interarea route, OSPF will not install the route in the routing table. This is in accordance with the RFC 2328 standard.

Figure 9-76 shows a network with the following specifications:

Troubleshooting OSPF Route Installationfig9.76

shows the output of show ip route for 200.200.200.0. This network resides in a RIP domain. Because RIP is being redistributed into OSPF on R3, all OSPF routers should see this router as OSPF external. However, R1 is not seeing this route in its routing table.

Example 9-207 R1 Is Missing RIP Route of 200.200.200.0 in Its Routing Table

Figure 9-77 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.77

Debugs and Verification
Example 9-208 shows the external LSA for router 200.200.200.0. The external LSA exists in the OSPF database, but the route still is not being installed in the routing table. Also, there is a forwarding address involved in this external LSA.

Example 9-208 External LSA Database for RIP Route 200.200.200.0

Example 9-209 shows that the route to the forwarding address is known through an OSPF external route.

Example 9-209 Route to the Forwarding Address Is Known Through an OSPF External Route

Example 9-210 shows that the ABR is summarizing 131.108.0.0/24 with an area range com-mand, so the more specific intra-area routes are summarized into one route. This range summarizes all routes under the 131.108.0.0/16 range.

Example 9-210 R2 Summarizes the Intra-area Routes as 131.108.0.0/24

Example 9-211 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 R3. This subnet covers the forwarding address that appeared in Example 9-209.

Example 9-211 R3 Redistributes RIP Routes in the 131.108.0.0/26 Range into OSPF

Solution
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 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 always is 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.

This problem can be solved in 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, go to the ABR and remove the area range command.

Example 9-212 shows the new configuration on ABR that solves this problem.

Example 9-212 Removing Summarization Capabilities at the ABR

To implement the second solution, go to the ASBR and add a filter to control redistributed routes.

Example 9-213 shows the new configurations that fix this problem. The filter actually prevents the route 131.108.0.0/26 from getting redistributed into OSPF as an external route because only 200.200.200.0 is permitted; all other routes are denied.

Example 9-213 Configuring the ASBR to Filter Connected Routes

Example 9-214 shows that after fixing this problem, R1 starts installing the routes in the routing table because the forwarding address is now known through an OSPF interarea route.

Example 9-214 Confirming That External Routes Are Being Installed Again on R1

Also, Example 9-215 shows that the forwarding address is now known through OSPF interarea instead of OSPF external.

Example 9-215 Forwarding Address Is Now Known Through OSPF Interarea

OSPF Not Installing External Routes in the Routing Table—Cause: 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 the other areas. This Type 4 LSA is not required if the ASBR exists in the same area.

The ASBR doesn’t generate the Type 4 summary LSA if it’s 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. As a result, the external routes will not be installed in the network. Chapter 8 covers Type 3 and Type 4 LSAs in greater detail.

Figure 9-78 shows a network in which R3 redistributes RIP routes into OSPF.

Troubleshooting OSPF Route Installationfig9.78

shows that R1 is not installing the external route 200.200.200.0/24 into the routing table.

Example 9-216 R1 Not Installing External Route 200.200.200.0

Figure 9-79 shows the flowchart to follow to solve this problem.

Troubleshooting OSPF Route Installationfig9.79

Debugs and Verification
Example 9-217 shows that the route exists in the external database.

Example 9-217 Confirming That Route 200.200.200.0 Exists in the External OSPF Database

The next logical step is to go on the ABR and see if it is indeed an ABR. If it does not consider itself an ABR, it will not generate any summary LSA of Type 3 or Type 4. Example 9-219 shows that R2 is not identifying itself as an ABR in the output of show ip ospf. If R2 were an ABR, the output would display “It’s an area border router.”

Example 9-219 R2 Doesn’t Acknowledge Itself as an ABR

Solution
In this example, R2 doesn’t generate the Type 4 summary LSAs 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, connect R2 to area 0 either physically or virtually by creating a virtual link, as shown in Example 9-220. To read more about virtual links, refer to Chapter 8.

Example 9-220 Configuring Virtual Link Between R2 and R1

By configuring a virtual link on R2, the router is now virtually connected to area 0; therefore, it now considers itself an ABR. Example 9-221 shows that after connecting R2 to area 0, the output of show ip ospf shows that it is an ABR. Compare this output to Example 9-219, in which the router doesn’t consider itself as an ABR.

Example 9-221 Confirming That R2 Is Now Aware of Its ABR Status

Now, get on R1 again and see if the Type 4 LSA is being received. Example 9-222 shows that after the configuration changes on R2, it has started generating Type 4 summary LSAs into area 3.

Example 9-222 R2 Now Generates Type 4 LSAs into Area 2, and R1 Receives It

Because the Type 4 LSA now is being generated, R1 installs the external routes in its routing table. Example 9-223 shows that after fixing this problem, the external route 200.200.200.0/24 is in the routing table of R1.

Example 9-223 External Route 200.200.200.0 Is Now in R1’s Routing Table

About the author

Prasanna

Leave a Comment