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:
- Neighbor formation process
- 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.
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.