CCIE Professional Development: Routing TCP/IP Volume I
Author: Jeff Doyle
Publisher: Cisco Press (53)
When the terms link state protocol and IP
are mentioned together, almost everyone thinks of OSPF. Some may say, “Oh,
yeah, there's also IS-IS, but Idunnomuchaboutit.” Only a few will think
of Integrated IS-IS as a serious alternative to OSPF. However, those few do
exist, and there are internetworksincluding a few ISPsthat route
IP with IS-IS.
IS-IS, which stands for Intermediate
System to Intermediate System, is the routing protocol for the ISO's Connectionless
Network Protocol (CLNP) and is described in
ISO 10589.1 The protocol was developed by Digital Equipment Corporation for
its DECnet Phase V.
The ISO was working on IS-IS at more or less the same time that the
Internet Architecture Board (IAB) was working on OSPF, and there was a proposal
that IS-IS be adopted as the routing protocol for TCP/IP in place of OSPF.
This proposal was driven by the opinion, popularly held in the late 1980s
and early 1990s, that TCP/IP was an interim protocol suite that would eventually
be replaced by the OSI suite. Adding impetus to this movement toward OSI were
specifications such as the United States' Government Open Systems Interconnection
Profile (GOSIP) and the European Procurement Handbook for Open Systems (EPHOS).
To support the predicted transition from
TCP/IP to OSI, an extension to IS-IS, known as Integrated IS-IS, was proposed2.
The purpose of Integrated IS-IS, also known as Dual
IS-IS, was to provide a single routing protocol with the capabilities of routing
both CLNS 3 and IP. The protocol was designed to operate in a pure
CLNS environment, a pure IP environment, or a dual CLNS/IP environment.
Saying that battle lines were drawn may be overly dramatic, but at the
least strong pro-ISO and pro-OSPF factions developed. It can be enlightening
to read and contrast the coverage of OSPF and IS-IS in the well-known books
by Christian Huitema,4 a past chairman of the IAB,
and Radia Perlman5, the chief designer of IS-IS. In the end, the Internet Engineering
Task Force (IETF) adopted OSPF as the recommended IGP. Technical differences
certainly influenced the decision, but so did political considerations. ISO
standardization is a slow, four-step process that depends upon the voted approval
of many committees. The IETF, on the other hand, is much more freewheeling.
A statement made in 1992 has been its informal motto: “We reject kings,
presidents, and voting; we believe in rough consensus and running code.”6
Letting OSPF evolve through the RFC process made more sense than adopting
the more formalized IS-IS.
Despite the political friction, the OSPF Working Group learned from
and capitalized on many of the basic mechanisms designed for IS-IS. On the
surface, OSPF and
IS-IS have many features in common:
They both maintain a link state database from which a Dijkstra-based
SPF algorithm computes a shortest-path tree.
They both use Hello packets to form and maintain adjacencies.
They both use areas to form a two-level hierarchical topology.
They both have the capability of providing address summarization
They both are classless protocols.
They both elect a designated router to represent broadcast
They both have authentication capabilities.
Below these similarities, there are distinct differences. This chapter begins by examining those
differences. Integrated IS-IS (henceforth referred to simply as IS-IS) is
covered only as an IP routing protocol; CLNS is discussed only when it is relevant to using IS-IS to route IP.
1 International Organization for
Standardization, “Intermediate System to Intermediate System Intra-Domain
Routeing Information Exchange Protocol for Use in Conjunction with the Protocol
for Providing the Connectionless-mode Network Service (ISO 8473),”
ISO/IEC 10589, 1992.
2 Ross Callon, “Use of OSI
IS-IS for Routing in TCP/IP and Dual Environments,” RFC 1195, December
3 Connectionless-Mode Network Servicethe
network layer protocol of CLNP.
4 Christian Huitema, Routing in
the Internet, Prentice Hall PTR, Englewood Cliffs, NJ, 1995.
5 Radia Perlman, Interconnections:
Bridges and Routers, Addison-Wesley, Reading, MA, 1992.
6 Dave Clark, quoted in Huitema,
The ISO often uses different terms than the IETF to describe the same
entities, a fact that can sometimes cause confusion. ISO terms are introduced
and defined in this section, but in most cases the more familiar IETF terminology
used throughout the rest of this book is used in this chapter.7
Some ISO terms are so fundamental that they should be discussed before getting
into any specifics of the IS-IS protocol.
A router is an Intermediate System (IS),
and a host is an End System (ES). Accordingly, a protocol
that provides communication between a host and a router is known as ES-IS,
and a protocol that routers use to speak to each other (a routing protocol)
is IS-IS (Figure 10.1). Whereas IP uses router
discovery mechanisms, such as
Proxy ARP or IRDP, or simply has a default gateway configured on hosts, CLNP
uses ES-IS to form adjacencies between End Systems
and Intermediate Systems. ES-IS has no relevance to IS-IS for IP and is not
covered in this book.
Figure 10.1. Hosts are End Systems in ISO terminology, and routers are Intermediate
An interface attached to a subnetwork is a Subnetwork Point of Attachment
(SNPA). An SNPA is somewhat
conceptual because it actually defines the point at which subnetwork services
are provided, rather than an actual physical interface. The conceptual nature
of SNPAs fits with the conceptual nature of subnetworks themselves, which
can consist of multiple data links connected by data link switches.
A data unit passed from an OSI layer of one node to the peer OSI layer
of another node is called a Protocol Data Unit
(PDU). So a frame is a Data Link PDU (DLPDU), and a packet is a Network PDU
(NPDU). The data unit that performs the equivalent function of the OSPF LSA
is the Link
State PDU (LSP).8 Unlike LSAs, which are encapsulated
behind an OSPF header and then an IP packet,
an LSP is itself a packet.
Although both IS-IS and OSPF use areas to create a two-level hierarchical
topology, a fundamental difference exists in the way in which the two protocols
define their areas. OSPF area borders are marked by routers, as shown in Figure 10.2. Some interfaces are in one area, and
other interfaces are in another area. When an OSPF router has interfaces in
more than one area, it is an Area
Border Router (ABR).
Figure 10.2. OSPF area borders fall within routers, and the routers that connect
the areas are ABRs.
Figure 10.3 shows the same topology as shown in Figure 10.2 but with IS-IS areas. Notice that all
the routers are completely within an area, and the area borders are on links,
not on routers. The routers that connect the areas are level 2routers,
and routers that have no direct connectivity to another area are level
Figure 10.3. IS-IS areas fall on links, and the routers that connect the areas are
level 2 routers.
An intermediate system can be a level 1 (L1) router, a level 2 (L2)
router, or both (L1/L2). L1 routers are analogous to OSPF
nonbackbone Internal Routers, L2 routers are analogous to OSPF backbone routers,
and L1/L2 routers are analogous to OSPF ABRs. In Figure 10.3,
the L1/L2 routers are connected to L1 routers and to L2 routers. These L1/L2 routers
must maintain both a level 1 link state database and a level 2 link state
database, in much the same way that an OSPF ABR must maintain a separate database
for each area to which it is attached.
The set of L2 routers (including L1/L2 routers) and their interconnecting
links is the IS-IS backbone; as with OSPF, inter-area traffic must traverse
this backbone. Every level 1 router within an area (including the area's L1/L2
routers) maintains an identical link state database. Unlike OSPF ABRs, L1/L2
routers do not advertise L2 routes to L1 routers. Therefore, an L1 router
has no knowledge of destinations outside of its own area. In this sense, an
L1 router is similar to a router in an OSPF totally stubby area. To route
a packet to another area, an L1 router must forward the packet to an L1/L2
router. When an L1/L2 router sends its level 1 LSP into an area, it signals
other L1 routers that it can reach another area by setting a bit known as the Attached
(ATT) bit9 in the LSP.
Recall from Chapter 9, “Open Shortest Path
First,” that OSPF runs its SPF algorithm to compute routes within
an area, but that inter-area routes are computed using a distance vector algorithm.
This situation is not true of IS-IS. L1/L2 routers, maintaining separate level
1 and level 2 link state databases, will calculate separate SPF trees for
the level 1 and level 2 topology.
ISO 10589 describes a procedure by which IS-IS routers can create virtual
links to repair partitioned areas, just as OSPF can. This feature is not supported
by Cisco or by most other router vendors and is not further described here.
Because an IS-IS router resides completely within a single area, the
Area ID (or area address)
is associated with the entire router rather than an interface. A unique feature of IS-IS is
that a router can have up to three area addresses, which can be useful during area transitions.
A configuration case study later in this chapter, “An Area Migration,”
demonstrates the use of multiple area addresses. Each IS-IS router must also
have a way to uniquely identify itself within the routing domain. This identification
is the function of the System ID,
which is analogous to the OSPF Router ID. Both the Area ID and the System
ID are defined on an IS-IS router by a single address, the Network Entity Title (NET).
Even when IS-IS is used to route only
TCP/IP, IS-IS is still an ISO CLNP protocol. Consequently, the packets by
which IS-IS communicates with its peers are CLNS PDUs, which in turn means
that even in an IP-only environment, an IS-IS router must have an ISO address.
The ISO address is a network address, known as Network Entity Title
(NET), described in ISO 8348.10 The length of a
NET can range from 8 to 20 octets; the NET describes both the Area ID and
the System ID of a device, as shown in Figure 10.4.
Figure 10.4. The NET specifies the Area ID and the System ID of an IS or ES.
The ISO designed the NET to be many things to many systems, and depending
upon your viewpoint, the address format is either extremely flexible and scalable
or it is a cumbersome muddle of variable fields. Figure
10.5 shows just three of the many forms an ISO NET can take. Although
the fields preceding the System ID are
different in each example, the System ID itself is the same. ISO 10589 specifies
that the field can be from one to eight octets in length, but that the System ID of all nodes within the routing domain must
use the same length. Most commonly, the length is six octets11 and is usually
the Media Access Control (MAC) identifier of an interface on the device. The
System ID must be unique for each node within the routing domain.
Figure 10.5. Three NET formats: A simple eight-octet Area ID/System ID format (a);
an OSI NSAP format (b); and a GOSIP NSAP format12
Also of interest in the examples of Figure
10.5 is the NSAP Selector (SEL). In each case, this one-octet field is set
to 0x00. A Network Service Access Point (NSAP) describes an attachment to a particular service at the network layer of
a node. So when the SEL is set to something other than 0x00 in an ISO address
the address is an NSAP address. This situation is similar to the combination
of IP destination address and IP protocol number in an IP packet, which addresses
a particular service at the network layer of a particular device's TCP/IP
stack. When the SEL is set to 0x00 in an ISO address, the address is a NET,
the address of a node's network layer itself.
As the variety of formats in Figure 10.5
implies, a detailed discussion of the configuration of NETs is beyond the
scope of this book. A good reference for further study is RFC 1237.13 In most
cases, Integrated IS-IS will be run in a dual CLNP/IP environment, and the
NET will be assigned based on the CLNP requirements. In an IP-only environment,
the NET might be assigned based on a standard such as GOSIP. If you are free
to choose any NET for an IP-only environment, choose the simplest format that
will serve the needs of your internetwork.
Regardless of the format, the following three rules apply:
The NET must begin with a single octet (for example, 47.xxxx…).
The NET must end with a single octet, which should be set
to 0x00 (…xxxx.00). IS-IS will function if the SEL is non-zero but
a dual CLNP/IP router may experience problems.
On Cisco routers, the System ID of the NET must be six octets.
One of the primary reasons for having a layered network architecture like
the OSI model is so that the functions of each layer are independent from
the layer below. The network layer, for example, must adapt to many types
of data links, or subnetworks. To further this adaptability, the network layer
consists of two sublayers (Figure 10.6). The Subnet work Independent
sublayer provides consistent, uniform network services to the transport
layer. The Subnetwork Dependent sublayer accesses the
services of the data link layer on behalf of the Subnetwork Independent sublayer.
As the two names imply, the Subnetwork Dependent sublayer depends upon a specific
type of data link, so that the subnetwork independent sublayer can be independent
of the data link.
Figure 10.6. The OSI network layer consists of two sublayers.
The organization of the network layer, specified in ISO 8648,14
is actually more complex than that shown in Figure
10.6. The two basic sublayers are introduced here because ISO 10589
presents much of its description of the operation of IS-IS within the framework
of the functions of these sublayers.
The subnetwork dependent functions are, of course, the functions of
the subnetwork dependent sublayer. Their job is to hide the characteristics
of different kinds of data links (subnetworks) from the functions of the subnetwork
independent sublayer. The following subnetwork dependent functions are important
The transmission and reception of PDUs over the specific attached
The exchange of IS-IS Hello PDUs to discover neighbors and
establish adjacencies on the subnetwork
The maintenance of the adjacencies
Link demultiplexing, or the transfer of OSI PDUs to the OSI
process and the transfer of IP packets to the IP process
In contrast to the four network types defined by OSPF, IS-IS defines
only two: broadcast subnetworks and point-to-point or general topology subnetworks.Broadcast
subnetworks are defined the same as they are under OSPFmulti-access
data links that support multicasting. Point-to-point (nonbroadcast) subnetworks
can be permanent, such as a T1 link, or dynamically established, such as X.25
IS-IS routers discover neighbors
and form adjacencies by exchanging IS-IS Hello PDUs. Hellos are transmitted
every 10 seconds, and on Cisco routers this interval can be changed
on a per interface basis with the command
isis hello-interval. Although IS-IS Hellos are slightly different
for broadcast and point-to-point subnetworks, the Hellos include the
same essential information, described in the section “IS-IS
PDU Formats.” An IS-IS router uses its Hello
PDUs to identify itself and its capabilities and to describe the parameters
of the interface on which the Hellos are sent. If two neighbors are
in agreement about their respective capabilities and
interface parameters, they become adjacent.
IS-IS forms separate adjacencies for level 1 and level 2 neighbors.
L1 routers form L1 adjacencies with L1 and L1/L2 neighbors, and L2 routers
form L2 adjacencies with L2 and L1/L2 neighbors. Neighboring L1/L2 routers
form both an L1 adjacency and an L2 adjacency. An L1 router and an L2 router
will not establish an adjacency.
Once an adjacency is established, the Hellos act as keepalives. Each router sends a hold
time in its Hellos, informing its neighbors how long they should
wait to hear the next Hello before declaring the router dead. The default
hold time on Cisco routers is three times the Hello interval and can be changed
on a per
interface basis with the command isis hello-multiplier.
The IS-IS neighbor table can be observed with the command show
clns is-neighbors(Figure 10.7).
The first four columns of the display show the System
ID of each neighbor, the interface on which the neighbor is located, the state
of the adjacency, and the adjacency type. The state will be either Init, indicating
that the neighbor is known, but is not adjacent, or Up, indicating that the neighbor
is adjacent. The priority is the router priority used for electing a Designated
Router on a broadcast network, as described in the next section.
Figure 10.7. The command show clns is-neighbors displays the IS-IS neighbor table.
The sixth column shows the Circuit ID, a one-octet
number that the router uses to uniquely identify the IS-IS interface. If the
interface is attached to a broadcast multiaccess network, the Circuit ID is concatenated with the System ID of the network's
Designated Router, and the complete number is known as the LAN
ID. In this usage, the Circuit ID is more correctly called the Pseudonode ID. For example, in Figure
10.7 the LAN ID of the link attached to interface E0 is 0000.0c76.5b7c.02.
The System ID of the Designated Router
is 0000.0c76.5b7c, and the Pseudonode ID is 02.
The last column indicates the format of the adjacency. For Integrated
IS-IS the format will always be Phase V, indicating OSI/DECnet Phase V. The
only other adjacency format is DECnet Phase IV.
IS-IS elects a Designated Router (or more officially, a Designated IS) on broadcast
multi-access networks for the same reason OSPF does. Rather than having each
router connected to the LAN advertise an adjacency with every other router
on the network, the network itself is considered a routera pseudonode.
Each router, including the Designated Router, advertises a single link to
the pseudonode. The DR also advertises, as the representative of the pseudonode,
a link to all of the attached routers.
Unlike OSPF, however, an IS-IS router attached to a broadcast multi-access
network establishes adjacencies with all of its neighbors on the network,
not just the DR. Each router multicasts its LSPs to all of its neighbors,
and the DR uses a system of PDUs called Sequence
Number PDUs (SNPs) to ensure that the flooding of LSPs is reliable.
The reliable flooding process, and SNPs, are described in a later section,
“The Update Process.”
The IS-IS Designated Router election process is quite simple. Every IS-IS router interface
is assigned both an L1 priority and an L2 priority in the range of 0 to 127.
Cisco router interfaces have a default priority of 64 for both levels, and
this value can be changed with the command isis priority.
The router advertises its priority in the Hellos sent from each interfacethe
L1 priority is advertised in L1 Hellos, and the L2 priority is advertised
in L2 Hellos. If the priority is 0, the router is ineligible to become the
DR. Interfaces to nonbroadcast networks, on which a DR is not elected, also
have a priority of 0 (notice the priority of the serial interface in Figure 10.7). The router with the highest priority
becomes the DR. In a tie, the router with the numerically highest System ID
becomes the DR.
As the L1 and L2 priorities suggest, separate DRs are elected on a network
for level 1 and level 2. This outcome is necessary because of the separate
L1 and L2 adjacencies that can exist on a single LAN, as shown in Figure
10.8. Because an interface can have separate priorities for each level,
the L1 DR and the L2 DR on a LAN might or might not be the same router.
The DR assigns the LAN ID to the network. As discussed in the preceding
section, the LAN ID is a concatenation of the DR's System ID and its Pseudonode
ID for the attached network. All other routers on the network will use the
LAN ID assigned by the DR.
Figure 10.9 shows the neighbor table
of a router whose E0 interface is attached to the same network as the E0 interface
of the router of Figure 10.7. By comparing
these two tables, you can see that three routers are attached to the Ethernet:
0000.0c0a.2aa9, 0000.0c0a.2c51, and 0000.0c76.5b7c. All have a priority of
64, so the one with the numerically highest System ID is the DR. That router,
0000.0c76.5b7c, identifies the network with Circuit ID 02. Therefore, the LAN
ID shown in both Figure 10.7 and Figure
10.9 is 0000.0c76.5b7c.02.
Figure 10.8. Separate adjacencies are established for level 1 and for level 2, so
separate DRs must be elected for level 1 and level 2.
Figure 10.9. The E0 interface of this router is attached to the same network as
the E0 interface of the router in Figure 10.7.
Appending the Circuit ID to the System ID is necessary because the same router
can be the DR on more than one network. Notice in Figure
10.7 that the same router is the DR on the network attached to E0 and
the network attached to E1. It is the Circuit ID, 02 on E0 and 03 on E1, which
makes the LAN ID unique for each network.
The IS-IS DR process is more primitive (or less complex, depending upon
one's viewpoint) than the OSPF DR process in two ways. First, IS-IS does not
elect a Backup Designated Router. If the IS-IS DR fails, a new DR is elected.
Second, the IS-IS DR is not as stable as the OSPF DR. If an OSPF router becomes
active on a network with an existing DR, the new router will not become the
DR even if its priority or Router ID is higher. As a result, the OSPF DR usually
is the router that has been active on the network for the longest time. In
contrast to the OSPF rules, a new IS-IS router with
h a higher priority than
the existing DR, or an equal priority and a higher System ID, will become
the new DR. Each time the DR is changed, a new set of LSPs must be flooded.
The functions of the subnetwork-independent
sublayer define how CLNS delivers packets throughout the CLNP internetwork
and how these services are offered to the transport layer. The routing function
itself is divided into four processes: the Update process, the Decision process,
the Forwarding process, and the Receive process. As the names of the last
two processes suggest, the Forwarding process is responsible for transmitting
PDUs, and the Receive process is responsible for the reception of PDUs. These
two processes, as described in ISO 10589, are more relevant to CLNS NPDUs
than to IP packets, and so are not described further.
process is responsible
for constructing the L1 and L2 link
state databases. To do so, L1 LSPs are flooded throughout an area, and
L2 LSPs are flooded over all L2 adjacencies. The specific fields of
the LSPs are described in the section “IS-IS
Each LSP contains a Remaining Lifetime, a
Sequence Number, and a Checksum. The Remaining Lifetime is an age. The difference
between an IS-IS LSP's Remaining Lifetime and an OSPF LSA's Age parameter
is that the LSA Age increments from zero to MaxAge, whereas the LSP Remaining
Lifetime begins at MaxAge and decrements to zero. The IS-IS MaxAge is 1200
seconds (20 minutes). Like OSPF, IS-IS ages each LSP as it resides in the
link state database, and the originator must periodically refresh its LSAs to prevent the Remaining
Lifetime from reaching zero. The IS-IS refresh interval is 15 minutes minus
a random jitter of up to 25%. If the Remaining Lifetime reaches
zero, the expired LSP will be kept in the link state database for 60 seconds,
known as the ZeroAgeLifetime.
If any router receives a LSP with an incorrect Checksum, the router
will purge the LSP by setting the LSP's Remaining Lifetime to zero and reflooding
it. The purge causes the LSP's originator to send a new instance of the LSP.
This procedure is yet another way that IS-IS differs from OSPF, where only
the originator can purge an OSPF LSA.
On error-prone subnetworks, allowing receiving routers to initiate purges
can significantly increase the LSP traffic. To override this behavior, the command ignore-lsp-errors can be added to the IS-IS routing
configuration. When a router with this option enabled receives a corrupted
LSP, it ignores it rather than purging it. The originator of the corrupted
LSP will still know that the LSP was not received through the use of SNPs,
described later in this section.
The Sequence Number is an unsigned, 32-bit linear number. When a router
first originates an LSP, it uses a Sequence Number of one, and each subsequent
instance of the LSP has its Sequence Number incremented by one. If the Sequence
Number increments to the maximum (0xFFFFFFFF), the IS-IS process must shut
down for at least 21 minutes (MaxAge + ZeroAgeLifetime) to allow the old LSPs
to age out of all databases.
On point-to-point subnetworks, routers send L1 and L2 LSPs directly to the neighboring
router. On broadcast subnetworks, the LSPs are multicast to all neighbors. Frames carrying
L1 LSPs have a destination MAC identifier of 0180.c200.0014, known
as AllL1ISs. Frames carrying L2 LSPs have a destination MAC identifier of 0180.c200.0015,
known as AllL2ISs.
IS-IS uses SNPs both to acknowledge the receipt of LSPs and to maintain link state database synchronization. There are
two types of SNPs: Partial SNPs
(PSNPs) and Complete SNPs (CSNPs). On a point-to-point subnetwork, a router uses a PSNP to explicitly acknowledge each
LSP it receives.15 The PSNP describes the LSP it is acknowledging by including
the following information:
When a router sends an LSP on a point-to-point subnetwork, it sets
a timer for a period known as minimumLSPTransmissionInterval.
If the timer expires before the router receives a PSNP acknowledging
receipt of the LSP, a new LSP will be sent. On Cisco routers, the default
is five seconds and can be changed on a per interface basis with the
On broadcast subnetworks, LSPs are not acknowledged by each receiving
router. Instead, the DR periodically multicasts a CSNP that describes every
LSP in the link state database. The default CSNP period is 10 seconds and
can be changed with the command isis csnp-interval.
L1 CSNPs are multicast to AllL1ISs (0180.c200.0014), and L2 CSNPs are multicast
to AllL2ISs (0180.c200.0015).
When a router receives a CSNP, it compares the LSPs summarized in the PDU with the LSPs
in its database. If the router has an LSP that is missing from the CSNP or a newer instance of an LSP, the
router multicasts the LSP onto the network. If another router sends the updated
LSP first, however, the router will not send another copy of the same LSP.
If the router's database does not contain a copy of every LSP listed in the
CSNP or if the database contains an older instance of an LSP, the router multicasts a PSNP listing
the LSPs it needs. Although the PSNP is multicast, only the DR responds with
the appropriate LSPs.
An interesting feature of IS-IS is its ability to signal other routers
if it runs out of memory and cannot record the complete link state database.
The memory overload might be due to an area that has been allowed to grow
too large, a router with insufficient memory, or a transitory condition such
as the failure of a DR. If a router cannot store the complete link state database,
it will set a bit in its LSP called the Overload (OL) bit.
The OL bit signals that the router might not be able to make correct
routing decisions because of its incomplete database. The other routers still
route packets to the overloaded router's directly connected networks, but
do not use the router for transit traffic until it has issued an LSP with
the OL bit cleared. Because a set OL bit prevents the router from being used
as a hop along a route, the bit is frequently called the hippity
bit (as in hippity-hop, believe it or not).
Memory should be allocated equally to the L1 and the L2 database, but
a router can be in an overload condition at one level and normal in the other.
If you want to intentionally set an IS-IS router to act only as an end node,
the OL bit can be set manually with the command set-over-load-bit.
The command show isis database displays
a summary of the IS-IS link state database, as shown in Figure
10.10. The router Brussels in this figure is an L1/L2 router, so it
has both L1 and L2 databases. The LSP ID shown in the first column consists
of the System ID of the originating router, concatenated with two more octets.
The first octet following the System ID is the Pseudonode ID. If this octet is nonzero,
the LSP was originated by a DR. The System ID and the nonzero Pseudonode ID
together make the LAN ID of a broadcast subnetwork.
The last octet is the LSP Number. Occasionally, an LSP can be so large that it exceeds
the MTU that can be supported by the router buffers or the data link. In this case,
the LSP is fragmentedthat is, the information
is conveyed in multiple LSPs. The LSP IDs of these multiple LSPs consist of identical
System IDs and Pseudonode IDs, and distinct LSP Numbers.
Figure 10.10. The IS-IS database can be observed with the command show isis database.
An asterisk following the LSP ID indicates that the LSP is originated by the router on which
the database is being observed. For example, the database shown in Figure
10.10 is taken from a router named Brussels. The L1 LSP with an ID
of 0000.0c76.5bB7c.00-00 is originated by Brussels, as are four other LSPs.
The second and third columns of the database display show the Sequence
Number and Checksum of each LSP. The fourth column, LSP Holdtime, is the Remaining
Lifetime of the LSP in seconds. If you enter the show
isis database command repeatedly, you can observe the
numbers decrementing. When the LSP is refreshed, the Remaining Lifetime is
reset to 1200 seconds and the Sequence Number is incremented by one.
The last column indicates the state of the Attached (ATT) bit, the Partition
(P) bit, and the Overload (OL) bit of each LSP. L2 and L1/L2 routers will
set the ATT bit to one to indicate that they have a route to another area.
The P bit indicates that the originating router has partition repair capability.
Cisco (and most other vendors) does not support this function, so the bit
is always set to zero. The OL bit is set to one if the originating router
is experiencing a memory overload and has an incomplete link state database.
A complete LSP
can be observed by using the command show
isis database detail along with the level and the LSP ID, as shown
in Figure 10.11.
The meanings of
the individual fields of the
LSP are given in “IS-IS PDU
Figure 10.11. The command show isis database detail is used to observe complete LSPs
in the database.
Once the Update process has built the link state database,
the Decision process uses the information in the database to calculate a shortest
path tree. The process then uses the shortest path tree to construct a forwarding
database (route table). Separate SPF calculations are run for the L1 routes
and the L2 routes.
ISO 10589 specifies the following metrics (one required and three
optional) to be used by IS-IS to calculate the shortest path:
Default. This metric must be supported and
understood by every IS-IS router.
Delay. This optional metric reflects the transit
delay of a subnetwork.
Expense. This optional metric reflects the
monetary cost of using the subnetwork.
Error. This optional metric reflects the residual
error probability of the subnetwork, similar to the IGRP/EIGRP reliability
Each metric is expressed as an integer between 0 and 63, and a
separate route is calculated for each metric. Therefore, if a system supports
all four metrics, the SPF calculation must be run four times for both L1 routes
and L2 routes. Because of the potential for many iterations of the SPF calculation
for every destination, resulting in many different route tables, and because
the optional metrics provide rudimentary Type of Service routing at best,
Cisco supports only the default metric.
Cisco assigns a default metric of 10 to every interface, regardless
of the interface type. The command isis metric changes
the value of the default metric, and the default can be changed separately
for level 1 and level 2. If the metrics are left at 10 for every interface,
every subnetwork is considered equal and the IS-IS metric becomes a simple
measure of hop count, where each hop has a cost of 10.
The total cost of a route is a simple sum of
the individual metrics at each outgoing interface, and the maximum metric
value that can be assigned to any route is 1023. This small maximum is frequently
pointed out as a limitation of IS-IS because it leaves little room for metric
granularity in large internetworks. The flip side of this criticism, however,
is that limiting the metric to 1023 makes the SPF algorithm more efficient.
IS-IS not only classifies routes as L1 or L2 but also classifies routes
as internal or external. Internal
routes are paths to destinations within the IS-IS routing domain, and external
routes are paths to destinations external to the routing domain. Whereas L2
routes may be either internal or external, L1 routes are always internal.
Given multiple possible routes to a particular destination, an L1 path
is preferred over an L2 path. Within each level, a path that supports the
optional metrics is preferred over a path that supports only the default metric.
(Again, Cisco supports only the default metric, so the second order of preference
is not relevant to Cisco routers.) Within each level of metric support, the
path with the lowest metric is preferred. If multiple equal-cost, equal-level
paths are found by the Decision process, they are all entered into the route
table. Cisco's IS-IS implementation will perform equal-cost
load balancing on up to six paths.
The previous section, “The Update
Process,” discussed the last octet of the LSP ID, known as
the LSP Number, used to track fragmented LSPs. The Decision process
pays attention to the LSP Number for several reasons. First, if an LSP
with an LSP Number of zero and a nonzero Remaining Lifetime is not present
in the database, the Decision process will not process any LSPs from
the same system that have nonzero LSP
Numbers. For example, if the LSP IDs 0000.0c76.5b7c.00-01 and 0000.0c76.5b7c.00-02
exist in the database,
but the database contains no LSP with an LSP ID of 0000.0c76.5b7c.00-00,
the first two LSPs are not processed. This approach ensures that incomplete
LSPs do not cause inaccurate routing decisions.
Also, the Decision process will accept the following information only
from LSPs whose LSP Number is zero:
The setting of the Database Overload bit
The setting of the IS Type field
The setting of the Area Addresses option field
The Decision process ignores these settings in LSPs whose LSP Number
is nonzero. In other words, the first LSP in a series of fragments speaks
for all the fragments for these three settings.
Figure 10.12 shows a route table from
a Cisco IS-IS router. Notice that the L1 and L2 routes are indicated and that
three destinations have multiple paths. A mask is associated with each route,
indicating support for VLSM. Finally, the route table indicates that the administrative
distance of IS-IS routes is 115.
Figure 10.12. This route table shows both level 1 and level 2 IS-IS routes.
Another duty of the Decision process in L1 routers is to calculate the
path to the nearest L2 router, for inter-area routing. As previously discussed,
when an L2 or L1/L2 router is attached to another area, the router will advertise
the fact by setting the ATT bit in its LSP to one. The Decision process in
L1 routers will choose the metrically closest L1/L2 router as the default
inter-area router. When IS-IS is used to route IP, a default IP route to the
L1/L2 is entered into the route table. For example, Figure 10.13 shows a link
state database for an L1 router and its associated route table. LSP 0000.0c0a.2c51.00-00
has an ATT = 1. Based upon this information, the Decision process has chosen
the router with System ID 0000.0c0a.2c51 as the default inter-area router.
The route table shows a default route (0.0.0.0) via 10.1.255.6, with a metric
of 10. Although it is not readily apparent from the information shown
in Figure 10.13, 10.1.255.6 and System ID 0000.0c0a.2c51
refer to the same router.
The information in Figure 10.13 illustrates
a basic problem of working with Integrated IS-IS, particularly when troubleshooting.
Although TCP/IP is the protocol being routed, the protocol determining the
routes, including all the route control packets and addresses, is a CLNS protocol.
Sometimes correlating the CLNS information with the IP information can be
difficult. One command that can be useful is which-route.
Figure 10.13. Integrated IS-IS adds a default IP route to the nearest L1/L2 router
whose ATT bit is set to one.
The command is used primarily to determine the route table in which
a particular CLNS destination is located. However, which-routecan
also yield useful information about the IP addresses associated with a particular
CLNS address. In Figure 10.14 the System
ID/Circuit ID 0000.0c0a.2c51.00, shown in the database of Figure
10.13 as having ATT = 1, is used as the argument to which-route.
The result shows, among other things, that the next-hop address for the queried System
ID is 10.1.255.6.
IS-IS uses nine PDU types in its processes, and each
PDU is identified by a five-bit type number. The PDUs fall into three categories,
as shown in Table 10.1.
The first eight octets of all of the IS-IS PDUs are header fields that
are common to all PDU types, as shown in Figure
10.15. These first fields are described here, and the PDU-specific
fields are described in subsequent sections.
Figure 10.14. The command which-route can reveal some information tying CLNS addresses
to IP addresses.
Table 10.1. IS-IS PDU types.
Level 1 LAN IS-IS Hello
2 LAN IS-IS Hello PDU
Point-to-point IS-IS Hello PDU
Link State PDUs
Level 1 LSP
Level 2 LSP
Sequence Numbers PDUs
Level 1 CSNP
Level 2 CNSP
Level 1 PSNP
Level 2 PSNP
Intradomain Routeing Protocol Discriminator
is a constant assigned by ISO 957716 to identify NPDUs. All IS-IS PDUs have
a value of 0x83 in this field.
specifies the length of the fixed header in octets.
Version/Protocol ID Extension is always set to one.
Length describes the length of the System ID field of NSAP addresses
and NETs used in this routing domain. This field is set to one of the following
An integer between 1 and 8 inclusive, indicating a System
ID field of the same length in octets
0, indicating a System ID field of six octets
255, indicating a null System ID field (zero octets)
The System ID of Cisco routers must be six octets, so the ID Length
field of a Cisco-originated PDU will always be zero.
PDU Typeis a five-bit field containing one of the
PDU type numbers shown in Table 10.1. The
preceding three bits (R) are reserved and are always set to zero.
Version is always set to one, just like the Version/Protocol
ID Extension in the third octet.
Reserved is always set to all zeroes.
Maximum Area Addresses describes the number of
area addresses permitted for this IS area. The number is set to one of the
An integer between 1 and 254 inclusive, indicating the number
of areas allowed
0, indicating that the IS only supports a maximum of three
Cisco IOS supports a maximum of three areas, so the Maximum Area Addresses
field in IS-IS PDUs originated by Cisco routers will always be zero.
In Figure 10.16, an analyzer capture
of an IS-IS PDU shows the first eight octets of the PDU.
The PDU-specific fields following
the common header fields are also part of the header; they vary according
to PDU type and are discussed in the sections dealing with specific PDU types.
The variable-length fields following the PDU-specific fields are Code/Length/Value(CLV)17
triplets, as shown in Figure 10.17. The Code
is a number specifying the information content of the value field, the Length
specifies the length of the Value field, and the Value field is the information
itself. As the one-octet size
of the Length field implies, the maximum size of the Value field is 255 octets.
Figure 10.16. This analyzer capture shows the first eight fields of an IS-IS PDU,
along with its data link header.
Figure 10.17. IS-IS Code/Length/Value triplets perform the same function for IS-IS
as Type/Length/Value triplets perform for EIGRP.
Table 10.2 lists the IS-IS CLV codes. The table also indicates whether the CLV is specified
in ISO 10589 or in RFC 1195. The ISO-specified CLVs are designed for use with
CLNP, although most of them are also used with IP. The RFC-specified CLVs
are designed only for IP. If a router does not recognize a particular CLV
code, it will ignore the CLV. This arrangement allows CLVs for CLNP, IP, or
both to be carried in the same PDU.
Table 10.2. CLV codes used with IS-IS.
IS Neighbors (LSPs)
Designated level 2 IS†
IP Internal Reachability Information
IP External Reachability Information
Inter-Domain Routing Protocol Information
IP Interface Address
* The ES-Neighbors
and Prefix Neighbors CLVs are not relevant to IP routing and are
not covered in this book.
†This CLV is used for partition
repair, which Cisco does not support.
‡RFC 1195 specifies this code
for IP authentication, but Cisco uses the ISO code of 10.
Although many of the CLVs are used by more than one IS-IS PDU type, only one (Authentication)
is used by all PDUs. As the formats of the IS-IS PDUs are described in the
following sections, the CLVs used by
each PDU are listed. The format of each CLV is described only once, the first
time it is listed. Table 10.3 summarizes
which CLVs are used with which PDUs.
Table 10.3. The CLVs used by each IS-IS PDU.
IS Neighbors (LSPs)
Partition Designated Level 2 IS
IS Neighbors (Hellos)
IP Internal Reachability Information
IP External Reachability Information
Inter-Domain Routing Protocol Information
IP Interface Address
The purpose of the IS-IS Hello
PDU is to allow IS-IS
routers to discover IS-IS neighbors on a link. Once the neighbors have been
discovered and have become adjacent, the job of the Hello PDU is to act as
a keepalive to maintain the adjacency and to inform the neighbors of any changes
in the adjacency parameters.
The upper limit on the size of an IS-IS PDU is defined by either the
buffer size of the
originating router or the MTU of the data link on which the PDU is transmitted.
ISO 10589 specifies that IS-IS Hellos must be padded to within one octet less
than this maximum, partly to allow a router to implicitly communicate its
MTU to its neighbors. More important, sending Hellos at or near the link MTU
is intended to help detect link failure modes in which small PDUs pass but
larger PDUs are dropped. The benefit of this design decision, weighed against
the expense of sending such large Hellos over low-speed serial links, is debatable.
There are two kinds of IS-IS Hellos: LAN Hellos and point-to-point
Hellos. The LAN Hellos can be further divided into L1 and L2 LAN Hellos. The
format of the two types of LAN Hellos is identical, as shown in Figure
10.18. Figure 10.19 shows an analyzer
capture of a level 2 LAN Hello.
Typeis a two-bit field (the preceding six bits are reserved and
are always zero) specifying whether the router is an L1 (01), L2 (10), or
L1/L2 (11). If both bits are zero (00), the entire PDU is ignored.
Source ID is the System ID of the router that originated
Holding Time is the period a neighbor should wait
to hear the next Hello before declaring the originating router dead.
PDU Length is the length of the entire PDU in octets.
Priority is a seven-bit field used for
the election of a DR. The field carries a value between 0 and 127 with the
higher number having the higher priority. L1 DRs are elected by the priority
in L1 LAN Hellos, and L2 DRs are elected by the priority in L2 LAN Hellos.
Figure 10.19. This analyzer capture of a LAN Hello shows the fields unique to a Hello PDU.
LAN ID is the System ID of the DR plus one
more octet (the Pseudonode ID) to differentiate this LAN ID from another LAN
ID that might have the same DR.
The following CLVs can be used by an IS-IS LAN Hello:18
Area Addresses (type 1)
Intermediate System Neighbors (type 6)
Padding (type 8)
Authentication Information (type 10)
Protocols Supported (type 129)
IP Interface Address (type 132)
Figure 10.20 shows the format of
the IS-IS point-to-point Hello PDU. It is almost identical to the LAN Hello
except that there is no Priority field and there is a Local Circuit ID field
instead of a LAN ID field. Unlike LAN Hellos, L1 and L2 information is carried
in the same point-to-point Hello PDU.
Local Circuit ID is a one-octet
ID assigned to this circuit by the router originating the Hello and is unique
among the router's interfaces. The Local Circuit ID in the Hellos at the other
end of the point-to-point link may or may not contain the same value.
The IS-IS point-to-point Hello
does not use the IS Neighbors CLV. With that exception, the same CLVs are used as the
The Area Addresses CLV (Figure
10.21) is used to advertise the area addresses configured on the originating
router. As the multiple Address Length/Area Address fields imply, a router
can be configured with multiple area addresses. There will never be more than
three Address Length/Area Address fields in PDUs originated by Cisco routers
because that is the maximum number of area addresses
Figure 10.22 shows part of an IS-IS
Hello PDU; Variable Length Field #3 is an Area Addresses CLV with a total
length of six octets. There are two area addresses:
47.0002 (three octets), and 0 (one octet).
The IS Neighbors CLV (Figure 10.23)
lists the System IDs of all neighbors from
whom a Hello has been heard within the last Hold Time. Note that this
CLV gives the IS-IS LAN Hello a function similar to the OSPF function of listing
all recently-heard-from neighbors in order to verify two-way communication.
This CLV is used only in LAN Hellos; it is not carried in point-to-point
Hellos, where no DR election is performed. It is also different from the IS
Neighbors CLV used by LSPs, and the two are distinguished by their type numbers.
L1 LAN Hellos list L1 neighbors only, and L2 LAN Hellos list L2 neighbors.
Although fields carrying System IDs are frequently of variable length, the
fields of this CLV are always six octets. The length can be fixed because
the System IDs always belong to
routers on LANs, and are therefore always MAC identifiers.
Variable Length Field #5 in Figure 10.24
shows an IS Neighbors CLV in which a
single neighbor, 0000.0c0a.2aa9, is listed.
Figure 10.22. An Area Addresses CLV is shown as Variable Length Field #3. The analyzer
also indicates the total addresses listed in the CLV (2) for convenience,
but this information is not one of the CLV fields.
Figure 10.24. An IS Neighbors CLV is shown as Variable Length Field #5.
The Padding CLV is used to pad a Hello
PDU out to at least its minimum-allowed size. Since the maximum size of a
Value field is 255 octets, multiple Padding CLVs are often used. The bits
in the Value field can be arbitrary because they are ignored; Cisco sets all
these bits to zero (Figure 10.25).
The Authentication Information CLV (Figure
10.26) is used when authentication is configured. The Authentication
Type field contains a number between 0 and 255 that specifies the type of
authentication used and hence the type of information contained in the Authentication
Value field. The only authentication type
currently defined by ISO 10589 or supported by Cisco is a cleartext password, which is Authentication Type 1.
Figure 10.25. The last Variable Length Fields of the Hello PDU shown in Figure
10.19 are Padding CLVs, which bring the size of the PDU to the 1497-octet
length shown in Figure 10.19. With the addition
of the 3-octet LLC header and the 18-octet Ethernet header, the entire frame
size is the 1518-octet Ethernet MTU.
Variable Length Field #1 in Figure 10.22
is an Authentication Information CLV. The password is “jeff,”
which is displayed as the hex representation of its ASCII characters.
The Protocols Supported CLV (Figure
10.27) is specified in RFC 1195, and its purpose is to indicate whether
the originator of the PDU supports CLNP only, IP only, or both. For each protocol
supported, the corresponding one-octet Network
Layer Protocol Identifier (NLPID), specified in ISO/TR 9577, is listed in
the CLV. IP is 0x81. Variable Length Field #2 in Figure
10.22 is a Protocols Supported CLV.
The IP Interface Address CLV (Figure
10.28) contains the IP address or addresses of the interface out which
the PDU was sent. Because the Length field is one octet, an interface of an
IS-IS router can theoretically have up to 255 IP addresses. Variable Length
Field #4 in Figure 10.24 is an IP Interface
Address CLV, indicating that the captured Hello PDU was transmitted from an
interface with an address of 10.1.3.1.
The IS-IS LSP performs essentially the
same function as the OSPF LSA. An L1 router floods a L1 LSP throughout an
area to identify its adjacencies and the state of those adjacencies. An L2
router floods L2 LSPs throughout the level 2 domain, identifying adjacencies
to other L2 routers and address prefixes that the advertising L2 router can
Figure 10.29 shows the format of the
IS-IS LSP. The format is the same for both L1 LSPs and L2 LSPs.
PDU Length is the length of the entire PDU in octets.
Remaining Lifetime is the number of seconds before
the LSP is considered to be expired.
LSP ID is the System ID, the Pseudonode ID, and the LSP Number of the LSP.
The LSP ID is described in more detail in “The Update Process.”
Sequence Number is a 32-bit unsigned integer.
Checksum is the checksum of the contents of the
P is the Partition Repair bit. Although the bit
exists in both L1 and L2 LSPs, it is relevant only in L2 LSPs. When this bit
is set, it indicates that the originating router supports the automatic repair
of area partitions. Cisco IOS does not support this function, so the P bit
of LSPs originated by Cisco routers will always be zero.
ATT is a four-bit field indicating that the originating router is attached
to one or more other areas. Although the bits exist in both L1 and L2 LSPs,
they are relevant only in L1 LSPs that have been originated by L1/L2 routers.
The four bits indicate which metrics are supported by the attachment. Reading
from left to right, the bits indicate:
Cisco IOS supports only the default
metric, so bits 5 through 7 will always be zero.
OL is the Link State Database Overload bit. Under normal
circumstances, this bit will be zero. If the originating router is experiencing
a memory overload condition, it will set the OL bit to one. Routers receiving
an LSP with the OL bit set will not use the originating router as a transit
router, although they will still route to destinations on the originator's
directly connected links.
IS Type is a two-bit field indicating whether the
originating router is an L1 or an L2:
00 = Unused value
01 = L1
10 = Unused value
11 = L2
An L1/L2 router sets the bits according to whether the LSP is an L1
or an L2 LSP.
The following CLVs can be used by an L1 LSP:
Area Addresses (type 1)
IS Neighbors (type 2)
ES Neighbors (type 3);
Authentication Information (type 10)
IP Internal Reachability Information (type 128)
Protocols Supported (type 129)
IP Interface Address (type 132)
The following CLVs can be used by an L2 LSP:
Area Addresses (type 1)
IS Neighbors (type 2)
Partition Designated Level 2 IS (type 4)
Prefix Neighbors (type 5)
Authentication Information (type 10)
IP Internal Reachability Information (type 128)
IP External Reachability Information (type 130)
Inter-Domain Routing Protocol Information (type 131)
Protocols Supported (type 129)
IP Interface Address (type 132)
Figure 10.30 shows an L1 LSP that was
originated by an L1/L2 router.
The Intermediate System Neighbors
CLV used by LSPs (Figure 10.31) lists the
originating router's IS-IS neighbors (including pseudonodes) and the metrics
of the router's link to each of its neighbors.
Virtual Flag, although eight bits long, has a value
of either 0x01 or 0x00. A 0x01 in this field indicates that the link is a
level 2 virtual link to repair an area partition. The field is relevant only
to L2 routers that support area partition repair; Cisco does not, so the field
will always be 0x00 in Cisco-originated LSPs.
R is a reserved bit and is always zero.
I/E, associated with each of the metrics, indicates
whether the associated metric is internal or external. The bit has no meaning
in IS Neighbors CLVs because all neighbors are by definition internal to the
IS-IS domain. Therefore, this bit is always zero in IS Neighbors CLVs.
Default Metric is the six-bit default metric for
the originating router's link to the listed neighbor and contains a value
between 0 and 63.
S, associated with each of the optional metrics,
indicates whether the metric is supported (zero) or unsupported (one). Cisco
does not support any of the three optional metrics, so the bit is always set
to one and the associated six-bit metric fields are all zeroes.
Neighbor ID is the System ID of the neighbor, plus
one more octet. If the neighbor is a router, the last octet is 0x00. If the
neighbor is a pseudonode, the System ID is that of the DR and the last octet
is the Pseudonode ID.
Figure 10.32 shows part of an IS Neighbors
The IP Internal Reachability Information CLV (Figure 10.33) lists IP addresses and associated
masks within the routing domain that are directly connected to the advertising
router. The CLV is used by both L1 and L2 LSPs, but never appears in an LSP
describing a pseudonode. The metric fields are identical to the IS Neighbors
CLV, except that no I/E bit is associated with the optional metrics. Instead,
the bit is reserved and is always zero. Like the IS Neighbors CLV, the I/E
bit in this CLV is always zero because the addresses advertised in the CLV
are always internal.Figure 10.34 shows an
analyzer capture of an IP Internal Reachability Information CLV.
The IP External Reachability Information CLV lists IP
addresses and associated masks external to the routing domain, which can be
reached via one of the originating router's interfaces. Its format is identical
to the Internal Reachability Information CLV shown in Figure
10.33 except for the code, which is 130. However, unlike the Internal
Reachability Information CLV, this CLV can be used only by L2 LSPs. The I/E
bit determines the metric type for all four metricsI/E = 0 for internal
metrics, and I/E = 1 for external metrics.
The Inter-Domain Routing Protocol Information CLV
(Figure 10.35) allows L2 LSPs to transparently
carry information from external routing protocols through the IS-IS domain.
The CLV serves the same purpose as the Route Tag fields of RIPv2, EIGRP, and
OSPF packets. Route tagging is covered in Chapter
14, “Route Maps.”
Inter-Domain Information Type specifies the
type of information contained in the variable-length External Information
field. If the type field is 0x01, the External Information is of a format
used by the local interdomain routing protocol. Chapter
14 includes examples of using route maps to set such local information.
If the type field is 0x02, the External Information is a 16-bit autonomous
system number, which is used to tag all subsequent External IP Reachability
entries until either the end of the LSP or the next occurrence of the Inter-Domain
Routing Protocol Information CLV.
Figure 10.34. An analyzer capture of an IP Internal Reachability Information CLV.
SNPs are used to maintain the IS-IS link
state database by describing some or all of the LSPs in the database. A DR
periodically multicasts a CSNP (Figure 10.36)
to describe all the LSPs in the pseudonode's database. Because there is an
L1 database and an L2 database, CSNPs are also either L1 or L2. Some link
state databases can be so large that the LSPs cannot all be described in a
single CSNP. For this reason, the last two fields of the CSNP header are the Start
LSP ID field and the End LSP ID field, which
together describe the range of LSPs described in the CSNP. Figure
10.37 shows how these two fields are used. In this CSNP, the full database
is described; therefore, the LSP ID range starts with 0000.0000.0000.00.00
and ends with ffff.ffff.ffff.ff.ff. If two CSNPs were required to describe
the database, the range of the first CSNP might be something like 0000.0000.0000.00
to 0000.0c0a.1234.00.00 and the range of the second CSNP might be 0000.0c0a.1235.00.00
A PSNP (Figure 10.38) is similar to
a CSNP, except that the former describes only some LSPs rather than the entire
database. Therefore, no Start and End fields are necessary as they are with
CSNPs. A router sends a PSNP on a point-to-point subnetwork to acknowledge
received LSPs. On a broadcast subnetwork, PSNPs request missing or more recent
LSPs. Like CSNPs, there are both L1 and L2 PSNPs.
Figure 10.37. This analyzer capture shows the header of an L1 CSNP.
Only two CLVs are used by SNPs, whether they are CSNP or PSNP
and whether they are L1 or L2:
The LSP Entries CLV (Figure 10.39)
summarizes an LSP by listing its Remaining Lifetime, LSP ID, Sequence Number,
and Checksum. These fields not only identify the LSP but also completely identify
a particular instance of an LSP. Figure 10.40 shows part of an LSP Entries CLV.
7 The temptation to use the ISO/European
spelling of certain common terms such as “routeing” and “neighbour”
was successfully resisted.
8 Some documentation, such as RFC
1195, define the LSP as Link State Packet.
9 There are actually four ATT bits, relevant to different metrics.
These bits are further explained in the section “IS-IS
10 International Organization for
Standardization, “Network Service Definition Addendum 2: Network Layer
Addressing,” ISO/IEC 8348/Add.2, 1988.
11 Cisco's IS-IS implementation
requires a System ID of 6 octets.
12 GOSIP Advanced Requirements Group, “Government Open Systems
Interconnection Profile (GOSIP) Version 2.0 [Final Text],” Federal
Information Processing Standard, U.S. Department of Commerce, National Institute
of Standards and Technology, October 1990.
13 Richard Colella, Ella Gardner, and Ross Callon, “Guidelines
for OSI NSAP Allocation in the Internet,” RFC 1237, July 1991.
14 International Organization for Standardization, “Internal Organisation
of the Network Layer,” ISO 8648, 1990.
15 The exception is if a router
receives an instance of an LSP that is older than an instance of the same
LSP in its database. In that case, the router will reply with the newer LSP.
16International Organization for
Standardization, "Protocol Identification in the Network Layer," IDO/IEC TR
17The acronym CLV is not used in ISO 10589, but is used here
for convenience. You are already familiary with the concept of CLVs from the
coverage of EIGRP TLVs in Chapter 8, “Enhanced Interior
Gateway Routing Protocol (EIGRP).” In fact, RFC 1195 referes to
Integrated IS-IS CLVs as TLVs.
18As a reminder, RFC 1195 also specifies an Authentication Information
CLV with a type number of 133. Cisco uses the ISO-specified type number of
10 to identify its Authentication Information CLVs.
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
Broadband, Second Edition
by George Abe
Introduces the topics surrounding high-speed networks
to the home. It is written for anyone seeking a broad-based familiarity
with the issues of residential broadband (RBB) including product
developers, engineers, network designers, business people, professionals
in legal and regulatory positions, and industry analysts.