Chapter 5. The IS-IS Link-State Database


In Chapter 3, "Integrated IS-IS Routing Protocol Concepts," you read about the two main categories of IS-IS functional capabilities: the subnetwork-dependent and subnetwork-independent functions. As you might recall, the subnetwork-dependent functions are primarily responsible for adjacency formation and management, whereas the subnetwork-independent functions provide capabilities for exchanging and managing routing and related control information. The IS-IS routing engine represented in Figure 3-8 illustrates the functional organization of the key processes and subsystems that are responsible for the subnetwork-independent functions. The IS-IS Link-State database, which is featured prominently in the routing engine, is the bottom line of all the complex operations that work together to achieve the objectives of the IS-IS protocol. Those objectives include the efficient collection and dissemination of routing information and the expedient determination of the most optimal path between any two points in the network.

The significance of the IS-IS routing engine in the overall IS-IS protocol framework underscores the importance of understanding the functions and operation of the IS-IS database for anyone interested in the nuts and bolts of the IS-IS protocol. This chapter focuses primarily on the IS-IS Link-State database and discusses its architectural internals. The discussion covers the role of the database update process, including how it gathers, stores, and disseminates routing information. The objective of the chapter is to provide you with a complete understanding and appreciation of the sophisticated innards of the IS-IS protocol.

The information elements stored in the IS-IS Link-State database are referred to as link-state packets (LSPs) . LSPs contain routing information generated by IS-IS routers to describe their immediate surrounding . Recall from Chapter 3 that LSPs are one of three categories of IS-IS packets; hello packets and sequence number packets (SNPs) are the others. LSPs contain information such as the following:

  • Area information

  • Adjacent routers

  • IP subnets

  • Metric information

  • Authentication information

The information contained in an LSP represents a partial view of the entire topology of the local area. You might recall from previous chapters that the original specifications of IS-IS (ISO 10589 and RFC 1195) require each router in an IS-IS routing domain to be tied to at least one parent area.

NOTE

IS-IS implementation extensions in recent Cisco IOS releases support multi-area configurations in which a single router can connect to multiple independent areas. Multi-area support in IS-IS is intended for use in pure ISO domains and for scaling auxiliary networks for managing telecommunication network elements such as SONET Add Drop Multiplexors.


The routers in an area exchange LSPs by means of a process called flooding . The flooding process is discussed in detail later in this chapter.

LSPs learned from neighbors in the same area are stored locally on each router in the Level 1 IS-IS Link-State database. Each area in an IS-IS domain has its own unique Level 1 Link-State database. It is a key requirement of link-state protocols such as IS-IS that all routers in an area receive and assemble all intra-area LSPs into identical Link-State databases that represent the topology of the area. Each router then runs the shortest path first (SPF) algorithm over its database to obtain best paths for destinations within the area.

As discussed in Chapter 2, "Introduction to the IS-IS Routing Protocol," and Chapter 3, IS-IS supports a hierarchical routing architecture with two levels: Level 1 and Level 2. The Level 1 Link-State database supports routing within an area, and the Level 2 Link-State database supports routing between areas. The Level 2 Link-State database is a collection of Level 2 LSPs flooded over the backbone. The Level 2 LSPs contain pieces of information about the Level 2 topology as seen from the perspective of routers attached to the backbone. The complete Level 2 topology is obtained by running the SPF algorithm over the Level 2 database. In a typical network layout, the individual Level 1 areas are interconnected by a backbone formed by Level 2-capable routers, referred to as Level 1-2 routers. Level 1-2 routers maintain two separate Link-State databases for Level 1 and Level 2 routing, respectively. This is illustrated in Figure 5-1, which shows an IS-IS routing domain with two areas, 49.0001 and 49.0002.

Figure 5-1. Level 1 and Level 2 Link-State databases.

graphics/05fig01.gif

Figure 5-1 also shows routers in each area functioning as Level 1-only and with only a single database. For Cisco routers, the default configuration is both a Level 1 and Level 2 router. However, routing can be turned off for Level 1 or Level 2, if necessary, to conserve memory and processing resources. If a router is not connected to the backbone and it is running low on system resources, for example, it can be configured as Level 1-only so that it builds and maintains only a Level 1 Link-State database. Similarly, a router sitting in the middle of the backbone of the network, without any direct connections to a Level 1 area, can be configured as a Level 2-only router. In this case, the Level 2 configuration is necessary to maintain contiguity of the Level 2 backbone. Chapter 7, "General Network Design Issues," focuses on IS-IS network design issues in service provider environments and elaborates on various design considerations, including scenarios with large flat single Level 1- or Level 2-only architectures without any hierarchy. The purpose of such a design is usually to optimize path selection in the IS-IS routing environment, while at the same time preserving router memory and processor resources. All routers in the single-area domain have the same Level 1 or Level 2 database from which they derive routing information. Figure 5-2 illustrates a nonhierarchical domain spanned by a single Level 1 area.

Figure 5-2. Single area domain, Level 1-only.

graphics/05fig02.gif

Alternatively, all the routers can be configured as Level 2-only, as shown in Figure 5-3; in which case, they all have identical Level 2 Link-State databases.

Figure 5-3. Single area domain, Level 2-only.

graphics/05fig03.gif

As mentioned earlier, IS-IS packets are categorized as follows :

  • Hello packets

  • LSPs

  • SNPs

Hello packets are central to the operation of the subnetwork-dependent functions, which essentially involve forming and maintaining adjacencies. LSPs relate to the operation of the subnetwork-independent functions, which manage the routing information-gathering process.

SNPs help ensure the reliability of the flooding process, which in turn leads to efficient database synchronization between the Level 1 routers in the various areas and the Level 2 routers in the backbone. Flooding and database synchronization are discussed later in this chapter in the "Flooding and Link-State Database Synchronization" section. That section also discusses the specific roles played by the various types of SNPs in flooding and database synchronization.

The LSPs collected into the various databases together provide the basis for the big picture interpretation of the topology of an area or the backbone. This interpretation is achieved with the help of the SPF algorithm. By piecing together the information contained in the LSPs to determine the topology of the area or the backbone, SPF also helps determine the shortest path between two points in the network. The SPF algorithm is discussed in detail in Chapter 6, "The Shortest Path First Algorithm."

This chapter now turns to issues relevant to the Link-State database, such as security, data integrity, efficiency, and resource conservation. These topics are discussed from both protocol design and implementation perspectives.



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