IS-IS Explained: Link-State Routing, Levels, TLVs and Authentication

IS-IS (Intermediate System to Intermediate System) is a link-state interior routing protocol: every router floods a description of its links, builds the same map of the network and runs a shortest path first calculation over it. It began as the OSI routing protocol in ISO/IEC 10589 and was extended to carry IP in RFC 1195, published in December 1990. Large service provider networks favour it because it scales with two levels, runs directly over layer 2 and grows by adding TLVs instead of new packet types.

That same design shapes how you secure it. IS-IS packets never travel inside IP, so firewall rules and IP access lists do not see them, and a device that can send frames on a routing link can try to form an adjacency. Protection comes from passive interfaces, careful level design and the authentication TLV. This post goes one level deeper than our guides to OSPF and BGP, and ends with a two-area FRRouting lab.

Key takeaways

• IS-IS is specified for OSI in ISO/IEC 10589 (first edition November 1992, second edition November 2002, according to RFC 7142) and for IP in RFC 1195 (December 1990), which defines Integrated IS-IS for pure IP, pure OSI and dual networks.
• Every router has a Network Entity Title (NET) such as 49.0001.0000.0000.0001.00: an area address, a 6 octet system ID and a selector of 00. The system ID, not an IP address, identifies the router in the topology.
• Routers discover each other with hellos, describe themselves in Link State PDUs (LSPs), sync databases with CSNPs and PSNPs, and on a LAN elect a Designated Intermediate System (DIS).
• Level 1 routers route inside one area, Level 2 routers form the backbone, and Level 1/Level 2 routers at the border set the attached bit so Level 1 routers default to them. Routes can be leaked down with the up/down bit (RFC 5302).
• Everything in IS-IS is a TLV (type, length, value). New features arrive as new TLVs or sub-TLVs: wide metrics and traffic engineering (RFC 5305), IPv6 (RFC 5308), multi-topology (RFC 5120) and segment routing (RFC 8667).
• Authentication lives in TLV 10. Type 1 is a cleartext password, type 54 is HMAC-MD5 (RFC 5304) and type 3 is generic cryptographic authentication with a Key ID and HMAC-SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 (RFC 5310).
• HMAC alone does not stop replay of hellos and sequence number PDUs. RFC 6039 describes the gap and RFC 7602 adds an Extended Sequence Number TLV to close it.
• FRRouting's isisd, as documented and in its source on 24 October 2026, supports cleartext and HMAC-MD5 only. The lab below uses HMAC-MD5 and explains what to look for on platforms that implement RFC 5310.

What IS-IS is and where it came from

The OSI origin

IS-IS was designed for the OSI protocol suite, where routers are called intermediate systems and hosts are end systems. Its job was to route the OSI Connectionless Network Protocol (ISO 8473). RFC 1142, published in February 1990, republished an early ISO draft proposal (DP 10589) of the protocol. RFC 7142 (February 2014) later moved RFC 1142 to Historic and explained why: the draft differed in important ways from the published standard, which appeared as ISO/IEC 10589:1992 and was revised as ISO/IEC 10589:2002, the second edition. RFC 7142 asks implementers to reference the ISO standard, not the old RFC copy.

Integrated IS-IS for IP

RFC 1195, titled "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", is the document that made IS-IS an IP routing protocol. Its abstract describes an integrated routing protocol that can serve pure IP, pure OSI and dual environments, developed by the IETF IS-IS working group. Rather than build a separate IP version, RFC 1195 added new TLVs to the same packets: IP reachability (TLVs 128 and 130), a list of supported protocols identified by NLPID (TLV 129) and IP interface addresses (TLV 132). An IS-IS router therefore needs an OSI style NET even when it routes nothing but IP.

Who maintains it now

IS-IS extensions are developed in the IETF Link State Routing (LSR) working group. Its charter says it was formed by merging the IS-IS and OSPF working groups and covers maintenance and extensions of IS-IS, OSPFv2 and OSPFv3. Code points are kept by IANA in the IS-IS TLV Codepoints registry, which lists the top level TLVs and dozens of sub-TLV registries; the copy we fetched was last updated in May 2026.

Dated timeline

Why large networks choose it

The reasons operators give are mostly structural, and each one traces back to the specifications.

• One protocol for IPv4 and IPv6. Because IPv6 arrived as new TLVs (RFC 5308), a single IS-IS instance, one adjacency per link and one database carry both address families. OSPF needed a new protocol version, OSPFv3 (RFC 5340), for IPv6.
• Few packet types, many TLVs. IS-IS has hellos, LSPs and two kinds of sequence number PDU. New capabilities arrive as TLVs that older routers skip and still flood, so rollout can be incremental.
• A flat Level 2 backbone. Many providers run a single Level 2 domain across the whole network, relying on modern router capacity rather than many areas.
• Separation from IP. Because IS-IS does not ride on IP, an IP addressing mistake does not stop the routing protocol from forming adjacencies, and IP packets from outside the network cannot reach the routing process directly.

For data centers the picture is mixed. RFC 7938 (August 2016) documents large data centers that chose BGP as their only routing protocol, while the LSR working group's RFC 9667 (October 2024) addresses a real problem for link-state protocols such as IS-IS in dense leaf and spine fabrics: too much flooding. Neither choice is universally right; the comparison table later lays out the trade-offs.

How IS-IS works

NETs, area addresses and system IDs

Each IS-IS router is identified by a Network Entity Title. A NET is an OSI network address with the selector byte set to zero, written in dotted hexadecimal. It has three parts:

1. Area address. Variable length, from the start of the NET up to the system ID. Routers in the same Level 1 area must share at least one area address.
2. System ID. Six octets that must be unique in the routing domain. This is the identity of the router in every LSP and in the SPF tree.
3. Selector (NSEL). One octet, always 00 for a router's NET.

Worked example: decoding a NET. Take 49.0001.1921.6800.1001.00.

