ISIS training and Junos configuration

In this article we will configure an ISIS multi-area network and also explain some part of the ISIS theory.

Introduction:

For network guys ISIS is not a goddess in Ancient Egyptian religious beliefs but rather, the Intra Domain routing protocol specified by the IEC and then extended by the IETF.

IS-IS was first developed for the DECNET project Phase V by ISO:IEC. It was the first Intra AS (Autonomous System) network protocol, but only for network equipment that supported the OSI model and thus a CLNP stack (CLNS systems) : Connectionless Network Protocol.  IS-IS was not designed by default for IP.  The first version was published in 1987: ISO10589, then a second version in 2002 : ISO10589:version 2. At the beginning of the 90th : the IETF ISIS Working Group specified IP support for ISIS in RFC 1195. Other RFCs after that have been published to enrich the RFC 1195. IP support for IS-IS is also referred to as Integrated IS-IS. ISIS stack’s :

• IS-IS is conveyed directly at Layer 2
• Even though IS-IS was not initially designed for IP, it provides a simple way to add new extensions by using TLV (Type Length Value) fields.
• Indeed, ISIS data is conveyed by using the TLV method : That was the case for IPv4 and then IPv6 extension and recently for SPB. The concept is: Just adding new TLVs for a new protocol family and If you don’t support a given TLV just silently ignore it. Note: TLV has been also extended with sub-TLV.

The Basis :

In the whole article we’ll speak about:

• IS: Intermediate System (This is the router)
• Circuit: it’s a link between 2 IS
• Neighbor: a directly connected IS on a Circuit
• LSP: Link State PDU (packets that transport the IS-IS database of a router)
• Adjacency: IS-IS “session” established between 2 IS directly connected allowing LSP exchanges.
• Point to Point (P2P) link: implicit P2P link like for example Sonet or Frame Relay (not multipoint) but also a multipoint link (Ethernet) configured explicitly in Point to Point (useful when only 2 routers are connected on an Ethernet segment).
• Pseudo-Node: One specific router on a LAN.
• Area : Like OSPF, this is a group of routers that are in the same ISIS flooding domain.
• Level : Hierarchical level. Only 2 Levels in IS-IS
• Leaking : ISIS routes leaked from an IS-IS level to another.
• Redistribution : Injected routes into IS-IS (coming from other protocols: static, RIP, BGP…)

Hereafter the IS-IS Header (for every ISIS PDU):

ISIS is different than other routing protocols. It’s totally independent of layer 3. On Ethernet, ISIS can be conveyed with a 802.3 LLC or 802.3 LLC-SNAP sub-layer.

• Today's implementations use the LLC format only.
• The EtherType field of the Ethernet Frame becomes a length field with a maximum value of 1500.

With LLC encap. ISIS frame has a maximum size of 1518 – (21 bytes (default eader)) = 1497 bytes. With a SNAP header we add 5 bytes. So on Ethernet the maximum PDU size is 1492 Bytes. There are reserved destination MAC addresses to convey ISIS Frames : Today, ISIS conveys IP routing information, nevertheless each IS (router) is still identified via an OSI address: used to originate the LSP.  ISIS requests only one OSI address or NET (Network Entity Title) per router. Note: We can configure more than one NET for merging, splitting, renumbering areas purposes but it’s out of the scope of this presentation. The NET address is a variable data but it usually has a size of 10 bytes.  The NET is made of 3 parts:

• The Area ID
• The SystemID
• The NSEL (NET Selector)

The NET address:

• Area ID:
  • Variable part of the NET address: usually equal to 1, 3 or 5 bytes.
  • The first byte (AFI – Address Family Identifier): (like IP : Public, private address). Just remember that usually SP has not a public range of ISO addresses and uses the AFI = 49 (private-addressing)
  • The following bytes of the AREA ID can be arbitrary filled to represent the Area number: useful for Level 1 adjacency.
•  System ID:
  • Like the OSPF router-id this identifies uniquely the router.
• System ID :
  • Usually SystemID is derived from the IP loopback address, 3 known methods are used:

• NSEL:
  • The NSEL is like the Protocol field of the IP header. It must be set to 0x00 in order to an adjacency comes up.

