Date created: 06/29/22 08:51:49. Last modified: 06/29/22 14:57:58

Cisco and Juniper IS-IS Interop

IS-IS Network Design Solutions By Abe Martey and Scott Sturgess

ATT/Attached Bit

L1/L2 routers set the ATT-Bit (attached bit) on Level-1 Link State Packets (LSPs) sent into a Level 1 area. This is done automatically by the L1/2 ABRs. The purpose of an ATT-Bit is to accomplish Inter-Area routing. L1 routers receiving an LSP with the ATT-Bit set from a L1/2 router use this flag as a marker that the neighbour router is an ABR for the area. Even though a default route may not be explicitly sent by the L1/L2 router, the L1 router receiving an LSP with the ATT-bit set implicitly installs a default route via the L1/L2 router sending LSPs with the ATT bit set. The ATT-Bit can be set on any and all LSPs the L1/L2 router sends into a L1 area. If multiple L1/L2 routers exist in a Level 1 area, then routers in the L1 area choose the nearest L1/L2 router as their default gateway. This requires that a L1/L2 router has at least one active L2 adjacency (to the same or another area), it doesn’t need to have a valid default route in it’s FIB to set the ATT bit automatically.

The ATT-bit can be cleared on LSPs sent by a L1/L2 router into a L1 area so that the area does not contain a default route via the ABRs (or a specific subset of ABRs). One reason for this may be to null route traffic for which there is no LPM locally on a Level 1 router or to have another protocol originate the default route within a Level 1 area. This applies to Junos/IOS/XR.


set protocol isis ignore-attached-bit

IOS-XR L1/2 router:

router isis 1
 address-family ipv4 unicast
  attached-bit send never-set

IOS-XR L1 router:

router isis 1
 address-family ipv4 unicast
  attached-bit receive ignore

IOS-XR note: If connectivity for the Level 2 instance is lost, the attached bit in the Level 1 instance LSP continues sending traffic to the Level 2 instance and causes the traffic to be dropped.

IOS-XR address-family: set-attached-bit

This is not normally needed, it is typically used for noncontiguous backbone connectivity.

IOS (this is a hidden command on IOS for L1 routers):

router isis

IOS (alternative to the hidden command, use a route map on the L1/L2 router):

clns filter-set Clear-ATT-Bit permit 49.0001 ! Area we don’t want to receive ATT bit
route-map Clear-ATT-Bit deny 10
 match clns address Clear-ATT-Bit
router isis
 set-attached-bit route-map Clear-ATT-Bit


CSNP Generation

On a PtP link periodic CSNP are not required by the ISIS standard (they are only required on broadcast links by the DIS). Some NOS’s implement periodic CNSPs on PtP links anyway.

IOS and IOS-XR do not support periodic CNSP transmission on PtP links.

JUNOS implements an hard-coded mechanism that generates periodic CSNP over p2p interfaces to allow better network stability. The Junos CSNP transmission algorithm on a PtP link is based on the number of adjacencies UP at a given time. If N is the number of UP Adj the Juniper router sends periodic CSNP on each interface every Nx5 seconds.

Arista implements periodic CNSP transmission on PtP links (default 10 seconds) which is configurable but can not be disabled: “timers csnp generation interval”.

Increasing the periodic CSNP interval can help protect against CSNP flooding.


Hello Interval and Multiplier

IOS-XR interface level: hello-interval seconds [ level { 1 | 2 } ]

IOS-XR note: default 10 seconds, range is 1 to 65535 seconds.

For point-to-point links, IS-IS sends only a single hello for Level 1 and Level 2, making the level keyword meaningless on point-to-point links. To modify hello parameters for a point-to-point interface, omit the level keyword.

IOS interface level: isis hello-interval { seconds | minimal } [ level-1 | level-2 ]

“Seconds: Length of time between hello packets, in seconds. By default, a value three times the hello interval seconds is advertised as the hold time in the hello packets sent. (Change the multiplier of 3 by specifying the isis hello-multiplier command.)

Minimal: Causes the system to compute the hello interval based on the hello multiplier (specified by the isis hello-multiplier command) so that the resulting hold time is 1 second.