Encoding a loopback address into the system ID is a convention, not a rule; what matters is that the six octets are unique. A duplicate system ID is one of the most disruptive IS-IS faults because two routers then originate LSPs with the same LSP ID and overwrite each other's view of the network.

RFC 1195 also explains how areas can be renumbered without downtime: a router may hold several area addresses at once, and Level 1 routers form an adjacency if any of their area addresses overlap. You add the new area address everywhere, then remove the old one router by router.

Hellos and adjacencies

Routers find neighbours by sending IS-IS Hello PDUs (IIHs). There are three kinds: Level 1 LAN hellos, Level 2 LAN hellos and point-to-point hellos. Each hello carries the sender's system ID, its circuit type, a holding time and, on a LAN, its priority for DIS election. On a LAN, a hello also lists the neighbours the sender has already heard, which is how two routers confirm that communication works in both directions (RFC 6039 describes this neighbour list).

On point-to-point links, the original ISO procedure was a two-way exchange that could leave one side thinking an adjacency was up while the other did not. RFC 5303 (October 2008) adds a three-way handshake using TLV 240, so each side knows the other has heard it. FRRouting enables the three-way handshake by default.

Worked example: hold time. In FRRouting the default hello interval is 3 seconds and the default hello multiplier is 10, according to its YANG model. The holding time advertised to the neighbour is the product: 3 x 10 = 30 seconds. If no hello arrives for 30 seconds, the neighbour drops the adjacency. Lowering the interval to 1 second with a multiplier of 3 gives a 3 second hold time, at the cost of three times more hello traffic and more risk of flaps on a busy control plane. Pairing IS-IS with BFD (isis bfd in FRRouting) is the usual way to get fast detection instead.

Hellos may also be padded to the full link MTU. Padding proves that the link can carry a maximum sized LSP before the adjacency comes up, which catches MTU mismatches early. FRRouting pads hellos by default and offers isis hello padding during-adjacency-formation to pad only while the adjacency is forming.

LSPs and the link-state database

Once an adjacency is up, each router describes itself in Link State PDUs. An LSP is identified by an LSP ID, which is the system ID plus a pseudonode byte plus a fragment number, written as 0000.0000.0001.00-00. LSPs carry:

• a sequence number, incremented each time the router regenerates the LSP, so newer information replaces older;
• a remaining lifetime, counting down to zero, after which the LSP is purged;
• a checksum over the contents;
• flags including the attached bit, the overload bit and the router's level.

Every router stores every LSP for its level in a link-state database. All routers in a level must hold the same database for their shortest path calculations to agree.

Worked example: LSP lifetime and refresh. RFC 3719 notes that ISO 10589 sets MaxAge, the starting lifetime of an LSP, as an architectural constant of 20 minutes (1,200 seconds), and recommends that MaxAge exceed the maximum LSP generation interval by at least 5 minutes so an LSP is always refreshed before it expires. FRRouting's defaults match: maximum lifetime 1,200 seconds and refresh interval 900 seconds, a margin of 300 seconds. If you raise the refresh interval to reduce flooding, raise the maximum lifetime too.

Flooding with CSNPs and PSNPs

IS-IS synchronises databases with two kinds of Sequence Number PDU:

• A Complete Sequence Number PDU (CSNP) lists every LSP ID the sender holds with its sequence number, remaining lifetime and checksum. It is a summary of the whole database.
• A Partial Sequence Number PDU (PSNP) lists a few LSP IDs. A router sends a PSNP to acknowledge an LSP on a point-to-point link, or to request LSPs it is missing or holds an older copy of.

