More About the IS-IS Link-State Database

The previous sections review components of the IS-IS Link-State database and discuss flooding mechanisms designed to optimize Link-State database synchronization on various media. In a stable IS-IS network, usual routing-related activities include sending and receiving hello packets to maintain adjacencies, periodic advertising of CSNPs on broadcast links, and the refreshing of LSPs. Network instabilities trigger dynamic disruptions, which when extensive result in a depletion of processing and bandwidth resources and ultimately meltdown of the network. This section looks at the operation and maintenance of the IS-IS database and discusses some stability and performance- related issues pertaining to these activities.

IS-IS Link-State Database and Network Stability

After initial flooding and synchronization of the Link-State database, the network becomes relatively quiet. LSPs are generated and flooded only when a change occurs in a router's environment, which creates corresponding changes in the TLVs contained in its LSP. IS-IS routers use only a single LSP to represent the router's immediate environment, and the LSP can be fragmented if necessary. A TLV content change results in generation and flooding of the entire LSP with appropriate modifications. The following events can trigger regeneration of a new LSP:

  • IS-IS adjacency flap

  • IP interface flap

  • Change in interface metric

  • Changes interarea routes

  • Changes in redistributed (external) routes

Any occurrence of the listed events compromises the previously issued LSP and requires a new LSP to be generated to replace the old one.

IS-IS Link-State Database Integrity Issues

The integrity of the Link-State database is critical to the operation of the IS-IS protocolin general and specifically for calculating accurate routing information to prevent costly routing loops . Database synchronization and periodic LSP refresh are key mechanisms for ensuring the integrity of the Link-State database. This section discusses other auxiliary mechanisms that directly or indirectly help guarantee the reliability of the information in the database. It also covers the mechanisms for discovering duplicate SysIDs and details the use of the Sequence Number and Checksum fields.

LSP Checksum

The IS-IS protocol does not rely on the data-link cyclic redundancy check (CRC) to guarantee the LSP integrity. Instead, IS-IS routers use a checksum value calculated over a greater part of the LSP to ensure the integrity of the contents of any LSP. The checksum is calculated from the SysID field to the end of the LSP and is inserted into the header by the originator of the LSP. The LSPs might be corrupted while sitting in memory; therefore, it is necessary to check the validity of LSPs before flooding them during refresh. When a node receives an LSP, it checks to make sure that the LSP was not corrupted in transmission before it installs a copy in the local database and refloods copies to other neighbors.

It is common knowledge that in certain networking environments, typically where Frame Relay to ATM conversion switches are used, LSPs are easily corrupted when flooded from one end of the network to the other. The standard procedure for handling a corrupted LSP at a receiving node is to not only discard it but also to attempt to purge it from the entire network.

To initiate a purge, a router sets the Remaining Lifetime field of the LSP to zero and floods it to into the network. Eventually, the owner or original source of the LSP receives a copy of the LSP being purged. The owner then reissues a newer copy back into the network. If the media problem remains, a situation of continuous flooding and purging of many LSPs in the network occurs, a network situation referred to as an LSP corruption storm .

LSP corruption storms consume network resources, cause tremendous network problems, and can potentially disrupt network services. In general, routers receive copies of an LSP over multiple links; therefore, although a corrupted copy might come in over one link, a good copy might make it over another link. It might be possible to obtain accurate network information by ignoring bad LSPs obtained over a specific path in the network, instead of creating a situation that can deteriorate the network.

Cisco IOS provides a command for configuring IS-IS routers in environments prone to LSP corruption storms to ignore LSP checksum errors. The router-level command ignore-LSP-errors enables Cisco routers to silently discard corrupted LSPs and to log the event. On a point-to-point link, if an LSP is discarded, it is not acknowledged and the source retransmits it. On broadcast links, no retransmission occurs; however, routers eventually discover missing LSPs from CSNPs advertised by the DIS and can subsequently request full copies with PSNPs.

LSP Sequence Number

As mentioned previously, the primary role of the Sequence Number field is to help identify newer LSPs from older versions. Any time that a router regenerates its LSP, either because of a refresh (normally every 15 minutes) or a change in the network, it increases the sequence number by 1.

An interesting phenomenon occurs when a router crashes and reloads . The router's neighbors drop their adjacencies, but they do not remove the LSP of the crashed router from their databases until the remaining lifetime reaches a zero value and the ZeroAgeLifetime passes . When the router recovers, it generates and floods its LSP with an initial sequence number of 1. The neighbors that have the same LSP with a higher sequence number then flood their copies to the rebooted router, thinking their LSPs are newer because of the higher sequence number. Upon detecting a sequence number mismatch of its own LSP, the reloaded router issues yet another copy of the LSP with a sequence number greater by 1 than the highest sequence number value in the LSPs received from neighbors. This process restores the router close to its sequence number value before the reboot.

Duplicate System IDs

The fundamental objective of addressing is to achieve unique identification of the addressed elements. In conformance with this ideal, IS-IS does not tolerate duplicate addresses. In discussing IS-IS addressing concepts, Chapter 4, "Addressing in Integrated IS-IS," notes that both IP addresses and ISO NSAP addresses need to be configured on IS-IS routers even in IP-only environments. As discussed in the section on IP addressing in Chapter 1, "Overview of IP Routing," IP addresses are made unique by defining unique IP subnets for the links in the network and assigning unique host addresses to the interfaces of devices that connect to links. However, the node-based addressing scheme used in ISO CLNP and adopted by Integrated IS-IS assigns a globally unique address to each network device in a domain. Within an area, a node's NSAP is made unique by its unique SysID component of the NSAP. The unique SysID also forms part of the LSP ID, providing a means to differentiate between LSPs in the Link-State database.

To simplify operations, service providers use domainwide unique SysIDs ”even though in a two-level network with many areas, it is possible to have Level 1 nodes in separate areas share the same SysID provided they do not connect to the IS-IS backbone (Level 2). A unique SysID is, however, required for each node in single-level (Level 1-only or Level 2-only) routing domains and is highly recommended for hierarchical domains with many areas. You can easily achieve this by using unique IP loopback addresses on the routers to create SysIDs (as discussed in Chapter 4). Using domainwide unique SysIDs in multi-area networks provides advantages in network operations involving device management, troubleshooting, and maintenance.

Obviously, IS-IS operations are seriously impacted in scenarios in which two or more routers in the same area or connected to the backbone share the same SysID. First, this means assigning the same NSAP or NET to them if they are in the same area; second, this means mixing up their LSPs, regardless of whether they are in the same area or connected to the backbone. Each router encloses information specific to its routing environment into its LSP ”that is, it calculates and enters a checksum on information in the LSP header. When the LSPs are mixed up, the sources see a different checksum than expected on what looks like their LSPs. Suspecting a corrupted LSP, each router issues another copy with a higher sequence number and floods it out into the rest of the network.

Similar activity occurring on other routers with duplicate addresses creates a situation of continuous regeneration and purging of the LSPs with duplicate IDs. This situation undoubtedly results in network instability. If a router detects that another device might be sharing its SysID, it generates an error similar to the following:

 %CLNS-4-DUPSYSTEM: ISIS: possible duplicate system ID 0000.0000.0002 detected 


IS-IS Network Design Solutions
IS-IS Network Design Solutions (Networking Technology)
ISBN: 1578702208
EAN: 2147483647
Year: 2005
Pages: 144
Authors: Abe Martey

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net