By default the hello interval is 10 seconds for non-DIS interfaces, and 3.333 seconds for DIS interfaces. The hello interval is configured for both Level 1 and Level 2.”

Junos IS-IS interface level: hello-interval seconds

Range: 1 through 20,000 seconds
Default: 3 seconds (for designated intermediate system [DIS] routers), 9 seconds (for non-DIS routers)

“You can send out hello packets in sub second intervals. To send out hello packets every 333 milliseconds, set the hold-time value to 1.”


Hello Multiplier:

IOS-XR interface level: hello-multiplier multiplier [ level { 1 | 2 } ]

Default 3, range is 1 to 1000.

IOS interface level: isis hello-multiplier multiplier [ level-1 | level-2 ]

“Multiplier: Integer value from 3 to 1000. The advertised hold time in IS-IS hello packets will be set to the hello multiplier times the hello interval.

Default is 3 for L1 and L2.

On point-to-point links, there is only one hello for both Level 1 and Level 2, so different hello multipliers should be configured only for multiaccess networks.”

Junos protocol IS-IS level: hold-time seconds

Range: 3 through 65,535 seconds, or 1 to send out hello packets every 333 milliseconds.
Default: 9 seconds (for designated intermediate system [DIS] routers), 27 seconds (for non-DIS routers; three times the default hello interval)

“Set the length of time a neighbor considers this router to be operative (up) after receiving a hello packet. If the neighbor does not receive another hello packet within the specified time, it marks this routing device as inoperative (down). The hold time itself is advertised in the hello packets.”

Junos: A hold down timer is enabled by default to delay the advertising of LSPs over a new adjacency. To disable it use “set protocols isis no-adjacency-holddown”, this can increase SPF activity though if a session is flapping.


L1/L2 Mode

By default a router operates in L1/L2 mode. This also means that the default interface type is mixed L1/L2. One level must be explicitly disabled to make a router or interface L1 or L2 only. This applies to Junos/IOS/XR devices.


LDP Sync

On IOS-XR a link with a maximum wide metric (0xFFFFFF) is not considered for shortest path first (SPF). Therefore, the maximum wide metric of -1 (0xFFFFFE) is used with MPLS LDP IGP synchronisation when the link is not in sync.



The default interface L1 and L2 metric is 10 and default interface priority is 64. Passive interfaces default to metric of 0. This applies to Junos/IOS/XR.

On IOS “isis ipv6 metric” allows a separate metric to be configured on a link that runs IPv6 and IPv4.


Junos uses wide metrics and narrow metrics by default. Best to choose just one.

“wide-metric-only knob changes all the prefixes conveyed by IS-IS as Internal routes: this includes redistributed routes (New style TLVs don’t keep the E/I flag anymore).”

Using “wide-metric-only” knob and “traffic-engineering disable” knob together suppresses all IP TLVs and effectively disables IS-IS reachability!

IOS router level: metric-style wide [transition] [ level-1 | level-2 | level-1-2 ]

Default is narrow metrics on IOS.


MTU and Hello Padding

Junos IS-IS interface level: hello-padding (adaptive | loose | strict);
adaptive—Configure padding until the neighbor adjacency is established and active.
disable—Disable padding on all types of interfaces for all adjacency states.
loose—Configure padding until the state of the adjacency is initialized.
strict—Configure padding for all adjacency states.

IOS-XR interface level: hello-padding { disable | sometimes } [ level { 1 | 2 } ]
disable: Suppresses hello padding.
sometimes: Enables hello padding during adjacency formation only.
level { 1 | 2 }: (Optional) Specifies hello padding for Level 1 or Level 2 independently.

Enabled by default on IOS-XR.

IOS router level: hello padding

IOS interface level: isis hello padding

“Cisco routers still send the first five IS-IS hellos padded to the full MTU size, in order to maintain the benefits of discovering MTU mismatches.”

Some vendors (Cisco and Arista) support the unofficial EthernetII Ethertype value 0x8870 to carry padded IIH when the MTU is larger than 1500 bytes (1500 being the max supported by 802.3).