On Junos, the NET address is configured at the loopback level: SystemID has not a human meaning. We need a kind of conversion SystemID/Name. The SystemID name conversion cannot be based on DNS protocol : SystemID is a 48 bits fields. IS-IS includes its own resolution name “protocol”. Each IS coveys an optional TLV in each PDU LSP L1 or L2. This TLV is called “Dynamic Hostname” and has the number 137.  By default, the hostname configured on the router is included in the TLV 137.  So, dynamically, once the adjacency is UP the router sends the TLV 137 into its LSPs.

This TLV is used by Junos to display with a “Name” the adjacency and ISIS database information.

The area :

For Link State routing protocols, the area groups several routers within the same flooding domain.  We can scale a network, for example, by limiting network event impacts to a specific Area or limiting the number of nodes in the LSBP. Those network designs allow better convergence times. Unlike OSPF, where the area border is a router, IS-IS area border is a link. Each router is usually configured with one Area ID but can belong to several Levels: Level 1 only, Level 2 only or Levels 1 and 2 (note the default is Levels 1 and 2). ISIS defines 2 hierarchical levels for Area

• L1 Area: the lowest hierarchical level.
• L2 Area: that’s the BackBone Area (aka Area 0 for OSPF).

The Level 2 area must be contiguous. In other words a level 2 router cannot be isolated. The L1 areas are connected to L2 area.  Each router keeps a separate LSDB per level.

• Note: a route known in L1 will always be better than a L2 route.
• Note 2: splitting the network in several area (Level) is not mandatory (should be triggered by the design, the growth of the network)

The Area ID has only a meaning for L1 adjacencies. Indeed, to establish an L1 adjacency, 2 routers must have the same area ID. It is not the case for L2 adj.

Remember : the Area ID is coded within the NET address and is a global parameter.

In our example IS-IS L1 adj. between R1 and R2 will be established only if the 2 routers have the same AreaID (here. 49.0002).

In // to establish a L2 adjacency between R11 and R12 the AreaID checking is not done (R11 is a L1L2 router which has the AreaID 49.0002 to establish a pure L1 adj with the router R1).  This ID has no meaning when it establishes an adj. with R12 (a pure L2 IS) which has the AreaID 49.0001 .

On Junos, the “family iso” statement must be added at interface level for Interfaces that want to handle ISIS PDU and then the configuration of ISIS parameters are done at "protocols isis" level.

The metrics :

There are several set of ISIS metrics: IS metric and IP metric ; and also several style: the old-style and the new-style.  Today, networks use only the new style of metrics for IS and IP information.  For ISIS for IP - we have 2 kinds of “objects”  :  « IS reachability »  (IS = router)  and  « IP reachability ». ISIS can be split by level (one link may belong to several levels), so there is one metric per level.  ISIS metrics rely on static metric and not on BW derived metrics like OSPF. Nevertheless, Junos can switch to BW derived metrics for ISIS if needed.

Default metrics are 10 for L1 or L2. Some exceptions :

• For Passive interface the default metric is 0.
• For redistributed or leaked routes: the metrics is equal to the route cost

Notice: The passive mode is a per level configuration. It allows the announcement of interface in the Link State DB but not allows the adjacency establishment on it :  No ISIS Hello is sent ;  No ISIS pdu is taken into account. It is very useful for :  Announcing loopback interfaces or Announcing stub interfaces.

The old style metric is a 6 bits field. So it offers at most 64 different metrics (0 to 63). Moreover the aggregated metric (max cost) was limited to 1023. Currently we only use “Wide Metrics” which offer a larger range of metrics. The IS and IP reachability TLV (TLV 22 and TLV 135) which convey those metrics are depicted below:

Notice: By default Junos sends both types of metrics : the old and new styles. To only use New-Style (recommended), you should use the knob : wide-metric-only

Inter-level routing :

On multi-area topology some routes are “leaked” between Levels. The default behaviour is the following :

• Leak only Internal routes from a Level 1 area to a Level 2 area
• Leak nothing from a Level 2 area to a Level 1 area. But a L1/L2 router set a specific flag ‘Attached-bit’ within its Level 1 LSP that means : “I know the Backbone, you can use me as a default gateway”. So Pure L1 nodes receive from L1/L2 nodes a kind of default gateway .

But this default behaviour could be overridden in case of:

• Using specific export policies
• Wide-metric-only knob changes all the prefixes conveyed by ISIS as Internal routes : this includes redistributed routes (New style TLVs don’t keep the E/I flag anymore).

