Interop IS-IS Scaling

References:
IS-IS Network Design Solutions By Abe Martey and Scott Sturgess
https://tools.ietf.org/html/rfc3719 - Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
MPLS In The SDN Era - Chapter 16
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-3/routing/command/reference/b-routing-cr-asr9000-63x/b-routing-cr-asr9000-63x_chapter_0101.html
https://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfisis.html#wp1039787
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_isis/command/irs-cr-book.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_isis/command/irs-cr-book/irs-l1.html

 

Increase Consistency

Cryptographic authentication should be used to detect corrupt packets more reliably. The standard IS-IS checksum doesn’t cover the LSP ID or sequence number fields.

 

Reduce Chatter

RFC3719 Sec 2.2 ISISHoldingMultiplier - The IIH multiplier on P2P links could be raised to a value higher than 3 if something like BFD is being used for liveliness detection or left as 3 if IIH are fully offloaded to hardware.

ISO10589 describes the periodic CNSP retransmission on LAN interfaces only. When periodic CNSP generation forcefully implemented on PtP links (e.g. by Junos and EOS, but not IOS-XR), this interval should be raised to the max supported value to reduce “chatter”.

Interface dampening should be used (and BGP dampening if these prefixes are redistributed to the IGP) to prevent IGP update flooding.

 

RFC3719 Section 2.1.  MaxAge:

  Each LSP contains a RemainingLifetime field which is initially set to
  the MaxAge value on the generating IS…The rate at which LSPs
  are regenerated by the originating IS is determined by the value of
  maximumLSPGenerationInterval.

  MaxAge is defined in ISO 10589 as an Architectural constant of 20
  minutes, and it is recommended that maximumLSPGenerationInterval be
  set to 15 minutes...Further, as RemainingLifetime is decremented each time it
  is forwarded, an LSP far from its origin appears older and is removed
  sooner. To make sure that an LSP survives long enough to be
  replaced, MaxAge should exceed maximumLSPGenerationInterval by at
  least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first
  term, ZeroAgeLifetime, is an estimate of how long it takes to flood
  an LSP through the network.  The second term,
  minimumLSPTransmissionInterval, takes into account how long a router
  might delay before sending an LSP.

The LSP MaxAge timer can be configured up to 65,535 seconds (over 18 hours). Set the MaxAge time to 65535 and increase the LSPRefresh timer to be near the MaxAge timer, so that unchanged LSPs are less frequently refreshed. Increasing the LSPRefresh timer to be near to the MaxAge time increases the amount of time that an undetected LSDB corruption can persist. To combat this it is important to enable cryptographic based authentication to minimise the spread of corrupted LSPs. IOS-XR and EOS allow the LSP Refresh timer to be configured.

 

Reduce Prefix Count

Limit IGP advertisement to loopback IP addresses only (or IPs used for transport forwarding), suppress interface level IP addresses (if supported by NOS).

Limit redistribution from other protocols into ISIS.

 

The following calculation can be used to determine how many IPv4 prefixes can be advertised in an LSP using TVL128 the “IP Internal Reachability Information TLV”. The following constraints are to be considered in the calculation:

    The maximum size (maxLSPsize) of an LSP is 1492 bytes.
    The LSP header (lspHeadersize) is 27 bytes.
    The maximum length of a TLV (maxTLVlength) is 255 bytes.

    Each TLV 128 consists of type (1 byte), length (1 byte), and IP prefixes (n x 12 bytes) up to a total of 255 bytes.

    The maximum number of fragments of an LSP (maxLSPfragments) is 256. The number of fragments is determined from the 1-byte LSP Number field in the LSP identifier.

    The first fragment contains other TLVs, and the remaining 255 fragments are packed with only TLV 128.

The calculation is as follows:

    The total space available for TLVs (TLVSpace) in an LSP is: maxLSPsize - lspHeadersize = 1492 - 27 = 1465 bytes

    The number of TLVs that can fit into TLVSpace is: 1465/255 = 5.7, approximately 6

    Assuming a 1-byte Type field and 1-byte Length field, overhead for 6 TLVs is: 6x2 = 12 bytes

    Actual space available for prefixes is: 1465-12 bytes overhead = 1453 bytes

    Number of prefixes, each 12 bytes (address + subnet mask + metric) that can fit into TLVSpace is: 1453/12 = 121.08 (approximately 121 IPv4 prefixes per LSP)

This means a theoretical maximum number of IP prefixes that could be advertised by an IS-IS router using 256 fragments, each containing 121 prefixes, is 30,976 IPv4 prefixes. In reality a few extra TLVs may be included in the LSP so this will be reduced a bit. This calculation doesn’t include any sub-TLVs (no MPLS, Segment Routing etc.). Also note that this calculation is using narrow metrics which aren’t best practice any more.

It is more likely that an LSP includes the Extended Intermediate System Reachability TLV (Type 22) and IPv4 prefixes are packed into the Extended IP Reachability TLV (Type 135).

Each TLV 135 consists of the values; type (1 byte), length (1 byte), and Nx IPv4 prefix entries (which are 9 bytes per IPv4 entry: 4 bytes metric, 4 bytes prefix address, 1 byte of flags [which includes the prefix length value]). This is a total of 11 bytes per prefix (assuming no sub-TLVs).

We can re-run the calculation as follows:

    Number of prefixes at 9 bytes each (metric + prefix + control byte) that can fit into TLVSpace is: 1453/9 = 161.4 (approximately 161 IPv4 prefixes per LSP)

256 fragments each containing 161 prefixes results in a theoretical maximum of 41,216 IPv4 prefixes. As mentioned before, some other TLVs will be included, and this doesn’t include sub-TLVs or TE TLVs etc.

 

---