On core networks where the MTU is usually larger than 1500 the ISIS frame is still limited to 1492 bytes due to it's use of 802.3 Ethernet (except with the Jumbo Frame option (TLV 14), but this is not supported by Junos).

To combat large updates on networks with small MTUs, an LSP originating system can fragment the LSP it originates, but transit systems can't fragment LSPs they receive.


Multi-Topology/Single Topology and IPv6

The IPv6 capability is enabled and announced in IIH (TLV 139) by default on Junos. On IOS/XR IS-IS doesn’t advertise this capability by default but enabling IS-IS for IPv6 on an interface will advertise this capability, e.g. “interface Fa1/0; ipv6 router isis 1” on IOS and “router isis 1; interface Gi0/0/0/1; address-family ipv6 unicast” on IOS-XR. However, IOS-XR defaults to multi-topology IS-IS and IOS and Junos both default to single topology. To switch IOS-XR to single topology commit “router isis 1; address-family ipv6 unicast; single-topology”. Alternatively, on IOS add “router isis 1; address-family ipv6 unicast; multi-topology” or on Junos “set protocols isis topologies ipv6-unicast” to enable MT IS-IS.

On Junos the “set protocol isis ipv6-unicast” command will cause IS-IS to calculate an alternate IPv6 unicast topology, in addition to the normal IPv4 unicast topology, and add the corresponding routes to inet6.0.

When running IPv4 and IPv6 in single-topology IS-IS all links must run both protocols otherwise adjacency negotiations will fail. In multi-topology IS-IS only a subset of all links need to run either protocol.


Overload Bit

The commands below force the router to set the overload bit (also known as the hippity bit) in its non pseudonode link-state packets (LSPs). Normally, the setting of the overload bit is allowed only when a router runs into problems. For example, when a router is experiencing a memory shortage, it might be that the link-state database is not complete, resulting in an incomplete or inaccurate routing table. By setting the overload bit in its LSPs, other routers can ignore the unreliable router in their SPF calculations until the router has recovered from its problems. The result will be that no paths through this router are seen by other routers in the IS-IS area. However, IP and Connectionless Network Service (CLNS) prefixes directly connected to this router will still be reachable.

IOS-XR router level: set-overload-bit [ on-startup { delay | wait-for-bgp } ] [ level { 1 | 2 } ] [ advertise { external | interlevel } ]

IOS router level: set-overload-bit [ on-startup { seconds | wait-for-bgp } ] [ suppress [ [interlevel] [external] ] ]