When you want to modify the default leaking policies, you might trigger routing loops. For example a /32 leaked from L2 to L1 then leaked back from L1 to L2 and so on. This is not possible because ISIS includes a specific flag (per IP reachability – aka per prefix) which informs if a prefix has been leaked. This flag is called the Distribution bit (aka UP/DOWN bit). When a route is leaked by a policy from the Level 2 to the Level 1, the UP/DOWN bit of this route is set to DOWN which means that the route comes from the Level 2. Then a DOWN route can never be leaked back from L1 to L2.

Notice: a policy which modifies the L1 to L2 leaking never modifies the UP/DOWN bit which it still set to UP.

 

On Junos, you need to create your own policies and apply them at the “isis export” level to change the default leaking policies. Hereafter an example where all the /32 are leaked from L1 to L2 and L2 to L1. Remember: automatically DOWN bit is set for routes that match L2toL1 policies which avoids routing loop.

ISIS adjacency:

ISIS adjacency allows to discover neighbors and checks several parameters. It allows to discover the SystemID of the neighbor ; it allows to exchange capabilities (like Graceful Restart) : it allows to check the neighbor compliancy : which family it supports ; if the IP network of the link is in the same range (to validate the Next-hop); if the MTU of the link can conveys the max. size of an ISIS PDU...

To establish an adjacency, ISIS routers use Hello packets called IIH (ISIS Hello) . There are 3 kinds of IIH ; Level1 IIH for LAN segment ; Level 2 IIH for LAN segment and Level1/Level2 IIH for point to point segment. IIH are directly conveyed in ISIS PDU (Type 15, 16 or 17). The holdtime of the adjacency is conveyed in the IIH, too. The default holdtime on Junos is  27 seconds (3x9secs).

Notice: For p2p adjacency the holdtime is shared by both levels (On L1/L2 adjacency, Junos will use only the Level 1 holdtime configured value). Hereafter the IIH for LAN segments:

And the IIH for point to point interfaces:

During adjacency establishment, the protocol will check:

• MTU checking = TLV 8 : The ISIS PDU has a maximum size of 1492 bytes. So a link should be able to handle packet with a size of 1492 bytes. To be sure that the link supports this MTU, the IIH packets are padded with a specific TLV. Padding can be done for each IIH, on every IIH before the adj. comes up or only during the initialization phase.
• The subnet checking = TLV 132 : each neighbor checks that the link, where the adjacency tries to come up, is in the same subnet. The TLV 132 conveys the IP addresses configured on the link (primary and secondary addresses). The neighbor checks if its link has also an IP address in the same range. If not, the adjacency will never come up.  This TLV is transmitted in all IIH packets.

• Protocol checking = TLV 129 : ISIS can conveys CLNP ; IPv4 ; IPv6 … routing information. Only neighbors with at least a common capability can establish an ISIS adjacency. Capabilities are conveyed in TLV 129. This TLV is transmitted on every IIH and/or LSP packets.

 

• Area checking = TLV 1 : ISIS area number is only used for L1 routers. L1 routers with not the same Area-ID will never establish an ISIS adjacency.

Junos supports the 3 Way handshaking (like TCP) during the ISIS adjacency establishment. During this kind of “syn ; syn-ack ; ack” exchange the checks described above are performed. The 3 Way Handshake allows unidirectional failures detection. The 3-Way handshake uses TLV 240 (for p2p adj) or TLV 6 (for broadcast segments). The state machine is depicted below:

The next diagram shows the 3-Way Handshaking to establish an ISIS adjacency on a p2p link.

Now, we can see how to configure ISIS adjacency parameters on Junos. Note for holdtime the multiplier is by default 3 and it is not configurable. But you have the choice to set up either hello-interval or holdtime. Setting both has no sense.

Juniper implements an Adjacency Holddown mechanism. This one takes into account the number of Adjacencies UP and the history of ISIS activity. So, sometimes, ISIS adjacency could take some time to become up. This is due to this mechanism. You cannot configure this holddown value but you can disable it (enable by default):

Pseudonode and broadcast circuit :

Like OSPF, ISIS manages LAN segments differently (Ethernet interface not configured as point to point). 2 new concepts are important on LAN segments:

• The Pseudonode : a virtual router, the LAN orchestrator’s
• The DIS : Designated IS (aka DR for OSPF) : one real router of the LAN. It elected to take in charge the management of the Pseudonode.

A pseudonode is here to simplify the LAN topology as a point to point topology. The following diagram shows this concept. The pseudonode is seen as a real router with its own LSDB. The DIS is in charge to manage its own LSDB and the pseudonode LSDB.

Explanation of the above diagram:

• Virtually, the pseudonode connects all physical routers of the LAN with p2p links.
• From the pseudonode point of view, to reach a physical router the metric is set to 0. But from a physical router to reach the pseudonode the metric is the configured metric of the LAN.
• As we can see the pseudonode never adds additional cost between physical routers : for example between routers A and C the cost is still 50.

How the pseudonode is identified in the network:

• Remember IS are identified by their SystemID
• A pseudonode (a virtual IS) is identified on the LAN by its NodeID
• The NodeID is generated by the DIS by merging the SystemID of the DIS and one additional byte : the pseudonode-ID

If the pseudonode-ID is equal to 0x00 therefore the LSP (identified by the LSP-ID) conveys the LS info of the physical router. If the value is not equal to 0x00, therefore the LSP conveys the LS info of the pseudonode. The value of the pseudonode-ID is chosen arbitrary per LAN segment by the DIS. It should be unique by router.

How the DIS is elected ? The DIS election is done during the adjacency establishment phase and it is based on the priority field (0 to 127 - default is 64) conveyed within the IIH. The higher priority will win the DIS election. A value of 0 means that a router doesn’t want to participate to the DIS election. When 2 routers have the same priority, the router with the higher MAC address will win the DIS election. When elected, the DIS allocates a pseudonode-ID and starts to generate the LSP of the pseudonode.  DIS pre-emption can be done at any time. The DIS is detected has dead when its adjacency timeout. To quickly detect that a DIS is dead, the holdtime of the DIS is divided per 3 (ex. If you configure an holdtime of 9 seconds – automatically the holdtime of the DIS will be 3 seconds). DIS election Diagram:

Junos Priority configuration:

ISIS Database exchange:

ISIS is a link state protocol. Each router sends its local information via Link State PDU aka LSP (Links with ISIS Adjacency UP ; Interfaces in passive ; leaked and redistributed routes). Those information are flooded through the area. Each router then computes the Short Path First algorithm toward each destination. Each router keeps a database per level (1 and/or 2). Each router generates at least one LSP.

The LSP conveys : IS and IP reachability ; the sequence number of the LSP ; the name of the router (via the TLV 137)  ; 2 flags (Overload and Attached bits)…

Hereafter the ISIS LSP header:

The five important fields are :

• The LSP sequence number: this is a version number. When a router sends a new version of its LSP it increments this field of 1. A higher value is always considered as a more recent version. It starts with a value of 1.
• The LSP Lifetime: this is the time before the LSP will be considered invalid. By default the LSP lifetime is equal to 1200 seconds (20 minutes). Each time a new version of the LSP is sent, each time the LSP Lifetime is reset to its default or configured value. In very stable network, without periodic LSP retransmissions, LSP Lifetime might reach the value of 0. To avoid this, on Junos the latest version of the LSP has to be re-transited when the LSP Lifetime reaches: Configured LSP-Lifetime – 317 seconds. This is called LSP Refresh.

Notice: LSP refresh increments also the Sequence Number of 1 : event if there is no LSP modification.

• Checksum: Allows to verify the LSP data integrity
• The LSP-ID : The 8 bits field that uniquely identifies the LSP. It makes of : the 6 bytes SystemID of the router ; the 1 byte of the PseudoNodeID (If no pseudonode = equal to 0) ; The fragment ID. Remember that the maximum size of a LSP is 1492 bytes. We will describe in more details the ISIS Fragmentation later.

 

• The flags : P ;  ATT 1 to 4 ; OL ; IS-type.

Only the fragment number 0x00 can convey :

• the state of Overload bit and attached bit ;
• the TLV 1 (area-ID) ;
• the IS-type field indicating at which level(s) the router belongs to. If a router has to update those previous information.

It has to send back the LSP fragment zero only and incrementing its sequence number.

P bit is not used.

