Troubleshooting Redistribution Problems in OSPF

Troubleshooting Redistribution Problems in OSPF

This section describes problems related to redistribution in OSPF. When a router in OSPF does the redistribution, it becomes an ASBR. The routes that are redistributed into OSPF could be directly connected routes, static routes, or dynamically learned routes from another routing protocol or another OSPF process.

The following are problems that can happen during redistribution:

  • ASBR is not advertising redistributed routes.
  • OSPF is not installing external routes in the routing table.

The second problem already was discussed in the earlier section on OSPF routes installation problems. The first problem is discussed in the section that follows.

Problem: OSPF Neighbor Is Not Advertising External Routes

Whenever a route is known to be connected or static, or when any other routing protocol is redistributed into OSPF, an external LSA is generated for that route. If an OSPF router is not advertising the external route even after the redistribution, this indicates a problem on a router that is doing the redistribution. Mostly, the problem stems from configuration mistakes.

The most common causes of this problem are as follows:

  • The subnets keyword is missing from the ASBR configuration.
  • distribute-list out is blocking the routes.

Figure 9-80 shows a network experiencing this problem. In this figure, R1 is running RIP on Ethernet and redistributing RIP routes into OSPF.

OSPF Neighbor Is Not Advertising External Routes—Cause: Subnets Keyword Missing from the ASBR Configuration

When any protocol is redistributed into OSPF, if the networks that are being redistributed are subnets, you must define the subnets keyword under OSPF configuration. If the subnets keyword is not added, OSPF will ignore all the subnetted routes when generating the external LSA.

The situation could arise when connected or static routes are being redistributed into or out of OSPF. In that case, the same rule applies: The subnets keyword must be entered to redistribute subnetted routes.

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

Debugs and Verification
Example 9-224 shows the output of show ip ospf database external for 132.108.3.0. The output shows no LSA information, which means that R1 is not even originating the external LSA for 132.108.3.0.

Example 9-224 R1 Is Not Originating an External LSA for 132.108.3.0

Example 9-225 shows the OSPF configuration on R1. The configuration shows that redistri-bution of RIP is missing the subnets keyword.

Example 9-225 R1’s Configuration Is Missing the subnets Keyword for RIP Redistribution

Solution
To fix this problem, add the subnets keyword to the redistribution command. Example 9-226 shows the correct configuration that fixes this problem.

Example 9-226 Adding subnets Keyword in the Configuration of R1

After the subnets keyword has been added, OSPF redistributes all the routes that are subnetted; for example, 131.108.3.0 is a subnetted route with a mask of /24. Example 9-227 shows that R1 starts generating the external LSA for 132.108.3.0 and 132.108.4.0.

Example 9-227 Confirming That R1 Is Originating the External LSA for 132.108.3.0 and 132.108.4.0

OSPF Neighbor Is Not Advertising External Routes—Cause: distribute-list out Is Blocking the Routes

When distribute-list out is configured on an ASBR, the access list associated with the distri-bute list is examined and Type 5 external LSAs are originated for networks that are explicitly permitted in the distribute list. All other networks are denied, and no Type 5 external LSAs are generated for those networks.

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

Debugs and Verification
The first logical step is to look at the configuration. Note in the previous example that the subnets keyword was preventing the routes from being installed in the routing table. In this example, however, the distribute list is the culprit that is blocking 131.108.3.0 from getting redistributed into OSPF. Example 9-228 shows the configuration of R1, which has distribute-list out configured under OSPF, which is blocking 132.108.3.0 into the OSPF database.

Example 9-228 R1’s Distribute List Blocks the 132.108.3.0 Route from Being Installed in the OSPF Database

Example 9-229 shows that R1 is originating the Type 5 external LSA for 132.108.4.0 but not for 132.108.3.0 because 131.108.3.0 network implicitly is denied in access list 1.

Example 9-229 Determining External LSA Originated by R1

Solution
To solve this problem, you must either remove the distribute list so that R1 generates Type 5 external LSAs for all the RIP routes or modifies the distribute list so that it contains all the necessary networks for which Type 5 LSAs are required. This problem also can happen when using route maps instead of distribute lists. In any case, be sure to permit the desired network in the access list.

Example 9-230 shows the configuration of R1 that allows network 132.108.3.0 in the access list so that R1 generates the Type 5 external LSA for this network.

Example 9-230 Configuring R1’s Distribute List to Permit the 132.108.3.0 Network

After the access list is modified, check to see whether R1 starts generating the external LSA for 131.108.3.0. Example 9-231 shows that R1 starts generating the external LSA for network 132.108.3.0 after the necessary configuration changes.

Example 9-231 Verifying That R1 Now Generates an External LSA for 132.108.3.0

About the author

Prasanna

Leave a Comment