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.