Only the ATT 1 bit is used and set to 1 in LSP Level 1 when a router belongs to also the Level 2 area. Remember, a pure L1 routers will install a default gateway toward the router(s) with ATT bit set.

The OL bit was first implemented to notify the network when a router is in Out Of Memory state. It is now used more for maintenance to remove traffic on a router. When this flag is set by a router : the router flushes all its LSP (all its fragments) and sends only one or more LSPs that will convey only its adjacencies UP and its passive interfaces. It doesn’t advertise any more Leaked and Redistributed routes. A router in overload is still in the topology but cannot be used for transit; it’s only seen as a leaf router.

The IS-Type indicates to which Level the routers belong to (L1 ; L2 or L1/L2).

LSP flooding means that when a router sends its LSP, this one will be received by all the other routers of a given area (excepted if you use mesh-group for example). The flooding is performed like that:

• A router that has to send an LSP sends it on all its interfaces with an adjacency UP.
• A router that receives an LSP, checks first the Sequence Number with the version of the LSP that it currently has in its LSDB:
  • If the received LSP has a sequence number greater than its version. It will update its database with this new version and then will flood the LSP on all its adjacency UP except the one where it received the LSP (split horizon)
  • If the received LSP sequence number is equal to its version. It silently discards the LSP and stops the flooding.
  • If the received LSP sequence number is lower than its version. It silently discards the LSP and sends back on the received interface the LSP version that it owns.

ISIS Database purge:

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 of the LSDB (if there is no update of its LSP).

Sometimes it might be useful to not wait for the LSP expired 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.

ISIS Flow control:

On large network, ISIS flooding could generate a lot of control plane messages. The ISIS protocol implements some kinds of rate-limiter. There are 2 types of flow control:

• The number of LSP which an Interface can transmit (in transit)
• The number of LSP which a router can generate (host generated)

The first limiter on Junos is called lsp-interval which is by default equal to 100ms. This means that an interface can transmit at most 10 "transit" LSP per seconds. The second limiter which applies on host LSP generated is called miminumLSPGenerationInterval. Juniper has an "hardcoded" implementation to manage the generation of its own LSPs. Indeed, Junos can only generate 3 rapid LSP and then wait a variable timer. The following diagram explains the concept:

ISIS Retransmission:

We will see later but when an LSP is sent, an acknowledgement is needed. If an LSP is not "ack" within the next 5 seconds, the LSP should be retransmitted. This value is not configurable on Junos.

Database synchronisation - the concepts:

The ISIS database synchronisation is done via 2 specific PDUs which are only generated per segment (no flooding):

• CSNP: Complete Sequence Number PDU
• PSNP: Partial Sequence Number PDU

As there are 2 levels, there are CSNP and PSNP per level. Those 2 messages allow a router  to recover the entire database of a network when it boots and on the other hand to keep the LSDB synchronised in the time. Those 2 messages are also used to acknowledge LSPs in some cases. The CSNP and PSNP messages don't carry the entire LSP information but only LSP identification and status. Indeed, an entry in a CSNP or PSNP message is made of :

LSP ID + Sequence Number + Lifetime + Checksum

The CSNP message carries information regarding all the LSP ID present in the LSDB. Unlike PSNP carries only one or more LSP ID information. The structure of CSNP and PSNP are depicted below:

CSNP PDU:

PSNP PDU:

And Each LSP entry is described in a TLV 9:

To better understand the synchronization concepts, we need to understand the internal ISIS state machine. Indeed, internally ISIS protocol uses to FLAGs called:

• SRM flag: Send Routing Message
• SSN flag: Send Sequence Number

Those 2 flags are allocated per LSP and per Interface. In other words, each LSP-ID has its own couple of (SRM,SSN) flags per Interface. Hereafter an example of the internal view of the router A:

Explanation of the above example:

SRM flag indicates to the "flooding engine" which LSPs on which interfaces have to transmitted. SSN flag means to the router to acknowledge (with PSNP or CSNP) the given LSP on the given interface. So for our example, a new adjacency between router A and router B came up, what does the router A do ? Based on the flags we can say that:

• The router A has to flood the latest version of the fragment 0 of its LSP on every Interfaces
• The router A needs to acknowledge the LSP of B on Circuit 2 within the next 5 seconds.
• The router A has to flood (forward) the LSP of B received on circuit 2 on Circuit 1 and 3.

Database synchronisation on LAN segments:

The synchronisation on LAN segments is done like that:

• When the adjacencies are up on the LAN : the DIS is elected.
• The DIS plays a specific role during the synchronisation. Periodically (every 10 seconds) the DIS transmits on the LAN a CSNP message, which are received by all the others routers of the LAN.
• With this mechanism the DIS verifies that all other routers of the LAN have the same view of the entire network.
• The periodic transmission of CSNP is configurable on Junos but only for LAN segment

The other routers of the LAN that receive the CSNP message(s) of the DIS can encounter 4 cases:

• The Database is synchronised. All the sequence numbers of all LSP-ID are equal between the DIS and the router
• The CSNP carries one or more LSP-ID with a lower Sequence Number.
• The CSNP carries one or more LSP-ID with a greater Sequence Number.
• The CSNP carries one or more LSP-ID unknown.

If a router detects that a LSP-ID received by the DIS is lower that its own version of the LSP. The router sends back to the DIS this given LSP. No direct acknowledgement is need there. Thus, the DIS updates its LSDB. The next periodic CSNP transmitted by the DIS will play the role of acknowledgement. The following diagram summarizes this first case:

If the router receives a more recent LSP-ID from the DIS than its version. First, this router sends a PSNP for this specific LSP-ID to the DIS (on the LAN) whith a value of 0 for the fields: Sequence Number ; Lifetime and checksum. The DIS which has received this PSNP set the SRM flag of the LSP-ID specified within the PSNP on the received interface. The "flooding process" of the DIS sends then the requested LSP on the interface and clears the SRM flag. No direct ack are needed again on the LAN. Indeed if the latest version of the LSP is not received within the 5 seconds, the router will sends back a new PSNP.

If the router detects a new LSP-Id that it didn't have before in its LSDB, First, this router sends a PSNP for this specific LSP-ID to the DIS (on the LAN) whit a value of 0 for the fields: Sequence Number ; Lifetime and checksum. The DIS which has received this PSNP set the SRM flag of the LSP-ID specified within the PSNP on the received interface. The "flooding process" of the DIS sends then the requested LSP on the interface and clears the SRM flag. No direct ack are needed on the LAN. Indeed if the latest version of the LSP is not received within the 5 seconds, the router will sends back a new PSNP. This case is depicted below:

Database synchronisation on p2p segments:

On point to point segments the CSNP and PSNP usage is different. On p2p segment when a new adjacency comes up, the CSNP is sent first and then the SRM flag is set for all LSP-ID on this given interface. But this doesn't mean that all LSPs will be flooded on this Interface because on the other side the other router has done the same thing. So before sending real LSP each router compares CSNP messages. So almost all SRM flags will be cleared and only not synchronised LSPs will be flooded back. Unlike LAN segment, each LSP sent has to be acknowledged specifically. In other words, the SRM flag of an LSP-ID is never cleared until a PSNP or a CSNP including the LSP-ID is not received. Moreover, on p2p segment, periodic CSNP are not mandatory but JUNOS implements an hard-coded mechanism that generates periodic CSNP over p2p interfaces to allow better network stability.

The CSNP transmission algorithm on p2p is based on the number of adjacencies UP at a given time. If N is the number of Adj. UP the Juniper router sends periodic CNSP on each interface every Nx5 seconds. Hereafter an example of the Junos CSNP periodic transmission mechanism with 4 adj. UP.

The other mechanisms for LSDB synchronisation on p2p segments are the same as mentioned for LAN segments. The 2 next diagrams describe in detail the synchronisation on a p2p link. You can see, the internal flags state and the CSNP/PSNP exchanges.

Junos configuration:

ISIS Fragmentation:

On core networks the MTU is usually greater than 1500 but the ISIS frame is still limited to 1492 bytes (except with the Jumbo Frame option (TLV 14) - not supported by Junos). Moreover ISIS is directly conveyed over Layer 2 which doesn't include fragmentation mechanism (like IP). Today, a ABR router with a lot of leaked routes or an ASBR with of a lot of redistributed routes requests more than one frame to convey its Link State information. ISIS implements its own fragmentation mechanism. Several PDU might be fragmented: IIH, xSNP and LSP.

IIH, even if it can convey a lot of optional TLVs, those information fit in one frame. So no IIH fragmentation has been implemented.

