Content

| 5.8 |  | Troubleshooting IS-IS |
| 5.8.6 |  | Route flapping problem |

Route flaps normally are caused by unstable links between the source of the route and the location where the flap is being observed. Typically, multiple routes are impacted at the same time because of an adjacency change affecting many LSPs, all of which might carry numerous IP prefixes. Also, route flaps could induce consistent running of SPF process, causing dangerously high CPU utilization on route processors that might crash affected routers. If the advertised LSP changes affect only IP prefixes, only partial route calculation (PRC) is run instead of full SPF calculations. PRC is less costly in terms of CPU cycles than full SPF runs.

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

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.