Route flaps normally are caused by unstable links between the source of the
route and the location where the flap is being observed. Apart from certain
destinations not being reachable, obviously implying routing problems, high CPU
utilization by the SPF process (show process cpu command)
certainly should flag instabilities in the network. High CPU utilization can be
observed through the IOS command line interface, network management
applications, or special network-performance analysis tools, such as
CiscoWorks.
The show process cpu command can obtain
CPU utilization 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:
-
debug isis spf-events
-
debug isis spf-triggers
-
debug isis spf-statistics
-
debug isis update-packets
-
debug isis adj-packets
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.