Configuring IS-IS for Optimized Performance

The previous sections discuss rudimentary IS-IS configuration for various scenarios, using the two basic steps required to enable IS-IS on Cisco routes: configuring the routing process and enabling IS-IS routing on interfaces. Cisco IOS Software provides numerous commands for enabling various capabilities of the IS-IS protocol and optimizing its performance. In most cases, the configuration options enabled are targeted at improving efficiency of the data-forwarding process and achieving network design objectives, such as routing stability and fast convergence. The command options can be enabled globally under the configuration of the IS-IS routing process (router-level configuration) or for specific interfaces (interface-level configuration). As you might be aware by now, the two categories of IS-IS configuration commands are interface-level commands and router-level commands.

This section discusses some commonly used (although nonessential) IS-IS commands. Example 9-21, which shows the typical configuration of an Internet router, provides the basis for discussions in this section. This configuration is for illustrative purposes only.

Example 9-21 Internet Router IS-IS Configuration

 RT1#  show running-config  ! clns routing ! interface Loopback0  ip address 172.168.123.1 255.255.255.255  no ip directed-broadcast ! interface Serial0/0  ip unnumbered Loopback0  no ip directed-broadcast  ip router isis  isis metric 15 level-2  isis password cisco level-2  isis hello-multiplier 12 level-2  isis hello-interval 5 level-2 ! router isis  summary-address 10.1.0.0 255.255.0.0  passive-interface Loopback0  net 49.0001.0002.0003.0004.0005.0006.00  is-type level-2-only  metric-style wide  spf-interval 30  no hello padding  log-adjacency-changes ! ip classless ! end 

The configuration in Example 9-21 features the following additional interface-level configuration commands:

• isis metric

• isis password

• isis hello-interval

• isis hello-multiplier

Example 9-21 also shows the following nonessential router-level commands:

• is-type

• metric-style

• spf-interval

• ignore-lsp-errors

• no hello padding

• log-adjacency-changes

• passive-interface

• summary-address

All the commands in the preceding two lists are not required to enable IS-IS. However, they are added to optimize operational efficiencies of the protocol and network design. These commands are discussed further in the following sections. The isis password and summary-address commands are covered earlier in this chapter, in the sections on authentication and summarization, respectively.

isis hello-interval and isis hello-multiplie r Commands

By default, the interval between hello packets is 10 seconds, with some jittering applied to prevent network-wide synchronization. The corresponding default for the hello multiplier is 3. The product of these two parameters gives the holdtime for the adjacency. The holdtime is the interval after which if a hello packet has not been received from the neighbor, it will be declared "dead" and the adjacency torn down. The holdtime has a direct bearing on the speed of convergence. The holdtime can be modified by adjusting the hello interval and hello multiplier, as needed, to provide the desired effect on network stability and convergence. The holdtime value cannot be modified directly on Cisco routers. In the sample configuration shown in Example 9-21, the hello interval has been reduced to 5 and the multiplier increased to 12, resulting in a holdtime of 60 seconds rather than the 30-second default value.

isis metric and metric-style Commands

You can use the isis metric command to modify the default metric value for Level 1 or Level 2 separately. In both situations, the default value is 10. In the configuration shown in Example 9-21, the metric is changed to 15 for only Level 2. Notice that this router would participate only in Level 2 routing on all its active IS-IS interfaces because of the global, router-level is-type level-2-only command.

The metric-style command is a recent introduction based on the IS-IS enhancements in the IETF (IS-IS extensions for Traffic Engineering, draft-ietf-isis-traffic-02.txt), specifically to facilitate MPLS traffic engineering. The following are the current argument options for this command:

• narrow ” Bases interpretation of the metric field in TLVs 2, 128, and 130 on ISO 10589 and RFC 1195. The router is limited to a maximum metric of 63 per interface and 1023 for an entire path .

• transition ” Allows routers to send and receive both old and new metric formats.

• wide ” Allows routers to use a new metric format to support large metric values.

The default is metric-style narrow. The wide option provides a lot of flexibility for metric assignment in IP networking environments. The transition option is recommended only for migration purposes and carries some overhead with it. Therefore, network operators need to avoid enabling transition mode for long- term operation. This is further discussedin Chapter 7, "General Network Design Issues," and a migration scenario is provided in Chapter 8.

isis-type Command

The isis-type command determines the mode of operation of all active IS-IS-enabled interfaces on a Cisco router. The argument options for this command are as follows :

• level-1-2 ” This is the default mode of operation. In this mode, the router is capable of both Level 1 and Level 2 functionality and can form either type of adjacencies with neighboring IS-IS routers.

• level-1 ” In this mode, the router can form only Level 1 adjacencies on all interface on which IS-IS is enabled. A router operating in this mode forwards all packets to other areas in the domain to the nearest Level 1-2 router in the local area.

• level-2-only ” In this mode, the router can participate only in Level 2 routing. Routers providing extensions to the IS-IS Level 2 backbone that do not connect to any Level 1 domains could be configured to operate in this mode to conserve system resources. Some ISP networks using IS-IS as the IGP employ flat network designs with all the IS-IS routers as Level 2 only. This allows for easy migration to a hierarchical design; you can just migrate the edge to different areas and leave the core intact.

spf-interval Command

