Overview
IS-IS is a dynamic routing protocol developed by the International Organization for Standardization (ISO) and commonly referred to as ISO 10589. IS-IS was originally developed at Digital Equipment Corporation for Phase V DECnet. The motivation to standardize IS-IS, however, was through the efforts of the American National Standards Institute (ANSI) X3S3.3 Network and Transport Layers Committee.
Similar to the Open Shortest Path First (OSPF) routing protocol, IS-IS is a link-state protocol. It builds a complete and consistent picture of a network’s topology by sharing link-state information across all network Intermediate System (IS) devices.
The IS-IS routing protocol provides routing for pure Open Systems Interconnection (OSI) environments. IS-IS as implemented on the E Series router supports IP networks and enables you to configure IS-IS as an IP routing protocol only. In IS-IS, networks are partitioned into routing domains, which are further divided into areas. A two-level hierarchical routing design is used. With this model, routing is referred to as level 1, level 2, or both level 1 and level 2.
IS-IS Terms
OSI internetworking has its own terminology. A number of terms used in IS-IS routing discussions are defined in Table 55.
Table 55: IS-IS Terms
Term | Meaning |
---|---|
area | A group of contiguous networks and their attached hosts. Area boundaries are normally assigned by a network administrator. |
complete sequence number PDU (CSNP) | PDU sent by designated router to ensure database synchronization |
Connectionless Network Protocol (CLNP) | An OSI network layer protocol used by CLNS to handle data at the transport layer; the OSI equivalent of IP |
Connectionless Network Service Protocol (CLNS) | An OSI network layer service that enables data transmission without establishing a circuit and that routes messages independently of any other messages. |
end system (ES) | Any nonrouting network node or host |
intermediate system (IS) | A router |
level 1 routing |
|
level 2 routing |
|
link-state PDU (LSP) | PDU broadcast by link-state protocols that contains information about neighbors and path costs; used to maintain routing tables; also known as link-state advertisement |
network entity title (NET) | ISO network addresses used by CLNS networks; an identifier of a network entity in an end system or intermediate system. A NET consists of an area address (routing domain), system identifier, and selector. |
network service access point (NSAP) | Hierarchical network address that specifies the point at which network services are made available to a transport layer entity in the OSI reference model. A valid NSAP address is unique and unambiguously identifies a single system. |
partial sequence number PDU (PSNP) | PDU sent by designated router to acknowledge and request link-state information |
protocol data unit (PDU) | OSI term equivalent to packet, containing protocol control information and, possibly, user data. This chapter uses the term packet interchangeably with PDU. |
route tag | A numeric value assigned to the IP addresses on an IS-IS route before the route is propagated to other routers in an IS-IS domain. You can use this tag to control IS-IS route redistribution, route leaking, or route summarization by referencing it in a route map. |
routing domain | A collection of connected areas that provide full connectivity to all end systems located within them. A routing domain is partitioned into areas. |
system identifier | Uniquely identifies a system within an area |
table map | A mechanism for applying a route map to an IS-IS route as a way to filter and manipulate route attributes before the route is added to the routing table. |
Figure 18 illustrates some of the terms described in Table 55.
Figure 18: Overview of IS-IS Topology

ISO Network Layer Addresses
ISO network layer addresses are flexible enough to make routing feasible in a worldwide Internet. Network layer addresses in ISO and IP are hierarchical and clearly identify level 1 and level 2 areas. These addresses can be up to 20 octets long; any packet that contains an address has one additional octet to specify the length of the address.
An ISO address—also known as the NSAP address—is broken into three parts: the area address, the system identifier (ID), and the NSAP selector.
area address
system ID
selector