CSNP and PSNP can convey more than 1492 bytes (often the case for CSNP) but CSNP or PSNP information can be easily fragmented in several CSNP or PSNP PDUs. Indeed in the header of xSNP messages you have the fields : Start-LSP-ID and Stop-LSP-ID.

For LSP: A new byte has been added at the end of the LSP-ID. This one is called: fragment-ID. So if a router needs more than 1492 bytes to describe its link state information it can use more than one fragments. All the router LSPs will have the same identification based on the System-ID + a specific byte to identify the fragment. Like this :

The fragment-ID always begins at 0 and is incremented by 1 for the other fragments. A fragment has its own LSP-ID and is totally independent. It means it has its own parameters: Lifetime + Sequence Number + Checksum. But remember only the LSP-ID with the fragment-ID 0 can convey the status of the flags: Overload and attached bits. The fragment 0 is the only one which can conveys the TLV 1 (Area-ID) and it is also the only mandatory fragment. The Fragment-ID is a 8 bits field. So an ISIS router can use at most 1492x256 bytes of payload. This means around 42000 @IPv4. If you use more, automatically you reach the limit of ISIS and the router will purge its LSPs and set its Overload bit.

When link states information change, the Juniper tries to change the less possible its fragmentation (conservative algorithm). Hereafter an example:

Short Path First implementation:

Junos uses 2 runs of SPF. The first run will use only IS-reachability information to build the short path tree (the tree between SystemID). Then a second run will use the IS-reachability information. Those information will be seen as leaves graphed to the previous tree.

On Junos, "SPF runs" can be configured. 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)

The next diagram describes the concept:

Junos configuration:

ISIS authentication:

Junos allows a per level authentication and a per PDU authentication. The ISIS authentication uses a TLV (TLV 10) to conveys either a Simple Password in plain-text or a digest message (HMAC MD5). When the TLV is present within a PDU: IIH, CSNP, PSNP, LSP a router has to check the simple password or the message integrity (with the HMAC) before it takes into account the PDU. Even if the authentication can be configured per level, on p2p interface Level 1 and Level 2 share the same IIH PDU. Therefore, only Level 1 authentication parameters will be used. To change ISIS password without impacting the network stability, Junos allows to deactivate the taken into account of the TLV 10 by 2 the specific knobs: no-authentication-check or loose-authentication-check (Verify authentication only if PDU has authentication TLV).

For example the knob no-authentication-check should be deployed on all routers of the area before starting changing authentication parameters. If you use ISIS authentication on Junos, by default it activates authentication for all PDU. You can then specify on which PDU you don't want authentication but LSP PDU will remain authenticated (it means at least LSP are authenticated when you configure ISIS authentication).

Per interface (& level) IIH authentication is also available on Junos to allow specific adjacency configurations.

ISIS prefix-imit:

ISIS prefix-limit knob allows to limit the number of routes that a router can redistribute (ASBR point of view). This does not include Leaked-routes (aka inter-level route leaking). This feature is available per level:

ISIS preference:

The default ISIS preferences are the following:

• 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. You can change preferences per level:

ISIS TE:

Unlike OSPF, Traffic Engineering is enable by default on ISIS. The TE information are conveyed within LSP via the TLV 22. The TE router ID used in the TED is also conveyed within LSP via a specific TLV : TLV 132.

The TLV 132:

The TLV 22:

ISIS IPv6 support:

IPv6 capability is enabled by default and it is announced with IIH via the TLV 139. To support IPv6, ISIS only added a new TLV to describe IPv6-Reachability information. This TLV is the TLV 236.

To disable IPv6 support:

Conclusion:

ISIS is a very flexible protocol and Junos implements all default features and also some recent ones (like LFA (aka. link-protection). The configuration of ISIS on Junos is quite simple but you just well remember that you can sometimes configure the same feature globally ; per level ; per interface or per interface/level. Moreover, never forget that with wide-metric knob all ISIS routes are considered as Internal.

My recommendation is : play with all those features on a iNET ZERO lab rack; use monitor traffic interface ge-x/x/x matching "not-ip" capture analyzer to well understand each ISIS PDU and concepts explained in this article.

Also you can use The iNET ZERO JNCIE-SP workbook as it has some very challenging ISIS troubleshooting tasks, which ensure you will get a firm grasp on the ISIS protocol.