information. If any indication of high CPU utilization caused by the SPF process is determined, the show isis spf-log command can determine SPF-related events that might cause the high CPU utilization. The output of the show isis spf-log command lists SPF process runs by time, trigger, and duration. LSPs are refreshed every 15 minutes, triggering periodic SPF calculations. Such events are labeled periodic in the show isis spf-log output. It also shows that at 03:25:25, the process was run over an insignificant period of time because of receipt of a new LSP from RT5. Figure lists and describes common SPF triggers. The following is a list of IS-IS debugging commands that can also be used to narrow SPF-related problems: Use caution when enabling debugging in a situation in which the route processor CPU already is overtaxed. Output of the debug isis spf-events command displays the events following an interface shut down to simulate a link flap. Lines indicating LSPs flagged for recalculation as a result of this event are highlighted. Also, events, flagging computation of the Level 1 and Level 2 SPF trees are highlighted. Most route-flapping problems can be traced to unstable links in the network. In more complicated scenarios, however, the flaps could be caused by LSP corruption storms or even a routing loop. This might be the case when there are no unstable links in the network, but CPU utilization is high, indicating continuous running of the SPF process. The show isis spf-log command can provide an indication of which LSPs are changing the most frequently and are triggering the SPF calculations. Similar clues can be gleaned by enabling debugging of the update process with debug isis update-packets. This should be done with care so that the CPU is not overloaded. The logs also can be observed for LSP error loggings, which could give an indication of packet corruption by a culprit device. Zeroing in on any continuously changing LSPs is critical for determining and addressing the problem.