On a point-to-point link, each LSP is acknowledged explicitly with a PSNP. On a broadcast LAN, flooding is not acknowledged one by one. Instead the DIS sends CSNPs periodically (FRRouting's default CSNP interval is 10 seconds), and any router that sees an LSP missing or outdated in its own database sends a PSNP to ask for it. If a router holds a newer LSP than the CSNP shows, it floods that LSP.

The Designated Intermediate System and pseudonodes

Without special handling, every router on a LAN would advertise a link to every other router, giving n squared links. RFC 1195 explains the fix it inherits from ISO 10589: one router on the LAN is elected to represent the segment as a pseudonode. Each router then advertises only a link to the pseudonode, and the elected router originates a pseudonode LSP that lists everyone on the LAN.

In IS-IS this elected router is called the Designated Intermediate System. Election is driven by an interface priority from 0 to 127; the IS-IS YANG model in RFC 9130 and FRRouting both use 64 as the default. Three practical points follow:

• Priority is set per level. FRRouting's isis priority takes a level argument, because a LAN runs its Level 1 and Level 2 elections separately and they can pick different routers.
• The DIS sends the CSNPs that keep everyone on the segment in sync, so a DIS that is overloaded or flapping affects the whole LAN.
• The rules are not OSPF's. The election procedure comes from ISO 10589 and differs from OSPF's designated router election. Do not assume OSPF behaviour such as a backup designated router carries over; check your platform's documentation for how it handles a DIS failure or a higher priority router joining.

RFC 8202 adds that when several IS-IS instances share a LAN, a DIS is elected per instance.

When a LAN joins exactly two routers, as most links between routers do, the pseudonode and DIS add work for nothing. RFC 5309 lets both ends treat the LAN as point-to-point. In FRRouting that is isis network point-to-point, and it is the configuration used in the lab.

SPF calculation

With a synchronised database, each router runs Dijkstra's shortest path first algorithm with itself as the root. The result is a tree of shortest paths to every other system in the level and, from the prefixes those systems advertise, a route to every reachable prefix. Equal cost paths produce multipath routes.

SPF is not run on every change. RFC 8405 (June 2018) standardises a back-off algorithm so a burst of changes does not trigger a burst of calculations; FRRouting's spf-interval and lsp-gen-interval set minimum gaps between SPF runs and LSP regeneration.

Levels: Level 1, Level 2 and Level 1/Level 2 routers

The two-level hierarchy

IS-IS has exactly two levels. RFC 1195 describes them directly:

• Level 1 routers route within an area. When a destination is outside the area, they send traffic to the nearest Level 2 router that is attached to the backbone.
• Level 2 routers route between areas, without regard to the internal structure of each area. A Level 2 router may also be a Level 1 router in its own area.

In practice routers come in three types, and FRRouting names them with is-type:

The adjacency rules are simple and worth memorising:

• Two Level 1 routers form a Level 1 adjacency only if they share an area address.
• Two Level 2 routers form a Level 2 adjacency regardless of area address.
• A Level 1/Level 2 router can form both kinds on the same link.

RFC 1195 adds that the Level 2 routers must form a connected backbone. If the Level 2 backbone partitions, IS-IS has no way to repair it through Level 1 links. A Level 1 area can be repaired through Level 2 if the optional partition repair function is implemented.

The attached bit and default routing

A Level 1/Level 2 router that has a path to other areas through Level 2 sets the attached bit in its Level 1 LSP. Level 1 routers in the area install a default route towards the nearest router with the attached bit set. RFC 1195 explains the safety valve: a Level 2 router that loses its backbone connectivity clears the bit, so Level 1 routers stop sending outside traffic to it and use another exit.

FRRouting exposes this with attached-bit send (set the bit on Level 1/Level 2 routers, enabled by default) and attached-bit receive ignore (do not install a default route when the bit is seen).

Route leaking and the up/down bit

By default, Level 1/Level 2 routers advertise Level 1 prefixes upward into Level 2, so every area is reachable across the backbone. Prefixes do not flow down: a Level 1 router knows only its own area plus a default route. That keeps Level 1 databases small but can produce suboptimal exits when an area has several Level 1/Level 2 routers.

RFC 5302 (October 2008) defines domain-wide prefix distribution. A Level 1/Level 2 router may leak selected Level 2 prefixes down into Level 1, marking them with the up/down bit. The bit prevents a loop: a prefix that has been leaked down must not be advertised back up into Level 2 by another border router. RFC 5305 carries the same up/down bit in the extended IP reachability TLV, and RFC 7775 (February 2016) clarifies route preferences for extended reachability TLVs and how the up/down bit affects preference.

How IS-IS levels compare with OSPF areas

The concepts line up loosely, but the boundaries are drawn differently.

In short, an IS-IS Level 1 area behaves much like an OSPF totally stubby area by default, and route leaking moves it towards a normal OSPF area.

TLVs: why IS-IS is so extensible

The TLV format

Almost everything inside an IS-IS PDU after the fixed header is a TLV: one octet of type, one octet of length and up to 255 octets of value. A receiver that sees a type it does not understand skips the length and moves on, and it still floods the LSP unchanged to its neighbours. That is why new features can be deployed router by router.

Many newer TLVs nest sub-TLVs with the same layout. Space is still finite: 256 top level code points and 255 octets per TLV, and RFC 5305 notes there is no defined way to extend the sub-TLV space of TLV 22.

The TLVs you will see most

The table below lists common TLVs with their numbers as recorded in the IANA registry.

Wide metrics and traffic engineering (RFC 5305)

The original IS reachability TLV gave each link a default metric of one octet, with one bit for internal or external, one bit later used as the up/down bit and 6 bits for the value. RFC 5305 calls the resulting range of 0 to 63 "one of the restrictions that we would like to lift". It also notes that each original entry spent 4 octets on metrics, and that three of them (delay, monetary cost and reliability) were rarely implemented.

RFC 5305 (October 2008) defines two replacements:

• TLV 22, Extended IS Reachability. Seven octets of neighbour ID, a 3 octet (24 bit) metric and up to 244 octets of sub-TLVs per neighbour. The sub-TLVs carry traffic engineering data: administrative group (sub-TLV 3), IPv4 interface and neighbour address (6 and 8), maximum link bandwidth (9), maximum reservable bandwidth (10), unreserved bandwidth per priority (11) and a separate TE default metric (18).
• TLV 135, Extended IP Reachability. A 4 octet (32 bit) metric, an up/down bit, a bit that says sub-TLVs follow and a 6 bit prefix length.

RFC 5305 also defines MAX_PATH_METRIC as 0xFE000000, which is 4,261,412,864 (2 to the 32 minus 2 to the 25), so that adding one more 24 bit link metric to a path never overflows a 32 bit counter. A prefix advertised with a metric above that value must not be used. FRRouting's documentation adds that a link advertised with the maximum 24 bit metric, 16,777,215, is still advertised but ignored in SPF, as RFC 5305 requires.

Worked example: why 6 bits is not enough. Suppose you set link costs by bandwidth with a reference of 100,000 Gb/s (100 Tb/s), so cost equals 100,000 divided by link speed in Gb/s.

With narrow metrics you would have to compress the whole range into 1 to 63, and a 400 Gb/s and 800 Gb/s link would likely share a value, so SPF could not prefer the faster one. With wide metrics each speed keeps a distinct cost, and even a 30 hop path of 1 Gb/s links (3,000,000) stays far below MAX_PATH_METRIC.

FRRouting uses metric-style wide by default; transition sends both encodings during a migration.

RFC 8919 (October 2020) and its replacement RFC 9479 (October 2023) define application-specific link attributes, so the same link can advertise different attribute values to RSVP-TE, segment routing policy and flexible algorithm instead of overloading the RFC 5305 sub-TLVs.

IPv6 (RFC 5308)

RFC 5308 (October 2008) adds IPv6 with two TLVs and one code point:

• TLV 236, IPv6 Reachability, with a 32 bit metric, an up/down bit, an external bit and optional sub-TLVs, modelled on TLV 135.
• TLV 232, IPv6 Interface Address, which in hellos carries link-local addresses for next hop resolution.
• NLPID 142 (0x8E) for IPv6 in the Protocols Supported TLV.

Without multi-topology, IPv4 and IPv6 share one SPF tree. That works only if every router and link runs both address families. If one link carries only IPv4, the shared tree may send IPv6 traffic down it and drop it.

Multi-topology (RFC 5120)

RFC 5120 (February 2008) lets one IS-IS instance compute separate SPF trees for separate topologies. A router announces which topologies it belongs to in TLV 229 and then advertises neighbours and prefixes per topology in TLVs 222, 235 and 237. Each topology is identified by a 12 bit MT ID. RFC 5120 reserves MT ID 0 for the standard topology, 1 for IPv4 in-band management, 2 for IPv6 routing, 3 and 4 for IPv4 and IPv6 multicast, 5 for IPv6 in-band management, and 3996 to 4095 for development and experimental use.

The common use is MT ID 2, which gives IPv6 its own tree so a partially dual stack network does not black hole IPv6. In FRRouting this is topology ipv6-unicast under router isis.

Segment routing (RFC 8667)

RFC 8667 (December 2019) is how IS-IS distributes segment routing identifiers for SR-MPLS. Highlights:

• A Prefix-SID sub-TLV (type 3) attaches a segment identifier, usually an index into the label block, to a prefix in TLVs 135, 235, 236 and 237.
• Adjacency SID sub-TLVs (types 31 and 32) attach a SID to a specific adjacency on point-to-point and LAN links.
• SR-Capabilities, carried as a sub-TLV of the Router Capability TLV 242, advertises the router's Segment Routing Global Block (SRGB), the label range indexes map into.
• TLV 149, SID/Label Binding, lets a router advertise SIDs on behalf of other prefixes, for example when mapping non segment routing devices.

Worked example: index to label. If a router advertises an SRGB starting at label 16,000 (FRRouting's default lower bound, with an upper bound of 23,999) and a loopback carries Prefix-SID index 100, every router using the same SRGB programs label 16,000 + 100 = 16,100 for that loopback. If a neighbour uses an SRGB starting at 20,000, it expects 20,100 for the same index, which is why each router computes outgoing labels from the next hop's advertised SRGB, not its own.

Segment routing makes the IGP the source of label state for the whole network, which raises the cost of a forged LSP and is one more reason to authenticate.

Why IS-IS runs directly over layer 2

What "no IP" means

ISO 10589 defines IS-IS for the OSI network layer, where routing PDUs are carried directly by the data link, not inside another network layer protocol. RFC 1195 kept that design when it added IP: it says OSI and IP packets are "transmitted directly over the underlying link layer services", with no mutual encapsulation. IS-IS PDUs are not IPv4 or IPv6 packets: they have no IP header, no IP protocol number and no TCP or UDP port. On a LAN they are sent to OSI multicast destinations; RFC 5309 lists AllISs, AllL1ISs and AllL2ISs, defined in ISO 10589, as the addresses used for link layer encapsulation.

Compare the others: OSPFv2 runs directly over IP using IP protocol 89 (RFC 2328), OSPFv3 also uses protocol 89 over IPv6 (RFC 5340), and BGP runs over TCP and listens on port 179 (RFC 4271).

What that means for attack surface

Running beneath IP has three security consequences, and they cut both ways.

1. It is not remotely reachable. An IS-IS packet cannot be routed. An attacker on the internet, or anywhere beyond the directly attached link, cannot send a hello to your router through the network, because there is no IP header to route on. OSPF and BGP need control plane filters and TTL tricks to reach similar safety; IS-IS gets it from the encapsulation.
2. Anyone on the link can talk to it. The flip side is that any device that can put frames on a routing segment can send hellos and try to become a neighbour. RFC 5309 makes the point in its security section: an attacker attached to the LAN can simply pick a correct address.
3. IP filters do not see it. Access lists that match IP packets, host firewalls and many network detection tools look at IP. IS-IS frames pass beside them. Protection has to come from link design, interface configuration and IS-IS's own authentication.

Treat every interface where IS-IS is enabled as a trust boundary, and make it passive if it faces anything other than a router you control.

What an attacker can do with an adjacency

Described conceptually, the risks of an unauthenticated IS-IS link are the risks of any link-state protocol: a rogue neighbour can inject LSPs that advertise prefixes it does not own and pull traffic towards itself, advertise a low metric path and become a transit point, flood large numbers of LSPs to exhaust memory and CPU, or purge legitimate LSPs so routes disappear. Because every router in a level holds the same database, one injected LSP is flooded to the whole level. The defences below exist to make each of those harder.

How IS-IS authentication works

TLV 10 and its authentication types

ISO 10589 defined the Authentication Information TLV, TLV 10, with a one octet authentication type followed by the value. RFC 5304 created an IANA registry for the type codes. The current values:

Cleartext (type 1)

Cleartext stops accidents, such as a lab router joining production, but the password is visible in any captured frame. It is a safety check, not security.

HMAC-MD5 (type 54, RFC 5304)

RFC 5304 (October 2008) replaced the earlier informal MD5 scheme with HMAC-MD5 per RFC 2104. The details matter when you troubleshoot:

• The type is 54 (0x36), the digest is 16 octets and the TLV length field is 17.
• The HMAC is computed over the whole PDU with the authentication value zeroed. For LSPs, the checksum and remaining lifetime fields are also set to zero first, because those change in flight as the LSP ages and is flooded.
• Hellos are authenticated after padding, so the whole padded frame is covered.
• RFC 5304 allows a transition mode that inserts HMAC-MD5 but does not verify it, to help roll authentication out, and allows checking against a set of passwords during key changes.
• Purges get special treatment: a router that purges an LSP must remove the body and include the authentication TLV, and routers must not accept unauthenticated purges or purges that carry any TLV other than authentication.

RFC 5304 is candid about its limits. It says the mechanism "does not prevent replay attacks", and that most replays would be rejected by existing IS-IS mechanisms such as LSP sequence numbers.

Generic cryptographic authentication (type 3, RFC 5310)

RFC 5310 (February 2009) generalises IS-IS authentication. It adds two things.

• Key IDs. A two octet Key ID in each authenticated PDU names the security association: the key and the algorithm. A receiver looks up the Key ID instead of trying every configured key, which RFC 6039 points out also removes a denial of service risk where random digests force a router to try every key during a rollover. Key IDs make planned key rotation straightforward: configure the new key everywhere for acceptance, switch senders, then retire the old key.
• Algorithm choice. The SA can use HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 or HMAC-SHA-512. RFC 5310 uses a padding constant (Apad, the value 0x878FE1F3 repeated) in place of the authentication value while computing the digest.

Worked example: TLV sizes. RFC 5310 gives the TLV length as 23 for HMAC-SHA-1, 31 for HMAC-SHA-224, 35 for HMAC-SHA-256, 51 for HMAC-SHA-384 and 67 for HMAC-SHA-512. That is one octet of type, two of Key ID and the digest: 1 + 2 + 32 = 35 for SHA-256. Adding the two octet TLV header, an HMAC-SHA-256 signature costs 37 octets per PDU, compared with 19 for HMAC-MD5 (2 + 17). In an LSP that FRRouting caps at 1,497 octets by default, moving from MD5 to SHA-256 takes 18 more octets, about 1.2 percent, out of the space available for reachability TLVs. That is rarely significant.

Which key protects which PDU

RFC 5304 and RFC 5310 define three separate keys, and this is where most configuration mistakes happen:

Because LSPs are flooded unchanged across the whole level, every router in an area must share the area key and every Level 2 router must share the domain key. RFC 6039 notes the operational cost: once keys are configured everywhere, changing them becomes much more difficult. Hello keys, by contrast, only need to match on each link, so you can rotate them link by link.

Replay protection and what remains open

LSPs are protected against simple replay by their sequence numbers: an older copy loses to the current one. Hellos and sequence number PDUs have no sequence number. RFC 6039 (October 2010) spells out what that allows: a replayed hello with an empty neighbour list could reset all adjacencies with the original sender, and a replayed old CSNP could trigger a burst of LSP flooding.

RFC 7602 (July 2015) defines the Extended Sequence Number (ESN) TLV, which adds a monotonically increasing sequence number to hellos and SNPs, maintained per PDU type, and is designed to be used together with RFC 5304 or RFC 5310 authentication. Check whether your platform supports it.

IS-IS authentication provides integrity and origin authentication only. RFC 6039 notes there is no provision to encrypt the body of an IS-IS message, so anyone on the link can still read your topology.

Other hardening

Authentication is one layer. The others are configuration choices.

• Passive interfaces. On loopbacks and any interface facing hosts, servers or customers, use isis passive. The prefix is still advertised, but no hellos are sent and no adjacency can form. FRRouting's advertise-passive-only goes further and advertises only passive interface prefixes, keeping transit link addresses out of the database.
• Point-to-point on two-router LANs. isis network point-to-point (RFC 5309) removes DIS election and pseudonode LSPs, so there is no election to win by announcing a high priority.
• Circuit type per interface. Restrict each interface to the level it needs (isis circuit-type level-1 or level-2-only). An interface that only speaks Level 1 cannot be used to inject Level 2 LSPs.
• Overload bit. RFC 3277 describes setting the overload bit so other routers stop using a router for transit while its forwarding state settles, avoiding black holes after a reboot. FRRouting supports set-overload-bit and set-overload-bit on-startup with a duration in seconds, and advertise-high-metrics as a softer alternative. Use it during maintenance and at startup.
• Purge protection. RFC 5304 and RFC 5310 require that purges be authenticated and carry nothing except the authentication TLV. RFC 6232 (May 2011) adds the Purge Originator Identification TLV, so a purge records the system ID of the router that started it; FRRouting enables this with purge-originator. That does not stop a malicious purge by a router that holds the key, but it tells you where to look.
• Logging. log-adjacency-changes and log-pdu-drops in FRRouting make adjacency flaps and authentication failures visible. An authentication failure on a link that has been stable for months is worth an alert.
• Layer 2 hygiene. Keep routing links on dedicated VLANs or point-to-point circuits and disable unused ports.
• BFD. Pair adjacencies with BFD for fast failure detection rather than shrinking hello timers.

Step by step: a two-area IS-IS lab with FRRouting

This lab builds four routers in containers: two in area 49.0001 and two in area 49.0002, joined by a Level 2 backbone link. It then turns on authentication for hellos, Level 1 and Level 2 PDUs, and verifies the database and routes.

A note on the algorithm. The plan for this post was to use HMAC-SHA-256 per RFC 5310. FRRouting's isisd documentation (latest and 10.7) lists only clear and md5 for isis password, area-password and domain-password, and the isisd source on the FRRouting master branch on 24 October 2026 implements only cleartext and HMAC-MD5 validators. So the lab uses HMAC-MD5, the strongest option FRRouting offers. If your production routers implement RFC 5310, use HMAC-SHA-256 with Key IDs there; the key layout (link, area, domain) is the same, and the RFC 9130 YANG model expresses it with key chains as defined in RFC 8177.

Topology

  area 49.0001 (Level 1)          Level 2 backbone          area 49.0002 (Level 1)

   r1 ----------------- r2 ======================= r3 ----------------- r4
   L1        10.0.12.0/24   L1/L2    10.0.23.0/24    L1/L2   10.0.34.0/24    L1
   lo 10.255.0.1           lo 10.255.0.2           lo 10.255.0.3           lo 10.255.0.4

r2 and r3 are Level 1/Level 2 routers in different areas, so the link between them forms only a Level 2 adjacency (Level 1 needs a shared area address). r1 and r4 are Level 1 only.

Step 1: create the lab directory and pull the image

You need Docker with the Compose plugin on a Linux host. FRRouting publishes container images on Quay; at the time of writing 10.7.1 is the latest release.

mkdir -p ~/isis-lab/{r1,r2,r3,r4} && cd ~/isis-lab
docker pull quay.io/frrouting/frr:10.7.1

Step 2: enable isisd on every router

Each router needs a daemons file that starts zebra and isisd, and a vtysh.conf for the integrated configuration.

for r in r1 r2 r3 r4; do
cat > $r/daemons <<'EOF'
zebra=yes
isisd=yes
bgpd=no
ospfd=no
ospf6d=no
bfdd=no
vtysh_enable=yes
zebra_options="  -A 127.0.0.1 -s 90000000"
isisd_options="  -A 127.0.0.1"
EOF
echo "service integrated-vtysh-config" > $r/vtysh.conf
done

Step 3: write the router configurations

Each router gets a loopback, a NET and IS-IS on its links. Links use point-to-point mode (RFC 5309), and loopbacks are passive. Interfaces on r2 and r3 are left at the default circuit type of Level 1/Level 2, which lets IS-IS pick the right adjacency level on each link by area address; that also means the configuration does not depend on which network Docker names eth0 and which eth1.

cat > r1/frr.conf <<'EOF'
frr defaults traditional
hostname r1
log syslog informational
!
interface lo
 ip address 10.255.0.1/32
 ip router isis LAB
 isis passive
!
interface eth0
 ip router isis LAB
 isis network point-to-point
!
router isis LAB
 net 49.0001.0000.0000.0001.00
 is-type level-1
 metric-style wide
 log-adjacency-changes
 log-pdu-drops
!
EOF

cat > r2/frr.conf <<'EOF'
frr defaults traditional
hostname r2
log syslog informational
!
interface lo
 ip address 10.255.0.2/32
 ip router isis LAB
 isis passive
!
interface eth0
 ip router isis LAB
 isis network point-to-point
!
interface eth1
 ip router isis LAB
 isis network point-to-point
!
router isis LAB
 net 49.0001.0000.0000.0002.00
 is-type level-1-2
 metric-style wide
 log-adjacency-changes
 log-pdu-drops
 purge-originator
!
EOF

r3 and r4 mirror r2 and r1 with area 49.0002, system IDs 0000.0000.0003 and 0000.0000.0004, and loopbacks 10.255.0.3 and 10.255.0.4:

sed -e 's/hostname r2/hostname r3/' -e 's/10.255.0.2/10.255.0.3/' \
    -e 's/49.0001.0000.0000.0002.00/49.0002.0000.0000.0003.00/' r2/frr.conf > r3/frr.conf
sed -e 's/hostname r1/hostname r4/' -e 's/10.255.0.1/10.255.0.4/' \
    -e 's/49.0001.0000.0000.0001.00/49.0002.0000.0000.0004.00/' r1/frr.conf > r4/frr.conf
grep -H 'net \|hostname' r*/frr.conf

The last command prints each NET. Check that every system ID is unique before you start anything.

Step 4: describe the topology in Compose

# ~/isis-lab/compose.yaml
name: isis-lab
networks:
  area1:
    ipam: { config: [ { subnet: 10.0.12.0/24 } ] }
  core:
    ipam: { config: [ { subnet: 10.0.23.0/24 } ] }
  area2:
    ipam: { config: [ { subnet: 10.0.34.0/24 } ] }
x-frr: &frr
  image: quay.io/frrouting/frr:10.7.1
  cap_add: [ NET_ADMIN, NET_RAW, SYS_ADMIN ]
  sysctls:
    net.ipv4.ip_forward: 1
services:
  r1:
    <<: *frr
    hostname: r1
    networks: { area1: { ipv4_address: 10.0.12.11 } }
    volumes: [ ./r1:/etc/frr ]
  r2:
    <<: *frr
    hostname: r2
    networks:
      area1: { ipv4_address: 10.0.12.12 }
      core:  { ipv4_address: 10.0.23.12 }
    volumes: [ ./r2:/etc/frr ]
  r3:
    <<: *frr
    hostname: r3
    networks:
      core:  { ipv4_address: 10.0.23.13 }
      area2: { ipv4_address: 10.0.34.13 }
    volumes: [ ./r3:/etc/frr ]
  r4:
    <<: *frr
    hostname: r4
    networks: { area2: { ipv4_address: 10.0.34.14 } }
    volumes: [ ./r4:/etc/frr ]

Step 5: start the lab and check adjacencies

docker compose up -d
docker compose exec r2 ip addr
docker compose exec r2 vtysh -c 'show isis neighbor'
docker compose exec r3 vtysh -c 'show isis neighbor'

On r2 you should see two neighbours: r1 at Level 1 and r3 at Level 2, both in state Up. On r3, r2 at Level 2 and r4 at Level 1. If one is missing, check show isis interface detail and the logs.

Step 6: read the database

docker compose exec r2 vtysh -c 'show isis database'
docker compose exec r2 vtysh -c 'show isis database detail r1.00-00'
docker compose exec r1 vtysh -c 'show isis database'

Things to look for:

• r2 holds a Level 1 database with r1 and r2, and a Level 2 database with r2 and r3. It does not hold r4's Level 1 LSP; that stays in area 2.
• In r1's Level 1 database, r2's LSP has the attached (ATT) flag set, because r2 has a Level 2 path to another area.
• The detail view of r1.00-00 shows the TLVs from earlier in this post: area address, protocols supported, hostname, extended IS reachability with a metric of 10 (FRRouting's default interface metric) and extended IP reachability for the loopback.
• Each LSP shows a sequence number, a checksum and a holdtime counting down from 1,200.

Step 7: check routes and the default route

docker compose exec r1 vtysh -c 'show isis route'
docker compose exec r1 vtysh -c 'show ip route isis'
docker compose exec r2 vtysh -c 'show ip route isis'
docker compose exec r1 ping -c 3 -I 10.255.0.1 10.255.0.4

r1 learns r2's loopback as a Level 1 route and a default route towards r2 from the attached bit, but no specific route to 10.255.0.4. r2 learns everything: Level 1 routes from area 1 and Level 2 routes for area 2. The ping from r1's loopback to r4's loopback still succeeds, because r1 follows the default route to r2, r2 follows its Level 2 route to r3, and r3 delivers into area 2 and back.

Step 8: turn on HMAC-MD5 authentication

Add three sets of keys. In a real network generate long random keys and store them in your secrets system, not in a repository. The values here are placeholders.

On r1 (area 1, Level 1 only):

configure
interface eth0
 isis password md5 LINK-KEY-PLACEHOLDER
router isis LAB
 area-password md5 AREA1-KEY-PLACEHOLDER authenticate snp validate
end
write memory

On r2 (area 1, Level 1/Level 2):

configure
interface eth0
 isis password md5 LINK-KEY-PLACEHOLDER
interface eth1
 isis password md5 LINK-KEY-PLACEHOLDER
router isis LAB
 area-password md5 AREA1-KEY-PLACEHOLDER authenticate snp validate
 domain-password md5 DOMAIN-KEY-PLACEHOLDER authenticate snp validate
end
write memory

r3 mirrors r2 with AREA2-KEY-PLACEHOLDER, and r4 mirrors r1 with the area 2 key. Run each block inside docker compose exec rN vtysh. Note the details:

• isis password covers hellos on that interface. This lab uses one link key on every interface so the configuration does not depend on interface naming; in production use a different key per link so a leaked key affects one link.
• area-password covers Level 1 LSPs, and with authenticate snp validate also signs and checks Level 1 CSNPs and PSNPs. send-only signs SNPs without checking them, which is useful while rolling keys out.
• domain-password does the same for Level 2.
• Configure one side of each link, then the other, and expect the adjacency to drop for up to the hold time (30 seconds at defaults) while keys disagree.

Step 9: verify the authentication

docker compose exec r2 vtysh -c 'show running-config' | grep -E 'password'
docker compose exec r2 vtysh -c 'show isis neighbor'
docker compose exec r2 vtysh -c 'show isis database'

Adjacencies should return to Up and the database should look as before. To prove that the checks bite, change r1's link key to something else, wait 30 seconds and look again: the r1 adjacency on r2 goes Down, and with log-pdu-drops the logs record dropped hellos. Put the key back and it recovers.

You can also watch the TLV on the wire from the host. Find the bridge for the area 1 network and capture IS-IS frames:

BR=br-$(docker network inspect isis-lab_area1 -f '{{.Id}}' | cut -c1-12)
sudo tcpdump -i "$BR" -nn -v isis -c 10

tcpdump decodes IS-IS and shows the authentication TLV with its type (HMAC-MD5) on hellos and LSPs. With cleartext authentication you would see the password itself in this output, which is the clearest argument against using it.

Step 10: practise the overload bit

Set the overload bit on r2 and watch r1's view change:

configure
router isis LAB
 set-overload-bit
end

show isis database on r1 now shows r2's LSP with the overload (OL) flag. Remove it with no set-overload-bit, and tear the lab down with docker compose down. In production, set-overload-bit on-startup 300 keeps a rebooted router out of the transit path for 300 seconds while BGP and other state converge.

Comparison: IS-IS, OSPFv2, OSPFv3 and BGP

Where Safeguard fits

Safeguard does not configure routers, run IS-IS, inspect routing packets or analyse router firmware, and nothing in the lab above depends on it. The fit is with the software around the routing plane: the automation that renders IS-IS configurations, the tools that collect database and adjacency state, and the container images many teams use to run open source routing stacks in labs and on white box hardware. Those are built from open source packages and shipped as images. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), shows which projects carry a given component and version, matches them against vulnerability data and applies policies and gates. That tells you which automation repositories or lab images still carry a vulnerable library when a fix ships. Router operating systems from vendors are outside that scope, and their fixes still come from those vendors.

Common mistakes

• Duplicate system IDs. Two routers with the same system ID originate LSPs with the same LSP ID and keep overwriting each other, causing constant SPF runs and flapping routes. Generate system IDs from a source of truth and check before deploying.
• Leaving hellos on host facing interfaces. Any interface without isis passive will try to form adjacencies with whatever is on the segment.
• Using cleartext authentication and calling it secure. The password is in every frame.
• Configuring only hello authentication. Hellos protect adjacency formation, but LSPs and SNPs need the area and domain keys, or a trusted neighbour can relay unauthenticated LSPs from elsewhere.
• Validating LSPs but not SNPs. Without SNP authentication, forged CSNPs and PSNPs can trigger floods or requests. Enable SNP validation once all routers sign them.
• Mixing narrow and wide metrics. Routers on different metric styles do not understand each other's reachability TLVs. Use the transition style only during a migration, then move everyone to wide.
• Running IPv6 without multi-topology on a partially dual stack network. A single shared SPF tree can send IPv6 traffic over IPv4 only links.
• Breaking the Level 2 backbone. A Level 2 partition cannot be repaired through Level 1. Design at least two Level 2 paths between every pair of Level 2 regions.
• Forgetting the attached bit when designing exits. Level 1 routers pick the nearest attached router, not the best exit for a given destination. If that matters, leak routes or ignore the attached bit and originate a default deliberately.
• Rotating area or domain keys all at once. Every router in the level must accept the new key before any router sends it. Use a send-only phase or multiple accepted keys.

FAQ

What is IS-IS in networking?

IS-IS, Intermediate System to Intermediate System, is a link-state interior gateway protocol. Each router floods LSPs describing its links and prefixes, all routers in a level build the same database, and each runs Dijkstra's shortest path first algorithm to compute routes. It is defined in ISO/IEC 10589 and extended for IP by RFC 1195.

Is IS-IS better than OSPF?

Neither is better in general. IS-IS carries IPv4 and IPv6 in one instance, extends through TLVs and runs beneath IP. OSPF is more familiar to many enterprise engineers and has richer area types. Pick the one your team can operate well.

Does IS-IS use IP or TCP?

No. IS-IS packets are carried directly in data link frames, without an IP header or a TCP or UDP port. OSPF uses IP protocol 89 and BGP uses TCP port 179.

What is the difference between Level 1 and Level 2 in IS-IS?

Level 1 routers route within one area and send everything else to the nearest attached Level 1/Level 2 router. Level 2 routers route between areas and form the backbone. A Level 1/Level 2 router does both and connects an area to the backbone.

What is a NET in IS-IS?

A Network Entity Title is the router's OSI address with a selector of 00, such as 49.0001.0000.0000.0001.00. It contains the area address, a 6 octet system ID that must be unique in the domain, and the selector.

What is a DIS in IS-IS?

The Designated Intermediate System is the router elected on a broadcast LAN to represent the segment as a pseudonode and to send CSNPs. Election uses an interface priority from 0 to 127 (default 64 in the RFC 9130 YANG model), and Level 1 and Level 2 elect separately. On links with only two routers, point-to-point mode (RFC 5309) removes the election altogether.

How does IS-IS authentication work?

Authentication is carried in TLV 10. Cleartext (type 1) sends the password itself. HMAC-MD5 (type 54, RFC 5304) and generic cryptographic authentication with HMAC-SHA and Key IDs (type 3, RFC 5310) sign each PDU. Hellos use a per-link key, Level 1 LSPs and SNPs use the area key and Level 2 LSPs and SNPs use the domain key.

Does FRRouting support HMAC-SHA-256 for IS-IS?

Not as of 24 October 2026. FRRouting's isisd documentation and its master branch source support cleartext and HMAC-MD5 for hellos, area and domain authentication. Check the release notes of the version you run; FRRouting's OSPF and BFD daemons have their own, separate authentication options.

Fix it without waiting for upstream

IS-IS itself is a protocol, but the systems that configure, test and observe it are ordinary software: configuration generators, telemetry collectors and the container images that package open source routing stacks such as the one in the lab above are all built from open source dependencies. When one of those dependencies has a vulnerability, the fix path is the same as for any other code you build, so the habits below apply to network automation as much as to product code.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session with the Safeguard CLI. The assistant reads a finding and its advisory, asks before each command, upgrades a dependency, runs the tests and pushes nothing. The same flow applies when a library inside your IS-IS configuration generator or topology collector needs an upgrade.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. Network automation repositories and lab images, like the FRRouting containers above, often live on internal hosts, and the runner lets you scan them from a machine you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Granting a narrow set of tools is the same habit as making every non-router interface passive in IS-IS: allow only what each party needs.

Click through it at your own pace, or open it full screen.

Download the apps at safeguard.sh/download and read the CLI docs at docs.safeguard.sh/docs/cli.

Quick check

Sources

• RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (December 1990)
• RFC 1142: OSI IS-IS Intra-domain Routing Protocol (February 1990, Historic)
• RFC 7142: Reclassification of RFC 1142 to Historic (February 2014)
• RFC 3277: IS-IS Transient Blackhole Avoidance (April 2002)
• RFC 3719: Recommendations for Interoperable Networks using IS-IS (February 2004)
• RFC 5120: M-ISIS: Multi Topology Routing in IS-IS (February 2008)
• RFC 5301: Dynamic Hostname Exchange Mechanism for IS-IS (October 2008)
• RFC 5302: Domain-Wide Prefix Distribution with Two-Level IS-IS (October 2008)
• RFC 5303: Three-Way Handshake for IS-IS Point-to-Point Adjacencies (October 2008)
• RFC 5304: IS-IS Cryptographic Authentication (October 2008)
• RFC 5305: IS-IS Extensions for Traffic Engineering (October 2008)
• RFC 5306: Restart Signaling for IS-IS (October 2008)
• RFC 5308: Routing IPv6 with IS-IS (October 2008)
• RFC 5309: Point-to-Point Operation over LAN in Link State Routing Protocols (October 2008)
• RFC 5310: IS-IS Generic Cryptographic Authentication (February 2009)
• RFC 5311: Simplified Extension of LSP Space for IS-IS (February 2009)
• RFC 6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (October 2010)
• RFC 6232: Purge Originator Identification TLV for IS-IS (May 2011)
• RFC 7602: IS-IS Extended Sequence Number TLV (July 2015)
• RFC 7775: IS-IS Route Preference for Extended IP and IPv6 Reachability (February 2016)
• RFC 7981: IS-IS Extensions for Advertising Router Information (October 2016)
• RFC 8202: IS-IS Multi-Instance (June 2017)
• RFC 8177: YANG Data Model for Key Chains (June 2017)
• RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs (June 2018)
• RFC 8667: IS-IS Extensions for Segment Routing (December 2019)
• RFC 8919: IS-IS Application-Specific Link Attributes (October 2020, obsoleted)
• RFC 9479: IS-IS Application-Specific Link Attributes (October 2023)
• RFC 9130: YANG Data Model for the IS-IS Protocol (October 2022)
• RFC 9667: Dynamic Flooding on Dense Graphs (October 2024)
• RFC 7938: Use of BGP for Routing in Large-Scale Data Centers (August 2016)
• RFC 2328: OSPF Version 2 (April 1998)
• RFC 5340: OSPF for IPv6 (July 2008)
• RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication (October 2009)
• RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management (April 2015)
• RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement (November 2015)
• RFC 4552: Authentication/Confidentiality for OSPFv3 (June 2006)
• RFC 7166: Supporting Authentication Trailer for OSPFv3 (March 2014)
• RFC 8362: OSPFv3 Link State Advertisement (LSA) Extensibility (April 2018)
• RFC 4271: A Border Gateway Protocol 4 (BGP-4) (January 2006)
• RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option (August 1998)
• RFC 5925: The TCP Authentication Option (June 2010)
• IANA: IS-IS TLV Codepoints registry
• IETF Link State Routing (LSR) working group
• FRRouting documentation: IS-IS (latest)
• FRRouting documentation: IS-IS (stable 10.7)
• FRRouting isisd CLI source (master)
• FRRouting isisd TLV source (master)
• FRRouting isisd YANG model (master)
• FRRouting releases on GitHub
• FRRouting container images on Quay

Related reading: OSPF explained, BGP explained, How to get an ASN and announce your own IP prefix and IPv4 vs IPv6 explained.

Last reviewed: 24 October 2026. IS-IS extensions continue in the IETF LSR working group, and router implementations differ in which authentication types they support; check the RFC Editor, the IANA registry and your platform's documentation before relying on a specific behaviour.