In default operation mode, the IS-IS SPF process on Cisco routers runs periodically, no more frequently than every 5 seconds. That is, by default, the normal minimum interval between two consecutive SPF calculations is 5 seconds. However, certain network changes, such as link failures, can trigger immediate runs. The SPF process might be costly in terms of CPU cycles depending on the size of the network (that is, the number of nodes, links, and prefixes involved).

The spf-interval command specifies the interval between SPF calculation events. A smaller interval might result in faster convergence but possibly affect the stability of the network. Typically, larger interval values are used only in stable network environments.

For example, the configuration shown in Example 9-21 is optimized for a stable environment, which is less prone to network churn; therefore, the SPF process is set to run no more frequently than every 30 seconds.

Recent IS-IS enhancements in IOS include new options for the spf-interval command. This change allows aggressive low intervals to be specified and provides for backoff to more conservative values when changes in the network become rampant. The backoff mechanism is also implemented for partial route calculations and also generation of LSPs. Exponential backoff is discussed in detail in Chapter 7.

The show isis spf-log command is a related command that enables you to view an SPF activity log. A sample output of the show isis spf-log command is shown in Example 9-22. The output shows various triggers that caused the running of the SPF process on this router. PERIODIC indicates periodic runs of the SPF process, whereas TLVCONTENT implies that the SPF calculation was triggered by a change in the contents of the TLV field of the LSP owned by the listed router.

Example 9-22 show isis spf-log Command Output

 RT1#  show isis spf-log  Level 2 SPF Log When       Duration  Nodes   Count     Last Trigger LSP   Triggers 02:38:48      0        5       3         RT3.00-00        NEWADJ TLVCONTENT 02:31:35      0        5       1                          PERIODIC 02:22:30      0        5       2         RT1.00-00        NEWMETRIC TLVCONTENT 02:16:36      0       2       4         RT1.02-00       PERIODIC TLVSTYLE TLVCODE 02:11:27      0        2       4         RT1.00-00        NEWADJ DELADJTLVCONTENT 02:08:10      0        2       2         RT1.00-00        DELADJ TLVCONTENT 02:01:36      0        2       1                          PERIODIC 01:46:36      0        2       1                          PERIODIC 01:31:36      0        2       1                          PERIODIC 

The following list explains the triggers shown in Example 9-22:

• PERIODIC ” Periodic SPF process (LSPDB refresh interval)

• NEWSYSID ” New system ID assigned

• NEWLEVEL ” IS-IS process level changed

• NEWMETRIC ” New metric assigned to an interface

• TLVCODE ” LSP with a new TLV code field received

• TLVCONTENT ” LSP with changed TLV contents received

• NEWADJ ” New neighbor adjacency up

• DELADJ ” Adjacency deletion

passive-interface Command

The objective of the passive interface command is to prevent protocol activity over a specific interface. This is a generic command applicable to all routing protocols supported in Cisco IOS Software. When configured under the IS-IS process, the passive-interface command prevents transmission of IIHs over the specific interface and as a result prevents formation of IS-IS adjacency over that interface. Typically, the passive-interface command is used when there is a need to advertise the prefix from a network interface without forming adjacencies over that interface. In Cisco IOS Software, specifying an IS-IS interface as passive removes the IS-IS configuration from that interface. The IP subnet configured on the interface is still advertised into the IS-IS environment.

The log-adjacency-changes, ignore-lsp-errors, and no hello padding Commands

The log-adjacency-changes command enables logging of IS-IS adjacency changes. You can use this to generate SYSLOG traps for network operations and management purposes. The logged information is also useful for troubleshooting purposes. Examples of the messages logged are shown in Example 9-23.

Example 9-23 Tracking Adjacency Changes

 RT1#  show log  %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0001 (ethernet 0)  %CLNS-5-ADJCHANGE: ISIS: Adjacency to 0000.0000.0002 (ethernet 0) 

The ignore-lsp-errors command is used in network environments prone to packet corruption. The command allows the router to ignore any corrupt LSP that would normally have triggered a purge action. A router purging another's LSP is the correct behavior of the protocol but could easily degenerate into an adverse network situation (referred to as LSP packet corruption storms ). In this situation, a router's LSPs are repeatedly corrupted by the transport medium and are purged by other systems in the network, resulting in an SPF churn that could potentially lead to a network meltdown.

The no hello padding command is designed to prevent network bandwidth from being wasted by the periodic exchange of hellos over interfaces with large message transmission unit (MTU) sizes. The IS-IS protocol requires hellos to be padded to the larger of the MTU or LSP buffer size.

This would technically guarantee that systems forming adjacencies over a link can receive and process each others LSPs and other IS-IS packets over the link. However, in practice, the same MTU size is used on the interfaces of the connecting routers; therefore, padding hello packets is irrelevant in most cases. The command disables the default behavior, resulting in significant bandwidth savings, especially in situations where small hello intervals have been configured and the MTU size is reasonably large.

A global router-level variant of this command provides options to selectively disable padding on all IS-IS interfaces or all point-to-point interfaces or all multipoint interfaces (see Example 9-24). You can use an interface-level variant of the command for a single interface application, as shown in Example 9-25.

Example 9-24 Disabling Hello Padding on Multiple Interfaces

 RTA(config)#  router isis  RTA(config-router)#  no hello padding ?  multipoint     Pad LAN hello PDUs         point-to-point  Pad point-to-point hello PDUs 

Example 9-25 Disabling Hello Padding on an Interface

 RTA(config)#  int pos 2/0  Rtr-A(config-if)#  no isis hello padding