This chapter is from the book
This chapter is from the book
This chapter is from the book
IS-IS Protocol Functions
The routing layer functions provided by the IS-IS protocol can be grouped into two main categories: subnetwork-dependent functions and subnetwork-independent functions. In IS-IS, subnetwork refers to the data-link layer. This notion fundamentally differs from IP terminology, in which a subnetwork refers to an IP address subnet. Only two types of IS-IS subnetworks are of practical significance in current applications of the IS-IS protocol: point-to-point and broadcast links.
The subnetwork-dependent functions relate to capabilities for interfacing with the data-link layer and primarily involve operations for detecting, forming, and maintaining routing adjacencies with neighboring routers over various types of interconnecting network media or links. The ES-IS protocol and certain elements of CLNP are key to the operation of the subnetwork-dependent functions.
Subsequent sections explore the subnetwork-dependent functions. In those sections, you will learn about IS-IS links, IS-IS adjacencies, and types of IS-IS systems (nodes).
The subnetwork-independent functions provide the capabilities for exchange and processing of routing information and related control information between adjacent routers as validated by the subnetwork-dependent functions.
The IS-IS routing engine, discussed later in this section, elaborates on the relationship between subsystems (processes and databases) that provide the subnetwork-independent functions within the framework of a conventional router.
Subnetwork-Dependent Functions
The role of the subnetwork-dependent functions of the IS-IS protocol was described in the previous section. Critical component functions are further described within this section. The IS-IS routing protocol distinguishes two main types of subnetworks or links in a network: general topology subnetworks and broadcast subnetworks.
General Topology Subnetworks
General topology subnetworks are permanent or dynamically established point-to-point links. An example of the former is Packet over SONET/SDH. Asynchronous Transfer Mode (ATM) point-to-point switched virtual circuit (SVC) is an example of the latter.
Broadcast Subnetworks
Broadcast subnetworks are multipoint or local-area network (LAN) media with broadcast capabilities, such as Ethernet, Fiber Distributed Data Interface (FDDI), or the Cisco-invented Dynamic Packet Transport Technology (DPT).
NOTE
The Cisco implementation of the IS-IS routing protocol operates in broadcast mode over nonbroadcast multiaccess (NBMA) technologies, such as Frame Relay and ATM, when configured in multipoint mode. This mode of operation requires the use of Layer 3-to-Layer 2 address map statements and assumes a full-mesh permanent virtual circuit (PVC) environment. In certain cases, special workarounds might be required for effective application of IS-IS in such environments. However, for such media, point-to-point configuration is highly recommended.
IS-IS Network Nodes
The ISO Connectionless Network Protocol is specified for transfer of data between two main categories of network devices:
End systems—The analogy for an end system is a workstation or network host with limited routing capability.
Intermediate systems—These are network devices such as routers with extensive packet-forwarding capabilities. The word intermediate refers to the capabilities of routers as intermediate forwarding or relay devices. Routers are referred to as gateways in some older networking literature.
The IS-IS routing protocol is designed to provide routing intelligence for intermediate systems, whose role in the network is to relay data between user applications running on distantly located end systems. IS-IS allows the gathering and processing of routing information by routers within the same domain. Routers can locate end systems on directly connected segments using ES-IS for CLNP or ARP for IP. Therefore, the combination of ES-IS and IS-IS or ARP allows routers to perform their primary function of helping move data packets from one end system to another within the network domain.
Adjacencies
The subnetwork-dependent functions of the routing layer provided by IS-IS are responsible for discovering, establishing, and maintaining adjacencies between the routers in an IS-IS domain. As stated previously, IS-IS works in conjunction with ES-IS and certain elements of the CLNP protocol to achieve this. No special configuration is required on Cisco routers to enable ES-IS. The ES-IS operation is enabled automatically when IS-IS is configured on Cisco routers, and it runs as a background process to support the operation of IS-IS. The subnetwork-dependent functions of IS-IS work with ES-IS to determine network layer addresses of all adjacent neighbors (both end systems and routers). On multiaccess links, data-link addresses (for example, MAC addresses; also referred to as subnetwork points of attachment [SNPAs]) are obtained for all adjacent neighbors and stored in the adjacency database.
ES-IS Adjacencies
ES-IS is designed for host-to-router communication in a pure ISO environment, such as implemented in Digital's DECnet Phase V networking architecture. In an IP environment, ES-IS is relevant only to the extent that it facilitates router-to-router adjacency formation. IP hosts do not participate in the ES-IS protocol and instead rely on ARP for Layer 3-to-Layer 2 address resolution in determining the Layer 2 addresses of LAN-connected hosts and the IP default gateway. In CLNP environments, end systems and routers use the ES-IS protocol to discover each other by sending ESHs and ISHs to well-known LAN broadcast addresses. End systems send ESHs targeted at the routers to 09-00-2B-00-00-05 (AllIntermediateSystems), and routers send the ISHs to 09-00-2B-00-00-04 (AllEndSystems). ES-IS allows end systems to locate the closest router for access to other nondirectly connected media. Routers, in turn, learn about the location of end systems through the ES-IS adjacency information. Routers also distribute the SysID of known end systems to other routers within the same area by means of Level 1 IS-IS routing. Other ES-IS events, such as redirection, are beyond the scope of this book.
Figure 3-3 End System Hello (ESH) and Intermediate System Hello (ISH).
){kind=link}
IS-IS Adjacencies
Directly connected routers enabled for IS-IS routing go beyond the ES-IS adjacencies described in the preceding section to form IS-IS adjacencies. The IS-IS adjacencies on point-to-point links are formed and maintained a little differently than on broadcast links. Consequently, different types of IS-IS hellos (IIHs) are used. The three types of IIHs follow:
Point-to-point IIH—Used over point-to-point links
Level 1 LAN IIH—Used over broadcast links, but for Leve1 1 adjacencies
Level 2 LAN IIH—Used on broadcast links, but for Level 2 adjacencies
Like all IS-IS packets, the IS-IS hello packets are made up of headers and variable-length fields. The point-to-point IIHs and LAN IIHs have slightly varied information in their header area. Mostly, however, similar information is contained in the header area of both packet types except that point-to-point IIHs have a local circuit ID in place of the LAN ID in LAN IIHs. Also, point-to-point IIHs do not have the priority information found in LAN IIHs. As specified in ISO 10589, TLV types used in point-to-point IIHs are limited to the following:
Area Addresses (Type 1)
Padding (Type 8)
Authentication Type (Type 10)
LAN IIHs support the following TLVs fields:
Area Addresses (Type 1)
Intermediate System Neighbors (Type 6)
Padding (Type 8)
Authentication Information (Type 10)
NOTE
The absence of information on intermediate system neighbors in point-to-point IIHs as specified in the original hello format caused reliability issues in forming point-to-point adjacencies. A recent IEFT draft proposes TLV Type 240 to address this problem. This draft is discussed later in this chapter.
Successful formation of an IS-IS adjacency between two nodes paves the way for the exchange of IS-IS routing information by using special routing information and control packets known as link-state packets (LSP) and sequence number packets (SNP), respectively. LSP and SNP exchange between IS-IS routers is discussed in-depth in Chapter 5, "IS-IS Link-State Database." The type of adjacency formed between neighbor routers determines the type of routing information that is exchanged between them. As mentioned previously, IS-IS routing has a two-level hierarchy, Level 1 and Level 2, and the types of adjacencies that can be formed are consistent with this hierarchy. As specified, routers in the same area must be able to form at least a Level 1 adjacency, regardless of the type of interconnecting links (point-to-point or broadcast). On Cisco routers, the default mode of operation for routers in the same area, is to form both Level 1 and Level 2 adjacencies. Routers that belong to different areas can form only Level 2 adjacencies. Point-to-point and broadcast adjacencies are further covered in detail in later sections of this chapter.
Hello Interval, Hello Multiplier, and Hello Holdtime
Routers periodically send hello packets to adjacent peers, every hello interval. The hello interval is jittered, up to about 25 percent, to reduce the likeliness of synchronized IIH transmission over the network. On Cisco routers, the default value of the hello interval is 10 seconds for ordinary routers and 3.3 seconds for the designated intermediate system (DIS) on a multiaccess link. IS-IS uses the concept of hello multiplier to determine how many hello packets can be missed from an adjacent neighbor before declaring it "dead." The maximum time lapse allowed between receipt of two consecutive hello packets received is referred to as the holdtime. The holdtime is defined as the product of the hello interval and the hello multiplier. On Cisco routers, the default value of the hello multiplier is 3; therefore, the default hold time is 30 seconds. If a router does not receive a hello from a neighbor before the holdtime expires, the adjacency is torn down. The holdtime is reset anytime a hello is received. Hellos are transmitted periodically by routers to neighbors at the expiration of the hello interval. However, the following conditions will also trigger immediate transmission:
IS-IS Point-to-Point Adjacencies
IS-IS adjacencies on point-to-point links are initialized by receipt of ISHs through the ES-IS protocol. This is followed by the exchange of point-to-point IIHs. The type of adjacency formed will depend on the parameters exchanged in the IIHs. The IIHs also are sent periodically over the link to every hello interval to maintain the adjacency. On Cisco routers, the default hello interval for point-to-point links is 10 seconds. The format of the point-to-point hello packet is shown in Figure 3-4.
){kind=link}
Figure 3-4 Point-to-Point Hello Packet (PDU Type 17).
A router performs checks on a received IIH to confirm various parameters in the hello header, such as SysID length, Maximum Area Addresses, and so on. System capabilities are advertised in the appended TLVs. The TLV fields that might be appended to the point-to-point hello packet are Area Addresses (Type 1), Padding (Type 8), and Authentication (Type 10) information. Padding is applied in increments of 2 bytes up to at least 1 byte short of the physical MTU of the outgoing interface.
The following is a list of packet type-specific fields in the header of a point-to-point hello:
Circuit Type—Level 1, Level 1-2, or Level 2 only
Source ID—System ID of the router that generated the hello packet
Holding Time—Maximum interval between two consecutive hello packets before the router is considered no longer available
PDU Length—Length of the entire PDU, including header
Local Circuit ID—Unique link identifier
TLV Fields—Variable-length fields
When an ISH is received on a newly enabled point-to-point link, the router verifies whether an adjacency already exists with the sender by checking the source SysID in the ISH against its adjacency database. The ISH is ignored if an adjacency exists. If not, the receiving router creates a new adjacency and sets its state to "initializing" and the system type to "unknown." The router then sends the new neighbor an IIH in response. Upon receiving a subsequent IIH from the new neighbor, the router then moves the adjacency to an up state and changes the neighbor's system type to IS. In this process, the local router is unable to determine whether its hellos are reaching the remote end.
As specified in ISO 10589, point-to-point hellos do not include the IS Neighbors TLVs (Type 6); therefore, it is impossible to use a three-way process to confirm whether hellos generated locally are reaching neighbors. This might lead to situations where one end of an adjacency is up but the other end is not. An Internet draft submitted to the IETF proposes a more reliable way to form point-to-point IS-IS adjacencies—by using a three-way handshake process, which is backward-compatible to the ISO 10589 procedure.
In the default mode of operation, IIHs are padded to the MTU size of the outgoing interface. Routers match the size of IIHs received to their local MTUs to ensure that they can handle the largest possible packets from their neighbors before completing an adjacency.
When a router sends out a hello packet, it sets the Circuit Type field in the header to Level 1 only, Level 2 only, or Level 1-2, depending on its configuration, either globally by IS type or on an interface level by circuit type. The default IS type on a Cisco router is to be both a Level 1 and Level 2, but this can be modified to be Level 1 only or Level 2 only. Cisco routers also allow the circuit type of a link to be modified individually and independent of the global IS type. A router assigns a locally unique link identifier to each point-to-point link by using the 8-bit Local Circuit ID field in the hello header. The 8-bit field allows up to 256 unique point-to-point links only to be defined in an IS-IS router. Efforts in the IETF's IS-IS Working Group to remove this limitation is discussed in a later section.
One of the key requirements of IS-IS is that the length of the SysID must be consistent on all routers across the domain. Consequently, if the ID Length field of the hello packet (which indicates the length of the SysID) is set to a different value from what is expected, the receiving router discards the IIH. On Cisco routers, the length of the SysID is fixed at 6 bytes. A value of 0 in the ID field of an IIH indicates support for a 6-byte SysID. This means that all nodes interoperating with Cisco routers in an IS-IS network need to set the value of the ID field to 0, to indicate they also support 6-byte SysIDs. Details of the CLNS addressing scheme used in IS-IS is covered in Chapter 4, "Addressing in Integrated IS-IS."
The maximum number of area addresses supported in a single router configuration must match between adjacent neighbors as well, unless the verifying router supports only a maximum value of 3. By default, Cisco routers support a maximum of three area addresses. This can be changed to 255 in recent IOS releases. Any disagreement in the maximum number of supported areas causes the IIH to be discarded; otherwise, it is accepted for further processing. As previously noted, adjacency information such as SNPAs and corresponding SysIDs are obtained from the ISHs that are exchanged through the ES-IS protocol. A key role of IIHs, however, is to help establish the type of the adjacency to be formed. The receiving router determines the type of adjacency to be formed with the remote router from the IS type and the Area ID advertised in the received hello. Thus, in determining the type of adjacency, a router considers all the addresses defined in the Area Address TLVs present in the IIH received. Because they belong to different areas, two routers with nonmatching Area IDs can form only a Level 2 adjacency. If two connected Cisco routers match in Area IDs, they'll form both Level 1 and Level 2 adjacencies according to default behavior.
If authentication is configured, the router appends an Authentication TLV field (Type 10) to the hello packet, which is then checked by the receiving node. ISO 10589 and RFC 1195 specify use of clear-text, simple passwords only. Currently, Cisco routers do not support any other more sophisticated authentication methods. More sophisticated authentication using MD5 message digest might be supported in the future.
If any of the adjacency checks previously described fails, a router will not bring up the new adjacency or will tear down an existing adjacency. When a router tears down an adjacency, it generates a notification message and removes the corresponding entry from its adjacency database. In case of a link failure, the IS-IS process reacts as soon as it obtains appropriate notification from the interface subsystem, by removing any adjacencies associated with the affected interface. The router then generates and floods an updated LSP reflecting the change to other neighbors.
Forming a Reliable Point-to-Point Adjacency
The three-way handshake process for reliably forming point-to-point adjacencies introduces a new type length value field (Type 240), known as Point-to-Point Adjacency State TLV. For backward compatibility, older systems running IS-IS implementations that do not support TLV Type 240 can ignore it, if encountered in an IIH, and follow conventional procedures for forming the adjacency. This is necessary so that newer and older systems can coexist in the same network. The three-way handshake requires a conforming system to move the state of the point-to-point adjacency to up only after confirming that there is bidirectional communication with the remote router and that its hellos are reaching the remote end. Compliant routers include the SysIDs of neighbors from which they have received hellos in TLV 240. A router knows its hellos are reaching a point-to-point neighbor when it receives a hello from that neighbor in which it is listed in this TLV. The TLV Type 240 consists of the following information:
This TLV enhances the IS-IS point-to-point adjacency formation process in two ways. First, a node can confirm three-way communication with its neighbor by confirming the presence of its SysID in a TLV 240 attached to hellos received from the neighbor. The local adjacency state can then be adjusted based on the existing state and the state featured in the Value field of TLV 240 from the hello received. Second, the Extended Local Circuit ID field in TLV 240 can be leveraged to provide unique link IDs for point-to-point links beyond the 256 limit specified in ISO 10589.
IS-IS Adjacencies over Multiaccess Media
The method specified in ISO 10589 for building adjacencies over broadcast media, such as LANs, differs slightly from that used on point-to-point links. Some of the significant differences are as follows:
The process is not triggered by receipt of ISHs. A router sends IIHs on broadcast interfaces as soon as the interface is enabled.
The broadcast medium is modeled as a node, called the pseudonode. The pseudonode role is played by an elected DIS.
Depending on the configuration, nodes on the LAN broadcast their hellos to well-known Level 1 and Level 2 broadcast MAC addresses.
Two-way communication is confirmed between adjacent nodes by using a three-way handshake procedure made possible by the presence of an IS Neighbors field in the LAN (Level 1 or Level 2) hello packets. The reliable point-to-point adjacency formation introduced by TLV Type 240 is similar to this process.
Details of the process for forming LAN adjacencies is discussed later in this chapter. For now, however, take a look at the format of the LAN hello packets, which is the same for both Level 1 and Level 2.
Figure 3-5 IS-IS LAN Hello (PDU Types 15, 16).
){kind=link}
The packet type–specific fields for IS-IS LAN hellos are as follows:
Circuit Type—Tells whether this circuit is Level 1-only, Level 2-only, or both.
Source ID—The SysID of the originator.
Holding Time—Tells how long to wait for hellos from this router before declaring it dead and removing its adjacency.
PDU Length—Length of the entire PDU, fixed header, and TLVs.
Priority—This 7-bit value designates the priority to be the DIS (Level 1 or Level 2) on the LAN.
LAN ID—SysID of the DIS plus an octet-long unique ID for this router assigned by the DIS.
The differences between LAN Level 1 and LAN Level 2 hellos is only in the interpretation of the values in the fields and the broadcast addresses to which they are transmitted. The MAC-level broadcast addresses are as follows:
01-80-C2-00-00-15 for Level 2 adjacencies (AllL2ISs)
01-80-C2-00-00-14 for Level 1 adjacencies (AllL1ISs)
The IS-IS PDU types for LAN Level 1 and Level 2 packets are 15 and 16, respectively. Example 3-1 shows a sample trace capture of a LAN Level 1 hello frame. The example displays a source address of 0x00D058F78941 and a destination or destination address of 0x0180C2000014. The target address is the AllL1IS address.
Example 3-1 Trace of IS-IS LAN Level 1 Hello
DLC: ----- DLC Header ----- DLC: DLC: Frame 1 arrived at 19:03:01.2025; frame size is 1514 (05EA hex) bytes. DLC: Destination = Multicast 0180C2000014 DLC: Source = Station 00D058F78941 DLC: 802.3 length = 1500 DLC: LLC: ----- LLC Header ----- LLC: LLC: DSAP Address = FE, DSAP IG Bit = 00 (Individual Address) LLC: SSAP Address = FE, SSAP CR Bit = 00 (Command) LLC: Unnumbered frame: UI |
The following TLVs fields can be found in LAN hello packets:
Area Addresses (Type 1)—Contains area addresses configured on the router
IS Neighbors (Type 6)—MAC addresses (SNPAs) of Level 1 (Level 2) neighbors that IIHs received from over the LAN interface in an initializing or up state
Padding (Type 8)—Used to make hello as large as MTU (or at least MTU - 1 octets)
Authentication (Type 10)—Password information
Forming LAN Adjacencies
When a LAN interface is enabled for IS-IS routing, the router immediately sends out IIH packets with a locally defined LAN ID, consisting of its own SysID and a unique local circuit ID. It also begins to listen to ESHs, ISHs, and IIHs to discover any connected adjacencies. It subsequently runs the DIS election process, depending on its configuration, to determine whether it is eligible to be a Level 1 or Level 2 DIS on the LAN.
The manner in which a router processes received IIHs depends on its configuration (IS type and circuit type). As in the case of point-to-point links, all IIHs received are checked for configuration conformity and authentication. The ID Length and Maximum Area Addresses fields in the received IIHs must match local values, and authentication passwords must be confirmed before the adjacency is further processed. Examples of additional information contained in hello packets are the neighbor's SysID, holding timer (holdtime), Level 1 or Level 2 priority, and configured area addresses.
A Level 1 adjacency is formed when the area addresses match unless configured otherwise. A Level 2 adjacency is formed alongside the Level 1 unless the router is configured to be Level 1-only. If no matching areas exist between the configuration of the local router and the area addresses information in the received hello, only a Level 2 adjacency is formed. If the transmitting router is configured for Level 2-only, the receiving router must be capable of forming a Level 2 adjacency; otherwise, no adjacency forms.
When a router receives a hello packet, it checks for an existing adjacency with the transmitter. If an adjacency is known, it resets the holdtime to the value in the hello received. If the neighbor is not known, the receiving router creates one, indicating the type of adjacency (Level 1 or Level 2) and sets its state to initializing until subsequent received hello packets confirm two-way communication. Routers include the MAC addresses of all neighbors on the LAN that they have received hellos from, allowing for a simple mechanism to confirm two-way communication. Two-way communication is confirmed when subsequent hellos received contain the receiving router's MAC address (SNPA) in an IS Neighbors TLV field. Otherwise, communication between the nodes is deemed one-way, and the adjacency stays at the initialized state. An adjacency must be in and up state for a router to send or process received LSPs.
Pseudonodes
As discussed in the preceding section, all IS-IS routers connected over a common LAN multicast hellos to well-known addresses, thereby forming adjacencies with each other.
After adjacency is determined, link-state information is exchanged (also referred to as LSP flooding). LSP flooding is the essence of dynamic routing information exchange between IS-IS routers. The two key requirements for LSP flooding are as follows:
Accuracy of information and timeliness of the updates
Minimum bandwidth usage and low processing overhead
Accuracy and timeliness imply spontaneous and frequent updates. This contradicts the need to conserve network resources, as stipulated by the requirement for minimum bandwidth usage and low processing overhead. This section focuses on the adjacency formation process and network resource management on multiaccess media.
To minimize the complexity of managing multiple adjacencies on multiaccess media, such as LANs, while enforcing efficient LSP flooding to minimize bandwidth consumption, IS-IS models multiaccess links as nodes, referred to as pseudonodes (see Figure 3-6). As the name implies, this is a virtual node, whose role is played by an elected DIS for the LAN. Separate DISs are elected for Level 1 and Level 2 routing. In the election process, only routers with adjacencies in an up state are considered. Election of the DIS is based on the highest interface priority, with the highest SNPA address (MAC address) breaking ties. The default interface priority on Cisco routers is 64.
){kind=link}
Despite the critical role of the DIS in LSP flooding, no backup DIS is elected for either Level 1 or Level 2. Fortunately, this doesn't turn out to be a contentious problem because of the frequency of periodic database synchronization that occurs on broadcast links. If the current DIS fails, another router is immediately elected to play the role. As mentioned previously, the DIS transmits hello packets three times faster than the interval for other routers on the LAN. The default hello interval for the DIS is 3.3 seconds rather than the 10 seconds specified for other nodes. This allows for quick detection of DIS failure and immediate replacement.
Figure 3-6 LAN Pseudonode.
As previously expressed, periodic database synchronization on broadcast links allows preemption of the existing DIS without significant disruption of IS-IS operation on such media. This implies that an elected router is not guaranteed to remain the DIS if a new router with a higher priority shows up on the LAN. Any eligible router at the time of connecting to the LAN immediately takes over the DIS role, assuming the pseudonode functionality. No mechanism is specified for making a router ineligible to be the DIS. However, this is achievable, to some extent, by configuring a router's LAN interface with the lowest priority value relative to the priorities of other nodes on the LAN.
The IS-IS specification (ISO 10589) defines three types of designated intermediate systems, as follows:
- LAN Level 1 DIS
- LAN Level 2 DIS
- Partition-designated Level 2 IS
Election of partition-designated Level 2 ISs is specified in ISO 10589 to provide a means for repairing partitioned Level 1 areas in an IS-IS domain. An IS-IS virtual link is established over the Level 2 backbone between partition-designated Level 2 routers, which are elected from among the Level 2 routers in the partitions. Intra-area traffic is then forwarded between the partitions over the virtual link. IS-IS partition repair is not supported on Cisco routers and, therefore, is not discussed further in this book.
The responsibilities of LAN Level 1 and Level 2 DISs include the following:
Generating pseudonode link-state packets to report links to all systems on the broadcast subnetwork
Carrying out flooding over the LAN for the corresponding routing level
The newly elected or resigning DIS is also responsible for purging the old pseudonode LSP from the network. A DIS might resign when preempted or when disconnected from the link either by an interface shutdown or the disabling of the IS-IS process. Because of its critical role, detection of DIS failure is expedited using a shorter hello interval, which is 3.3 seconds rather than the 10 seconds used for ordinary nodes.
The IS-IS Routing Engine
Figure 3-7 shows the IS-IS routing engine, which is adapted from the more elaborate representation of the processes that work together to provide the complex of subnetwork-independent functions defined in ISO 10589. This simplified representation shows only the relevant dependencies between various processes of the IS-IS protocol within the framework of a conventional router's forwarding architecture. The receiving and forwarding processes specified in ISO 10589 are not necessarily applicable to an IP router and are therefore not discussed. Identical but separate routing engine architecture is maintained for each of the two levels of routing.
){kind=link}
IP routers using Integrated IS-IS as the routing protocol conform to requirements for IP packet handling as specified by RFC 1812 (Requirements for Internet Gateways). Such IP routers must handle the ISO packets relevant to the operation of IS-IS and also must support other IP router functionality, such as Internet Message Protocol (ICMP) and Address Resolution Protocol (ARP).
Figure 3-7 IS-IS routing engine.
The Routing Information Base
The Routing Information Base is composed of two databases that are central to the operation of IS-IS: the Link-State database and the Forwarding database. The Link-State database is fed with routing information by the update process.
The Update Process
The update process generates local link-state information, based on the adjacency database built by the subnetwork-dependent functions, which the router advertises to all its neighbors in link-state packets. A router also receives similar link-state information from every adjacent neighbor, keeps copies of LSPs received, and re-advertises them to other neighbors. Routers in an area maintain identical Level 1 Link-State databases, which are synchronized using SNPs. This means that routers in an area will have identical views of the area topology, which is necessary for routing consistency within the area. A Level 2 Link-State database contains area prefix information that ties all the areas together for inter-area (Level 2) routing.
The Decision Process
The decision process creates the Forwarding database by running the shortest path first (SPF) algorithm (also referred to as the Dijkstra algorithm) on the Link-State database. A router runs separate SPF processes for Level 1 and Level 2.
Routing Table
The IS-IS Forwarding database, which is made up of only best IS-IS routes, is fed into the Routing Information Base (RIB), essentially the IP routing table of a router to be used in packet-switching decisions. When multiple sources exist for routing information in a router, such as static routes and BGP, a Cisco router uses the concept of administrative distances to prefer one routing source to the others. The protocol with the lowest administrative distance wins. (Table 3-3 lists administrative distances for various routing protocols.) The accepted best route is then installed in the routing table. Routing table information might be processed further into the fast-switching cache or the Cisco Express Forwarding (CEF) Forwarding Information Base (FIB) to speed up switching packets through the router. Typically, IS-IS is used in conjunction with BGP for routing IP packets. BGP brings in external routes, whereas IS-IS, as an IGP, is responsible for internal routes (mostly next-hop information for the BGP routes). Consequently, little overlap occurs in routing information obtained from either source, allowing IS-IS and BGP routes to coexist in the routing table.
Table 3-3 Administrative Distances of Routing Protocols
|
Route Protocol |
Administrative Distance |
|
RIP v1 and v2 |
120 |
|
IGRP |
100 |
|
EIGRP Internal |
90 |
|
EIGRP External |
170 |
|
OSPF |
110 |
|
Integrated ISIS |
115 |
|
BGP Internal |
20 |
|
BGP External |
200 |
|
Static to Next Hop |
1 |
|
Static to Interface |
1 |
|
Connected |
0 |