The area address defines the routing domain and the area within the routing domain. The length of the ID field can be from 1 to 8 octets and uses a single fixed length for any one routing domain. The selector field is always 1 octet long. Usually, all end systems within the same area have the same area address. Some areas can have multiple addresses. The NSAP address is defined by the network entity title (NET) during configuration.
Level 1 Routing
A level 1 router looks at a packet’s area address and compares it with a destination address. If the area portion of the destination address matches its own area’s address, the level 1 router uses the ID portion of the address to route the packet. If the area portion of the address does not match, the level 1 router routes the packet to a level 2 router within its area.
Level 2 Routing
Level 2 routers do not look at an area’s internal structure, but simply route toward an area based on the area address. It is common for a level 2 router to also be a level 1 router in a particular area; these routers are sometimes referred to as level 1-2 routers. See Figure 18.
Dynamic Hostname Resolution
The system identifier of the NSAP address identifies a node in a network. System operators often find symbolic hostnames to be easier to use and remember than the system identifier. However, a static mapping of hostname to system identifier requires every router to maintain a table of the mappings; each table must contain the hostnames and system identifiers of every router in the network. The static mapping must be managed by router operators, and every change or addition of a mapping requires all the tables to be updated. Consequently, the static tables are likely to become rapidly outdated.
The router supports dynamic resolution of hostnames to system identifiers. You can use the clns host command to map the hostname to the NSAP address, and therefore to the system ID. This mapping is inserted in the dynamic hostname type-length-value tuple (TLV type 137), and subsequently advertised when LSPs are transmitted. The value field contains the hostname, preferably the fully qualified domain name (FQDN) of the host, or a subset of the FQDN. You can display the TLV by issuing the show isis database detail command.
Authentication
The router supports two authentication methods for IS-IS: simple authentication and hash function–based message authentication code (HMAC) MD5 authentication. These authentication methods prevent unauthorized routers from injecting false routing information into your network or forming adjacencies with your router.
By default, IS-IS authentication is disabled on the router until you enable it with the commands described in the following sections.
Simple Authentication
Simple authentication uses a text password (authentication key) that can be entered in encrypted or unencrypted form. The receiving router uses this authentication key to verify the packet.
You can configure the password for simple authentication by using the following commands:
- The area-authentication-key command assigns a password used by neighboring routers to authenticate IS-IS level 1 link-state PDUs (LSPs), complete sequence number PDUs (CSNPs), and partial sequence number PDUs (PSNPs). This command also enables simple authentication of level 1 LSPs.
- The domain-authentication-key command assigns a password used by neighboring routers to authenticate IS-IS level 2 LSPs, CSNPs, and PSNPs. This command also enables simple authentication of level 2 LSPs.
- The isis authentication-key command assigns a password associated with a specific interface for authentication of IS-IS level 1 or level 2 hello packets. This command also enables simple authentication of level 1 or level 2 hello packets.
These commands enable simple authentication of LSPs and (for the isis authentication-key command) hello packets only; they do not enable authentication of CSNP and PSNP packets. To enable authentication of CSNPs or PSNPs, you must issue either the area-authentication command or the domain-authentication command. For information, see Enabling and Disabling Authentication of CSNPs and PSNPs.
![]() | Note: The router supports simple authentication for compatibility with existing IS-IS implementations. However, we recommend that you do not use the simple authentication method because it is insecure (the text can be “sniffed” ). |
HMAC MD5 Authentication
When you enable IS-IS HMAC MD5 authentication (also referred to as MD5 authentication), the router creates secure digests of the packets, encrypted according to the HMAC MD5 message-digest algorithms. The digests are inserted into the packets from which they are created. Depending on the commands you issue, the digests can be inserted into hello packets, link-state PDUs, complete sequence number PDUs, and partial sequence number PDUs.
You can configure an HMAC MD5 authentication key by using the following commands:
- The area-message-digest-key command specifies an HMAC MD5 key that the router uses to create a message digest of each level 1 packet—LSPs, CSNPs, and PSNPs—transmitted by area routers. Using MD5 authentication for area routers protects against unauthorized routers injecting false routing information into the area portions of your network. This command also enables MD5 authentication of level 1 LSPs.
- The domain-message-digest-key command specifies an HMAC MD5 key that the router uses to create a message digest of each level 2 packet—LSPs, CSNPs, and PSNPs—transmitted by domain routers. Using MD5 authentication for domain routers protects against unauthorized routers injecting false routing information into the routing domain portions of your network. This command also enables MD5 authentication of level 2 LSPs.
- The isis message-digest-key command specifies an HMAC MD5 key that the router uses to create a message digest of level 1 or level 2 hello packets on the interface. Level 1 packets are the default. Using MD5 authentication on interfaces protects against intrusion by preventing unauthorized routers from forming adjacencies with your router. This command also enables MD5 authentication of level 1 or level 2 hello packets.
These commands enable MD5 authentication of LSPs and (for the isis message-digest-key command) hello packets only; they do not enable authentication of CSNP and PSNP packets. To enable authentication of CSNPs or PSNPs, you must issue either the area-authentication command or the domain-authentication command. For information, see Enabling and Disabling Authentication of CSNPs and PSNPs.
MD5 Authentication Example
In the example shown in Figure 19, authentication is configured on router LA and router SanDiego, but not on router SanJose. Router LA and router SanDiego accept packets from each other because they contain message digests generated by an accepted key. Router SanJose accepts packets from router LA and router SanDiego, and simply ignores the message digest included in their packets. Router LA and router SanDiego reject packets from router SanJose because those packets do not include a message digest.
Figure 19: Packet Flow Between Routers With and Without Authentication Set