Junos isis level: set overload {
  timeout seconds;


Passive Interfaces / PtP Prefix Suppression

By default on Junos, IS-IS only runs on interfaces configured for IS-IS and only advertises prefixes for the interfaces over which IS-IS is enabled. IS-IS is normally only enabled on the point-to-point links between routers and the loopback0 interface. The same is also true for IOS assuming no features like “passive-interface default” have been used. The following IOS command will show that the only networks in the LSDB are those for the interfaces on which IS-IS is enabled: “show isis database detail [l1 | l2]”

To advertise a loopback interface IP into IS-IS the process would have to be enabled for that interface.

For example on IOS:

interface loopback0
 ip router isis

Example on Junos:

set protocols isis interface lo0.0

Check IS-IS enabled interfaces:

IOS: show clns interface

Junos: show isis interface brief

There is a problem with this approach. IOS will by default send IS-IS hellos on the loopback interface trying to establish a neighbour adjacency but there isn’t a neighbour available via the loopback interface. Junos will set any loopback interface enabled for IS-IS as passive by default meaning that IP the address is advertised but no hellos are sent. Even though it’s not needed the Junos command “set protocols isis interface lo0.0 passive” can help during troubleshooting by showing explicitly that the loopback interface is passive.

The output below shows that the command “set protocols isis interface lo0.0 passive” enables IS-IS on a loopback interface on Junos, and places it into passive mode, also note that neither level 1 or level 2 have been disabled so the interface defaults into L1/L2 mode (in this case the router is an ABR so this places the loopback0 IP into both areas without any additional configuration):

lab@ACC31# run show isis interface lo0.0 detail
IS-IS interface database:
  Index: 325, State: 0x6, Circuit id: 0x1, Circuit type: 0
  LSP interval: 100 ms, CSNP interval: disabled
  Adjacency advertisement: Advertise
  Level Adjacencies Priority Metric Hello (s) Hold (s) Designated Router
    1             0       64      0 Passive
    2             0       64      0 Passive

For IOS the solution is also to use “passive” interfaces however IOS doesn’t differentiate between a loopback and non-loopback interface so additional tweaking is required. The following information applies only to IOS as Junos does not support a feature similar to “passive-interface default” on IOS.

There is a problem with “passive-interface default” in IOS though. When configured under “router isis” this disables ISIS processing on all interfaces and all connected interface IPs are automatically placed into the LSDB. The IOS “show isis database detail [l1 | l2]” command will show that all connected networks are now in the LSDB with a metric of 0. IS-IS must now be enabled on each required point-to-point link using “no passive-interface X/X” under “router isis” in addition to any interface specific configuration, for example:

router isis
 no passive-interface fa0/1
int fa0/1
ip router isis
 isis circuit-type level-1
 isis network point-to-point

At this point IS-IS is only running over interfaces that are explicitly configured as non-passive; however, all connected prefixes are being advertised into the IGP, even on links which are not enabled for IS-IS.

“passive-interface default” is generally considered good practice because it saves CPU cycles by explicitly configuring IS-IS to form adjacencies over interfaces which connect to other IS-IS enabled routers. Assuming “passive-interface default” is enabled, two different methods are described below which one can use to limit which interfaces IP ranges are entered into the LSDB and flooded in the IGP.

One option is to configure “no passive-interface X” under “router isis” for each connected interface we do not wish to advertise into IS-IS. Without the “ip router isis” statement under the interface configuration the interface won’t try to form an IS-IS adjacency but because it’s configured as non-passive under “router isis” the interface IP range isn’t automatically included into the LSDB. This method allows an interface to be enabled for IS-IS but the never enabled IS-IS on the interface, this disjoin is why the prefix is never added to the LSDB. This implementation seems a bit hacky though because many interfaces are configured as non-passive but then have no IS-IS configuration present under them, during a troubleshooting phase it can seem like a mistake. This also doesn’t scale well having to set every unwanted interface as non-passive.

Another option is to have “passive-interface default” configured and only add “no passive-interface X/Y” for the actual IGP links which should run IS-IS. Then simply configured “no isis advertise prefix” directly under each interface which should not be included in the LSDB. This is cleaner than the above solution but still doesn’t scale well.

A third option which is more scalable than the above two methods is to not use “passive-interface default”. Instead configure “advertise passive-only” and “passive-interface Loopback0”, both under “router isis”. Now only the loopback0 IP prefix will be added into the LSDB and advertised into the IGP. The point-to-point interfaces are configured as normal and only IS-IS adjacencies form on this links explicitly configured with “ip router isis”:

interface Fa0/0
 ip router isis
 isis circuit-type level-2-only
 isis network point-to-point
router isis
 advertise passive-only
 passive-interface Loopback0

“show isis database detail [l1 | l2]” now shows only the loopback0 IP in the LSDB.

Comparing this IOS behaviour to Junos, because Junos only advertises IP prefixes for interfaces which have been explicitly enabled for IS-IS and it places the loopback0 interface into passive mode by default; the only missing feature to align a Juniper routers behaviour with the IOS router behaviour above is to prevent point-to-point links from being advertised and only advertise the loopback0 IP address whilst still keeping the point-to-point links active for IS-IS.

An export policy can be configured under IS-IS On Junos. Note that because IS-IS keeps two separate LSDBs for Level 1 LSPs and Level 2 LSPs, this export policy applies to routes advertised between levels, routes advertised between areas, and routes being redistributed in and out of IS-IS.

The example policy below matches any /32s from Level 1 neighbours (term 10) which this L1/L2 router will advertise over its L2 adjacency into the backbone area. It also matches its own loopback0 IP to advertise it into the Level 2 LSDB (term 20) and the Level 1 LSDB (term 30).

set policy-options policy-statement ISIS-Loopback0-Only term 10 from protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 10 from level 1
set policy-options policy-statement ISIS-Loopback0-Only term 10 from route-filter prefix-length-range /32-/32
set policy-options policy-statement ISIS-Loopback0-Only term 10 to protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 10 to level 2
set policy-options policy-statement ISIS-Loopback0-Only term 10 then accept
set policy-options policy-statement ISIS-Loopback0-Only term 20 from protocol direct
set policy-options policy-statement ISIS-Loopback0-Only term 20 from interface lo0.0
set policy-options policy-statement ISIS-Loopback0-Only term 20 to protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 20 to level 2
set policy-options policy-statement ISIS-Loopback0-Only term 20 then accept
set policy-options policy-statement ISIS-Loopback0-Only term 30 from protocol direct
set policy-options policy-statement ISIS-Loopback0-Only term 30 from interface lo0.0
set policy-options policy-statement ISIS-Loopback0-Only term 30 to protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 30 to level 1
set policy-options policy-statement ISIS-Loopback0-Only term 30 then accept
set policy-options policy-statement ISIS-Loopback0-Only term 40 from protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 40 from level 2
set policy-options policy-statement ISIS-Loopback0-Only term 40 from route-filter prefix-length-range /32-/32
set policy-options policy-statement ISIS-Loopback0-Only term 40 to protocol isis
set policy-options policy-statement ISIS-Loopback0-Only term 40 to level 1
set policy-options policy-statement ISIS-Loopback0-Only term 40 then accept
set policy-options policy-statement ISIS-Loopback0-Only then reject

lab@ACC31# run show isis database detail level 2 ACC31.00-00
IS-IS level 2 link-state database:
ACC31.00-00 Sequence: 0x7, Checksum: 0x902f, Lifetime: 1158 secs
   IS neighbor: AGG2.00                       Metric:       10
   IP prefix:                     Metric:        0 Internal Up
   IP prefix:                     Metric:       10 Internal Up

lab@ACC31# run show isis database detail level 1 ACC31.00-00
IS-IS level 1 link-state database:
ACC31.00-00 Sequence: 0x11, Checksum: 0xacb3, Lifetime: 1167 secs
   IS neighbor: ACC32.00                      Metric:       10
   IP prefix:                     Metric:       10 Internal Down
   IP prefix:                     Metric:       30 Internal Down
   IP prefix:                     Metric:       20 Internal Down
   IP prefix:                     Metric:        0 Internal Up

ACC32#show ip route
Gateway of last resort is to network

i*L1 [115/10] via, 00:14:12, FastEthernet0/0 is variably subnetted, 9 subnets, 2 masks
i ia [115/20] via, 00:04:02, FastEthernet0/0
i ia [115/40] via, 00:14:02, FastEthernet0/0
i ia [115/30] via, 00:14:12, FastEthernet0/0
i L1 [115/10] via, 00:17:01, FastEthernet0/0
C is directly connected, Loopback0
C is directly connected, FastEthernet0/0
L is directly connected, FastEthernet0/0
C is directly connected, FastEthernet0/1
L is directly connected, FastEthernet0/1

XR supports the “suppressed” command under the “router isis” stanza under “interface X/Y”. This allows the interface to participate in IS-IS and form an adjacency but the interface network prefix isn't advertised within the IS-IS LSDB.



When a router detects that an LSP has reached a zero LifeTime (not its own LSPs), it first removes the LSP from its LSDB. Then it floods the LSP with the LSP Lifetime and checksum fields set to 0. Other routers within the area do not totally remove the LSP, they wait 60 seconds (aka ZeroAgeLifetime). After those 60 seconds the LSP is definitely removed from the LSDB (if there is no update of this LSP).

Sometimes it might be useful to not wait for the LSP to expire naturally. To do that a router can send its own LSP with those 2 fields (LSP-Lifetime + Checksum) equal to 0. This mechanism removes automatically (after ZeroAgeLifeTime) the LSP in a network. It is used, for example, when you manually set the Overload bit. This network-wide-purge mechanism is performed by the router that owns the LSP.

When purging TLVs (sending LSPs with 0 lifetime + 0 checksum which contain one or more TLVs) the originating system ID may not be included in the LSP. On IOS-XR, the Purge Originator Identification TLV is included in purge LSPs by default if cryptographic authentication is disabled for LSPs. If cryptographic authentication is enabled then the Purge Origin ID needs to be explicitly enabled "lsp-password hmac-md5 encrypted 123 level 2 enable-poi". This is disabled by default on Junos can be enabled with "protocols isis level level-number purge-originator [empty|self]".



The default ISIS preferences for redistributed routes are as follows on Junos:
Internal level 1 routes : 15
Internal level 2 routes : 18
External level 1 routes : 160
External level 2 routes : 165
External routes meant “redistributed Routes” when the old metric style was used. When you use the knob wide-metric-only all types of ISIS routes (native, leaked, redistributed) are managed as internal routes.

set protocols isis level N external-preference M

Range: 0 through 4,294,967,295 (2^32–1)

On IOS the default metric for routes redistributed as internal and external routes into either L1 and L2 is 0 and must be explicitly set, for example “redistribute static ip metric-type internal level-X metric Y”.

A maximum limit can be placed on the number of external routes exported into IS-IS, which can help with redistribution errors. On Junos the “set protocols isis level-1 prefix-export-limit X”  command informs the router how many routes to accept using a routing policy configuration. This option is configured at a specific level using a 32-bit value, which provides a range of routes from 1 to 4,294,967,295. This does not affect internal (inter-area routes). XR also supports the feature under the “address-family x” stanza under “router isis” using “maximum-redistributed-prefixes X [ level { 1 | 2 } ]”. For XR the default is 10000 and the configurable range is 1 to 28000. IOS doesn't support this feature.


Reference Bandwidth

Junos supports and auto-cost feature that uses a reference bandwidth however, only on QFX and EX currently:

Cisco also support a reference bandwidth but only on NX-OS for fabric path:


Route Leaking (L2 -> L1)

Without distributing inter area routes into Level 1 from Level 2, IS-IS areas function as stubs, and Level 1 routers forward traffic to destinations in other areas through the nearest Level 1-2 router, not based on the reachability of that Level-1-2 router to the remote prefix (see info on the ATT/attached bit).

By default L2 routes are not leaked into L1 by L1/L2 routers although, L1 routes are by default propagated into the L2 by L1/2 routers.

Propagating Level 2 routes into Level 1 is called route leaking. Route leaking is required to allow L2 routes to be advertised into L1. When L2 routes are leaked into the L1 LSDB by a L1/L2 router and sent into L1 they use TLV 128 (IP Internal Reachability Information TLV) with the UP/DOWN bit set to 1 (UP). This TLV is the same TLV used for L1 originated routes within L1 so the TLV looks like an intra-area prefix; however, the UP/DOWN bit indicates that the prefix originated from another level. L1/L2 routers will use the UP/DOWN bit as a flag to filter those TLVs from being advertised back up into the L2 LSDB, natively preventing routing loops between L1 and L2 areas.

TLVs inside Level 1 which contain prefixes with the UP/DOWN bit not set (0/DOWN) originated inside Level 1. Level-1-2 routes will advertise these into Level 2, and other Level-1-2 routers can advertise them into Level-1 but will set the UP/DOWN bit (1). TLVs inside Level 1 which contain prefixes with the UP/DOWN bit set (1/UP) originated inside Level 2 or another Level 1 area and are not redistributed by Level-1-2 routers back into Level-2. When prefixes are redistributed from L2 into L1 and the UP bit is set, this is done unconditionally on Junos/IOS/IOS-XR and can’t be disabled.

If wide metrics are used then TLV 128 (the narrow metric Internal IP Reachability TLV) and TLV 130 (the narrow metric External IP Reachability TLV) are both replaced with TLV 135 the Extended IP Reachability TLV for L1 and L2 routes. TLV 135 has a 32 bit metric field however, there is no differentiation between internal and external routes now that the same TLV is sent for both route types. Also TLV 2, the narrow 6 bit metric IS Reachability TLV, is replaced with TLV 22 the Extended IS Reachability with 24 bit metric field.

Junos: Note that wide metrics cannot differentiate between internal and external prefixes. As a result, the use of only wide metrics results in the automatic leaking of external prefixes from Level 1 areas into Level 2 areas. You can use routing policy to block the leaking of external prefixes into the backbone area if needed.

The following output from PE ACC12 shows that it’s directly connected neighbour PE ACC11 is sending its loopback0 IP within the non-backbone area across the L1 adjacency:

ACC12#show isis database detail l1 ACC11.00-00
IS-IS Level-1 LSP ACC11.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
ACC11.00-00           0x00000019   0x18C7        850               1/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: ACC11
  IP Address:
  Metric: 0          IP
  Metric: 10         IS-Extended ACC12.00

The below output shows ACC11’s loopback0 IP being advertised (in addition to ACC12’s loopback0 IP) over the L2 adjacency to the AGG2 PE inside the backbone area, showing that L1 prefixes are automatically sent over L2 adjacencies:

ACC12#show isis database detail l2 ACC12.00-00
IS-IS Level-2 LSP ACC12.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
ACC12.00-00         * 0x00000026   0x5C4B        857               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: ACC12
  IP Address:
  Metric: 10         IS-Extended AGG2.00
  Metric: 10         IP
  Metric: 0          IP

These can be filtered, e.g. to only allow /32 for loopback IPs:


set policy-options policy-statement filter-L1-to-L2 from route-filter prefix-length-range /32-/32
set policy-options policy-statement filter-L1-to-L2 from protocol isis
set policy-options policy-statement filter-L1-to-L2 from level 1
set policy-options policy-statement filter-L1-to-L2 to protocol isis
set policy-options policy-statement filter-L1-to-L2 to level 2
set policy-options policy-statement filter-L1-to-L2 then accept
set protocols isis export filter-L1-to-L2


router isis
 address-family x
  propagate level { 1 | 2 } into level { 1 | 2 } route-policy route-policy-name

L2 to L1 route leaking can be enabled with:

IOS: redistribute isis ip { level-1 | level-2 } into { level-2 | level-1 } [ [ distribute-list list-number ] | [ route-map map-tag ] ]

Junos: set protocols isis export { policy-map }



Junos uses a two-run SPF paradigm (assuming IS-IS isn’t running in multi-topology mode). The first run will use only IS-reachability information to build the short path tree (the tree between SystemIDs). Then a second run will use the prefix reachability TLVs. Those prefix TLVs will be treated as leaves on the SystemID previous graph.

Junos uses 3 parameters to configure SPF runs:
delay (ms): minimum wait before the detection of an update and starting the SPF run (by default 200ms).
rapid-runs: number of consecutive SPF that might be run. Each SPF will be separated per a time equal to “delay”. (3 per default – max 5)
holddown (ms): time to wait before running again “rapid-run” SPF (by default 5000 ms)

spf-options {
 delay 100;
 holddown 5000;
 rapid-runs 3;

In Junos PRC is enabled by default for ISIS on Junos and can't be disabled.

Junos performs an SPF run every 15 minutes for IS-IS for increased reliability.


Summary Addresses

IOS-XR address-family level: summary-prefix address mask level { 1 | 2 } tag tag-number

IOS Router level: summary-address address mask [ level-1 | level-1-2 | level-2 ] [ tag tag-number ] [ metric metric-value ]

This command also reduces the size of the link-state packets (LSPs) and thus the link-state database (LSDB). It also helps network stability because a summary advertisement is depending on many more specific routes. A single route flap does not cause the summary advertisement to flap in most cases.

The drawback of summary addresses is that other routes might have less information to calculate the most optimal routing table for all individual destinations.

IS-IS Summary address cost:
 Equal to the best more specific cost
 Plus cost to reach neighbor of best specific


Traffic Engineering

Traffic Engineering is enabled by default for ISIS on Junos. For IOS and XR TE for ISIS is disabled by default and must be enabled under the “router isis” configuration section.