route-map is added to the redistribute rip command, as shown in Figure to prevent the route 131.108.0.0/26 from getting redistributed into OSPF, permitting only the 200.200.200.0/24 route. Figures and show the changes in the R1 routing table for the external 200.200.200.0/24 route and that the forwarding address is now known through OSPF interarea instead of OSPF external.
Content 5.7 Troubleshooting OSPF 5.7.6 Route summarization problems Route summarization allows a group of contiguous networks to be summarized as fewer addresses in order to help reduce the size of the routing table, thus increasing the performance of OSPF and other routing protocols. OSPF can use two types of summarization:
  1. Interarea route summarization that can be done on the ABR.
  2. External route summarization that can be done on the ASBR.
Figure shows a network in which a router is not summarizing interarea routes. Debugs and Verification
Router R1 has the area range command for summarization of area 3 routes. The syntax of the command is correct, but the problem is that R1 is not an ABR. Router R1 is included in area 0, but it is not connected to area 3, and thus cannot summarize area 3 routes. A way to check if a router is summarizing the routes properly is to use the show ip ospf command. The output of show ip ospf shows that the area 3 range is passive. Passive means that no addresses within this area fall within this range. In fact, R1 does have the routes in this range; however, because R1 is not connected to area 3, the range appears as passive. Because summarization is not happening, R1 is receiving four routes in the routing table instead of one summarized route. Solution
The solution to this problem is to configure the area range command on the ABR, which is R2. After changing the configuration and removing the area range command on R1, verify that the summarization is indeed active by using show ip ospf on R2. The summarized route is now being installed in the routing table of R1. Note: There are similar issues with external summarization, which is done on the ASBR. External summarization uses the summary-address command only on the ASBR. The show ip ospf summary-address command can be used to help troubleshoot external summarization issues. A metric of infinity, shown in Figure , means that no valid addresses belong to this range of summarization and that there is a problem (16,777,215 equates to infinity because the external LSA metric is 24 bits long and 224 is equal to 16,777,215). Figure shows the same show ip ospf summary-address command, when summarization is configured correctly on the ASBR, with a metric less than infinity.
Content 5.7 Troubleshooting OSPF 5.7.7 CPUHOG problems When OSPF forms an adjacency, it floods all the link-state update packets to its neighbors. Sometimes, the flooding process takes a lot of time, depending upon the router resources. CPUHOG messages appear in the log if the resources of the router become exhausted due to flooding. CPUHOG messages usually appear in two significant stages:
  1. Neighbor formation process
  2. LSA refresh process
Neighbor formation process
When OSPF forms an adjacency, it floods all of its link-state packets to its neighbor. This flooding sometimes takes a lot of CPU processing. Starting with Cisco IOS Software 12.0T, packet pacing was included to help prevent CPU processing problems from occurring. Prior to 12.0T, the IOS did not support packet pacing. During link-state flooding a router will try to send data as fast as it can over a link. If a link is slow or the router on the other side is slow in responding, this results in retransmission of the LSA and eventually leads to CPUHOG messages. Packet pacing adds a pacing interval between the LS updates. Instead of flooding everything at once, packet pacing sends the packet with a gap of a few milliseconds in between. Figure shows the log messages on a router showing CPUHOG during adjacency formation. Packet pacing introduces a delay of 33 ms between packets and 66 ms between retransmissions. This pacing interval reduces the CPUHOG messages, and the adjacency is formed more quickly. If a router is experiencing this problem with an IOS prior to 12.0T, the solution is to upgrade to 12.0T or higher. LSA refresh process
Starting with Cisco IOS 12.0, the LSA group pacing feature was introduced to eliminate a CPU processing problem that can occur every 30 minutes. Prior to IOS 12.0, all LSAs are flooded every 30 minutes to refresh the MAXAGE times in the link state database. Without this flooding, the LSAs would expire after 60 minutes. This flooding is also known as a paranoid update. This flooding causes CPUHOG messages every 30 minutes, especially in cases where a couple of thousand LSAs are all being flooded at the same time. The CPUHOG messages appear in the router log every 30 minutes. LSA group packing looks at the LSA periodic interval (every 4 minutes, by default) and refreshes only those LSAs that are past their refresh time. This is an efficient way of reducing a large flood by chopping it down to smaller LSA floods. No extra configuration is required for this feature, but for large numbers of LSAs (generally 10,000 or more), it is recommended to use small intervals (for example, every 2 minutes); for a few hundred LSAs, use a large interval, such as 20 minutes. If 10,000 LSAs need to be refreshed, keeping the refresh interval smaller will check the LSA every 2 or 4 minutes to see how many LSAs have reached the refresh interval, which is 30 minutes. The advantage of checking this frequently is that few LSAs would need to be refreshed every 2 or 4 minutes, and this will not cause a huge storm of LSA updates. If the number of LSAs is small, it really does not matter whether the refresh occurs at 2 minutes or 20 minutes. This is why it is better to increase the timer so that all the LSAs, which are few in number, can be refreshed at once. Figure shows how to configure the LSA refresh interval.
Content 5.7 Troubleshooting OSPF 5.7.8 SPF calculation and route flapping Whenever there is a change in topology, OSPF runs the SPF algorithm to compute the Shortest Path First tree again. Unstable links existing within the OSPF network could cause constant SPF calculations. Some of the most common reasons for SPF running constantly are: Topology changes in an OSPF network cause SPF calculations within that area. The SPF is not recalculated if the topology change is in another area. Actually, OSPF distributes interarea (between areas) topology information using a distance-vector method. The ABRs forward routing information between areas using a distance vector technique similar to that of RIP or IGRP. The following is an example of SPF running constantly due to an interface flap within the network. This is a common problem in OSPF. Whenever there is a link flap in an area, OSPF runs SPF within that area. So, if a network has unstable links, it can cause constant SPF calculations. SPF itself is not a problem because OSPF is just adjusting to the change in the database through calculating SPF. The real problem occurs if there are small routers in the area and a constant SPF run might cause a CPU spike in a router. Because R1 is also included in area 0, any link flap in area 0 causes all routers in area 0 to run SPF. Debugs and Verification
A link flap in an area causes SPF to run. If a link is flapping constantly, this can increase the number of SPF calculations in an area. A constant number of SPF calculations in not a problem, but if the number is incrementing constantly, it is an indication of a problem. The output of show ip ospf, shows that there is a huge counter for SPF in area 0. The easiest way to find out which