Specifying MD5 Start and Stop Timing
With each of the MD5 commands, you can specify when the router will start and stop accepting packets that include a digest made with this key. You can also specify when the router will start and stop generating packets that include a digest made with this key. If you specify a time for any of these actions, you can further specify the day, month, and year. The default times are as follows:
- Start accepting keys (startAcceptTime)—Current time
- Stop accepting keys (stopAcceptTime)—Never
- Start generating keys (startGenTime)—Current time plus 2 minutes
- Stop generating keys (stopGenTime)—Never
If you specify times, you must follow these guidelines to achieve appropriate timing between the actions:
- startAcceptTime must be less than startGenTime.
- stopGenTime must be less than stopAcceptTime.
- When a new key replaces an old one, the startGenTime time for the new key must be less than or equal to the stopGenTime time of the old key.
For example, suppose you configure authentication on router A and router B. If the startGenTime for router A is earlier than the startAcceptTime for router B, router B does not accept packets from router A until the current time matches its startAcceptTime.
The router accepts any packet authenticated with a key you have defined if the packet is received within the period defined for the key by its startAcceptTime and stopAcceptTime. If more than one key has been defined for that period, the router determines which key to use by comparing the startGenTime with the current time. When the startGenTime of a key matches the current time, the router starts using this key to transmit packets and stops using the previous key.
Example
The following commands configure both key 1 and key 2 to be accepted between 08:00:00 and 23:00:00. When the current time reaches 09:00:00, the router begins using key 1 to transmit packets. When the current time reaches 10:00:00, the router begins using key 2 to transmit packets; key 1 is no longer used. Key 2 will continue to be used until a new key is configured and the new key's startGenTime matches the current time on the router.
Halting MD5 Authentication
To prevent key expiration from causing your network to revert to an unauthenticated condition, you cannot halt MD5 authentication by using the timers. When the stopGenTime time for a key is reached, the router does not stop generating the key if it was the last key issued. You must delete all keys to halt authentication. Use the no version of the command to delete a key.
Managing and Replacing MD5 Keys
A key has an infinite lifetime if you do not specify stopGenTime and stopAcceptTime. (As noted previously, if the last key expires, the router continues to generate that key.) Many system operators choose to change their keys on a regular basis, such as every month. If you determine that a key is no longer secure, configure a new key immediately. We recommend the following practice for configuring new keys:
- Configure the new key on all routers in the IS-IS network.
- Verify that the new key is working.
- Delete the old key from every router.
Each key has an associated key-ID that you specify. The key-ID is sent with the message digest, so that the receiving routers know which key was used to generate the digest. You also use the key-ID to delete a key.
Enabling and Disabling Authentication of CSNPs and PSNPs
When the E Series router interoperates with other vendors’ routers in the same network, you might want to enable or disable (suppress) authentication for some PDU types but not for others. For example, some vendors’ routing software might not authenticate any PDUs, whereas other vendors’ routing software might authenticate CSNPs and PSNPs separately from LSPs.
To facilitate interoperability with other vendors’ routers, the E Series router allows you to enable and disable authentication of CSNPs and PSNPs separately from authentication of LSPs by using the following commands:
- The area-authentication { csnp | psnp } command enables or disables simple authentication or HMAC MD5 authentication of IS-IS level 1 CSNP packets or PSNP packets. By default, authentication of CSNPs and PSNPs is disabled.
- The domain-authentication { csnp | psnp } command enables or disables simple authentication or HMAC MD5 authentication of IS-IS level 2 CSNP packets or PSNP packets. By default, authentication of CSNPs and PSNPs is disabled.
When you suppress authentication of CSNPs, the router does not authenticate CSNP packets that it receives from neighboring routers, nor does it include authentication information in CSNP packets that it sends to other routers. Similarly, when you suppress authentication of PSNPs, the router neither authenticates PSNP packets that it receives nor sends authentication information in PSNP packets that it transmits.
Extensions for Traffic Engineering
The router supports new-style TLV tuples described in the Internet draft, IS-IS Extensions for Traffic Engineering. The router ID TLV (TLV type 134) contains the ID of the router that originates the LSP, providing a stable address that can always be referenced regardless of the state of node interfaces.
The extended IP reachability TLV (type 135) carries IP prefixes and is similar to the IP reachability TLVs (types 128 and 130). The extended IS reachability TLV (type 22) contains information about a series of IS neighbors and is similar to the IS neighbor TLV (type 2).
The older TLVs—2, 128, 130—each have a narrow metric field, providing for metric values ranging only from 0–63. The new TLVs—22 and 135—have a new data structure that includes a wide metric field of 3 bytes (extended IS reachability; configurable) or four bytes (extended IP reachability; calculated). Both new TLVs provide for the use of sub-TLVs to carry more information about IS neighbors; however, only the extended IS reachability TLV currently has defined sub-TLVs, such as IPv4 interface and neighbor addresses.
Use the metric-style commands to configure what style the router generates and accepts. The following behaviors are supported:
- Generates and accepts only old-style metrics
- Generates only old-style metrics, but accepts old style and new style
- Generates and accepts both old-style and new-style metrics (this option consumes the most system resources)
- Generates only new-style metrics, but accepts old style and new style
- Generates and accepts only new-style metrics
Refer to the Internet draft, IS-IS Extensions for Traffic Engineering, for more information about these extensions.
Integrated IS-IS
The E Series router supports the Integrated IS-IS version of IS-IS. Integrated IS-IS provides a single routing algorithm to route both TCP/IP and OSI Connectionless Network Protocol (CLNP) packets. This design adds IP-specific information to the OSI IS-IS routing protocol. It supports IP subnetting, variable subnet masks, type of service (ToS), and external routing.
Integrated IS-IS allows for the mixing of routing domains; that is, IP-only routers, OSI-only routers, and dual (IP and OSI) routers. OSI and IP packets are forwarded directly over the link-layer services without needing mutual encapsulation. The E Series router supports IS-IS only for the routing and forwarding of TCP/IP packets. Forwarding of OSI packets is not supported.
Equal-Cost Multipath
IS-IS supports equal-cost multipath (ECMP) and installs into the routing table multiple entries for paths to the same destination. Each of these multiple paths to a given destination must have the same cost as the others, but a different next hop.
Static PPP Interfaces
When IS-IS has been configured on a static PPP interface, the IS-IS neighbor does not come up if you remove the IP address from the interface and then add the IP address back to the interface. Consequently, when you remove and add back the IP address, you must also remove the IS-IS configuration from the interface and then add the configuration back to the interface by issuing the no router isis and router isis commands.
Route Tags
E Series routers support the use of route tags, also known as administrative tags, as a means of tagging the IP addresses on an IS-IS route before the route is propagated to other routers in an IS-IS domain. You must reference the tag in a route map to apply administrative policies to the IS-IS route that matches this tag.
Route Tag Applications
An administrative policy controls how a router handles the routes it receives from and sends to neighboring routers, and governs the installation of routes in the routing table. Examples of the types of administrative policies that you might apply with a route tag include:
- Policies for redistributing routes received from other protocols in the routing table to IS-IS
- Policies for redistributing routes between levels in an IS-IS routing hierarchy; this is also referred to as route leaking
- Policies for summarizing routes redistributed into IS-IS or within IS-IS by creating aggregate (summary) addresses
Route Tag Structure
On E Series routers, an IS-IS route tag is a 32-bit (4-octet) nonzero number that is stored as sub-TLV 1 inside the extended IP reachability TLV (type 135). TLV type 135, in turn, is part of an IS-IS LSP. The route tag is therefore advertised when LSPs are transmitted in an IS-IS network.
Because TLV type 135 is a new-style TLV tuple, it has a data structure that includes a wide metric field of four octets. As a result, to use IS-IS route tags you must issue the metric-style wide command (in Router Configuration mode) to specify that the router generate and accept only new-style TLV tuples.
For a discussion of IS-IS support for TLV tuples, see Extensions for Traffic Engineering.
Setting Route Tags
You can set IS-IS route tags in any of the following ways:
- Tagging a route for IP addresses on an IS-IS passive interface
- Tagging a route for IP addresses on an IS-IS interface
- Tagging IS-IS routes by using an associated route map to set the tag
- Tagging an IS-IS summary address
For instructions and examples on configuring IS-IS route tags, see the sections listed in Table 56.
Table 56: Configuration Tasks for Setting IS-IS Route Tags
To Learn About | Using This Command | See |
---|---|---|
Setting a route tag for an IS-IS passive interface | ||
Setting a route tag for an IS-IS interface | ||
Setting a route tag for a route redistributed from another protocol to IS-IS by using an associated route map | ||
Setting a route tag for a route redistributed from one IS-IS level to another IS-IS level by using an associated route map | ||
Setting a route tag for an IS-IS default route by using an associated route map | ||
Setting a route tag for an IS-IS summary address |
Using Route Tags
You can set only a single route tag per IS-IS route. However, setting a tag for an IS-IS route has no effect by itself. To use the route tag to apply administrative policies such as route redistribution, route summarization, or route leaking, you must reference the tag value in a route map by issuing the match tag command (in Route Map Configuration mode). The route map must also include one or more set commands that modify attributes of the routes matching the tag value. These routes can reside on a different router than the one on which you set the route tag.
For example, the following commands define a route map to modify the metric and metric type attributes of IS-IS routes configured with a route tag value of 221. The redistribute isis ip command, as described in Redistributing Routes Between Levels, applies this route map when redistributing the routes from level 1 into level 2.
Alternatively, you can use a route map to set the tag for an IS-IS route by issuing the set tag command (in Route Map Configuration mode). For example, the following commands define a route map that sets route tag 33 for those IS-IS routes configured with an administrative distance of 25:
The table-map command, described in Configuring Table Maps, applies this route map to the IS-IS routes before they are added to the routing table. For details about configuring and using route maps, see JunosE IP Services Configuration Guide.
Unsupported Features
E Series routers do not currently support the following route tag features:
- Multiple route tags for a single IS-IS route
Although the router accepts IS-IS routes with multiple route tags and propagates these routes in LSPs, it uses only the first route tag assigned to a route to determine routing policy.
- 64-bit (8-octet) route tags
Although the router accepts IS-IS routes with 64-bit route tags and propagates these routes in LSPs, it does not use 64-bit route tags to determine routing policy.
- Mathematical (ordered) set operations on multiple route tags
Table Maps
E Series routers support the use of table maps to filter and manipulate the attributes of an IS-IS route before the route is installed in the routing table. Issuing the table-map command (in Router Configuration mode) applies a specified route map as a policy filter on the route before the route is installed in the routing table.
For IS-IS routes, the route map you apply by using the table-map command contains one or more set commands that can modify the following route attributes:
distance | origin |
level | preference |
metric | route type |
metric type | tag |
The router applies the specified route map to all routes currently and subsequently installed in the routing table. If any previously redistributed routes are changed as a result of applying the route map, the router redistributes these routes again with the changes caused by the route map.
For details about configuring and using route maps, see JunosE IP Services Configuration Guide.
Graceful Restart
E Series routers support IS-IS graceful restart as defined in RFC 3847—Restart Signaling for Intermediate System to Intermediate System (IS-IS) (July 2004). Graceful restart is also known as nonstop forwarding (NSF). When graceful restart is enabled on an IS-IS router, it allows the router to restart with minimal routing disruption to the network.
Features
When a router running in an IS-IS domain restarts, it typically causes routers in that domain to reset their adjacencies, thus generating unnecessary LSP flooding and shortest-path-first (SPF) calculations throughout the domain. Enabling graceful restart minimizes these effects by providing a mechanism by which a restarting router can do the following:
- Notify neighboring IS-IS routers that it is restarting and request help resynchronizing its LSP database. Neighbors with active adjacencies to the restarting router can thereby reestablish these adjacencies without having to reset them.
- Determine when complete LSP database synchronization with its neighbors has occurred.
- Optimize the process of LSP database synchronization while minimizing temporary routing disruption.
IS-IS graceful restart on E Series routers supports both restart and helper capabilities. These capabilities mean that an E Series router can not only notify neighboring IS-IS routers that it is restarting and request help resynchronizing its LSP database, but can also cooperate with other restarting routers to help them with the restart process.
How Graceful Restart Works
Graceful restart is disabled on the router by default. When you enable graceful restart by issuing the nsf ietf command, the router sends restart requests to neighboring routers to notify them that it is restarting. The restarting router includes the restart TLV (type 211) in its hello PDUs to signal the other routers that it supports graceful restart and to request help resynchronizing its LSP database. Including the restart TLV in hello packets also ensures that neighboring routers will maintain their active adjacencies to the restarting router and keep the restarting router in the network topology.
Graceful restart uses a set of configurable timers to support the restart mechanism. Table 57 briefly describes these timers and lists the associated commands that you can use to configure the timer values on the router.
Table 57: IS-IS Graceful Restart Timers
Timer | Description | Associated Command |
---|---|---|
Interface wait | Sets the maximum time (in seconds) that the router waits for all interfaces with IS-IS adjacencies to come up before completing the restart process | |
T1 | Sets the time interval (in seconds) between restart requests sent by the router, and the number of times that the router resends unacknowledged restart requests | |
T2 | Sets the maximum time (in seconds) that the router waits for the LSP database to synchronize | |
T3 | Sets the maximum time (in seconds) that the restarting router waits before setting the overload bit to indicate that graceful restart has failed |
For details about configuring graceful restart, see Configuring Graceful Restart.
IS-IS for IPv6
E Series routers support IPv6 routing for IS-IS. The IPv6 Reachability TLV propagates reachability information by flooding and is used in SPF calculations. The IPv6 Interface TLV is used for next hop calculation and is exchanged by means of IS-IS hello packets. A single SPF calculation computes both IPv6 and IPv4 routing tables.
IS-IS routers learn about their neighbors’ support for IPv6 through the ISO network layer IPv6 protocol identifier, NLPID 142. The NLPID is contained in the NLPID TLV and is sent out in IS-IS hello packets when IS-IS IPv6 routing is enabled on an interface. A mismatch in support prevents an IS-IS adjacency from being established, because both neighbors must run the same protocols.
IPv6 aggregation, leaking, redistribution, export policies and import policies are supported similarly as for IP, but must be configured within the IS-IS IPv6 address family.
Graceful restart is supported for IS-IS IPv6 traffic depending on the availability of IPv6 high availability. It does not affect IP traffic.