35 years of IS-IS, and vendors still disagree on two bits¶

IS-IS has carried IP since RFC 1195, in December 1990. If any routing protocol should behave the same on every router, it is this one. Yet when one LSP carries both the attached bit and the overload bit, Nokia SR OS, Juniper Junos and FRR do not install the same routes.

This matters the day you drain a router. You set the overload bit, you wait, and the traffic moves away. On a network with several vendors, it does not always happen that way: depending on the vendor of the access router, the traffic keeps using the router you just drained, or the access router loses its default route. Both behaviors can claim the standards: read literally, the base standard keeps the default route, and the drain use of the overload bit expects the opposite. No text covers the two bits together.

This post shows the difference on a small lab, looks at what the standards say, explains what it means for a multi-vendor network, and ends with the commands to get the behavior you want.

A protocol older than most of our networks¶

The documents behind the two bits of this post:

Every feature used in this post is at least eighteen years old, and documented in public standards. The difference is not in the features: it is in how they combine.

The two bits¶

IS-IS routers exchange link-state packets (LSPs). Two flags of the LSP header matter here.

The attached bit (ATT). In a multi-area IS-IS network, an L1/L2 router that reaches another area sets ATT in its level 1 LSP. An L1-only router has no route outside its area, so it installs a default route toward the closest router that advertises ATT. RFC 1195, section 1.2: level 1 routers "route traffic to destinations outside of their area only to level 2 routers which indicate in their level 1 LSPs that they are 'attached'".

The overload bit (OL). ISO 10589 defines it for a router whose link-state database is overloaded. RFC 3787, section 4: "Section 7.2.8.1 of ISO 10589 instructs other systems not to use the overloaded IS as a transit router." Operators also set it on purpose, to drain a router before maintenance or to keep it out of the paths while BGP converges after a reboot (RFC 3277).

Each bit has a clear meaning. The question is what an L1 router must do when one LSP carries both: "send your traffic for the outside to me" and "do not send me transit traffic".

The lab¶

Five nodes in containerlab. border is the L1/L2 router that sends both bits. l2core gives it an L2 adjacency in another area, which is what makes border set ATT. The three L1 routers have no other way out: if they have a default route, it comes from the ATT bit of border.

flowchart LR
  l2core["<b>l2core</b><br/>FRR<br/>L2 only, area 49.0003"]
  border["<b>border</b><br/>Nokia SR OS<br/>L1/L2, area 49.0002<br/>sends ATT + OL"]
  l1nokia["<b>l1nokia</b><br/>Nokia SR OS<br/>L1"]
  l1junos["<b>l1junos</b><br/>Juniper Junos<br/>L1"]
  l1frr["<b>l1frr</b><br/>FRR<br/>L1"]

  l2core ---|L2| border
  border ---|L1| l1nokia
  border ---|L1| l1junos
  border ---|L1| l1frr

  classDef sender fill:#fde7c8,stroke:#c77700,color:#000
  classDef receiver fill:#dbeafe,stroke:#2563eb,color:#000
  classDef other fill:#e5e7eb,stroke:#6b7280,color:#000
  class border sender
  class l1nokia,l1junos,l1frr receiver
  class l2core other

The whole lab (topology, startup configurations and the commands below) is on GitHub: labs/isis_interop.

Step 1: ATT only¶

After deploy, border has no overload. Its L1 LSP carries ATT, and the three L1 routers install a default route toward it:

border# show router isis database
border.00-00          0xf       0x9215   1141     L1L2 ATT

l1nokia# show router route-table 0.0.0.0/0
0.0.0.0/0                  Remote  ISIS      00h14m48s  15
       10.0.1.1                                          10

l1junos> show route 0.0.0.0/0 exact table inet.0
0.0.0.0/0          *[IS-IS/15] 00:14:53, metric 10
                    >  to 10.0.2.1 via ge-0/0/0.0

l1frr# show ip route 0.0.0.0/0
Routing entry for 0.0.0.0/0
  Known via "isis", distance 115, metric 10, best
  * 10.0.3.1, via eth1, weight 1

Three vendors, one behavior.

Step 2: ATT + OL¶

Now border sets the overload bit:

configure private
/configure router "Base" isis 0 overload
commit

Its LSP carries both bits, and the three L1 routers see them:

border# show router isis database
border.00-00          0x10      0x940e   1168     L1L2 ATT
                                                    OV

l1junos> show isis database
border.00-00              0x10   0x940e     1153 L1 L2 Overload Attached

l1frr# show isis database
border.00-00              177   0x00000010  0x940e    1154    1/0/1

Same LSP, same flags (on FRR, 1/0/1 is the ATT/P/OL column). Not the same routing tables:

l1nokia# show router route-table 0.0.0.0/0
No. of Routes: 0

l1junos> show route 0.0.0.0/0 exact table inet.0
0.0.0.0/0          *[IS-IS/15] 00:15:43, metric 10
                    >  to 10.0.2.1 via ge-0/0/0.0

l1frr# show ip route 0.0.0.0/0
Routing entry for 0.0.0.0/0
  Known via "isis", distance 115, metric 10, best
  * 10.0.3.1, via eth1, weight 1

Nokia removes the default route. Junos and FRR keep it, and keep sending their traffic for the outside to the router that asked not to receive transit traffic.

flowchart TD
  lsp["LSP of border<br/>ATT = 1, OL = 1"] --> nokia["l1nokia<br/>SR OS"]
  lsp --> junos["l1junos<br/>Junos"]
  lsp --> frr["l1frr<br/>FRR"]
  nokia --> n_res["no default route"]
  junos --> j_res["default route via border"]
  frr --> f_res["default route via border"]

  classDef drop fill:#e5e7eb,stroke:#6b7280,color:#000
  classDef keep fill:#dbeafe,stroke:#2563eb,color:#000
  class n_res drop
  class j_res,f_res keep

Where exactly the implementations disagree¶

Junos does not ignore the overload bit. On l1junos, the IS-IS routes with and without the overload bit on border:

The routes that cross border to reach another router are gone. The routes to border itself and to its attached subnets stay. This is what RFC 3787 section 4 describes: no transit through an overloaded router, but an overloaded router "may be used to reach End Systems directly attached to the router".

The default route is where the two readings split. It points to the nearest L1/L2 router that sets ATT, and its metric (10 here) is the SPF distance to that router. Junos and FRR keep border as the target of the default route: border itself is still reachable, so the default route stays. But the traffic that follows the default route does not stop at border: it crosses it toward the other area, which is transit. Nokia behaves as if an overloaded router cannot be a target of the default route at all. Both readings can be defended: the next section shows that the base standard, read literally, supports the first one, and that the drain use of the bit supports the second.

RFC 3787 leans toward Junos and FRR: the receiver "SHOULD treat all IP reachability advertisements as directly connected", and the overloaded router "SHOULD take care in selecting which routes to advertise". Read this way, the receiver trusts the LSP, and the sender must not advertise what it cannot serve. This is what Junos does as a sender: it clears ATT in overload. But ATT is a header flag, not an IP reachability advertisement, so the text does not settle it. An explicit 0.0.0.0/0 in the LSP would fall under the rule; the default route derived from ATT does not.

What the standards say¶

No paragraph of ISO/IEC 10589, RFC 1195, RFC 3277, RFC 3784, RFC 3787 or RFC 5305 mentions the overload bit and the attached bit together.

Read literally, ISO/IEC 10589 decides the case: nothing in 7.2.9 removes an overloaded router from the attached routers, and nothing in 7.2.9.2 tells it to clear ATT. That fits the original purpose of the bit: it reports an incomplete database, level by level, and in an L1 LSP it says nothing about the level 2 database that forwards the traffic for the outside. The drain use came later: RFC 3787, section 4, notes that "the meaning of this flag has been overloaded". For a drain, the Nokia receiver and the Junos sender are the behaviors that empty the router.

The vendor documentation covers only the sender. The Junos overload page says: "An L1-L2 router in overload mode stops leaking route information between L1 and L2 levels and clears its attached bit." So Junos never sends the combination of this post. SR OS keeps ATT with the plain overload bit. I found no Nokia page on the combination.

So the standards do not settle the case that operators care about. A standard describes the messages and each feature in isolation. When a feature gets a new use, what happens when it meets another feature is often left open, and every vendor closes the gap in its own way, even after thirty-five years.

What it means for a multi-vendor network¶

The real question for an operator is: "when I drain this router, where does the traffic go?" The answer depends on two vendors, not one.

The receiver decides what to do with ATT + OL. In production, an L1 router usually has two L1/L2 routers to reach the outside, not one. When the closest one is drained with the overload bit:

• A Nokia L1 router stops using it and moves its default route to the other L1/L2 router.
• A Junos or FRR L1 router keeps the drained router as the target of its default route, because it is still the closest router with ATT. The traffic for the outside keeps crossing the router you wanted to empty.

The sender decides which bits are in the LSP. Setting the overload bit does not produce the same LSP on every vendor:

So setting the overload bit can fully drain the router, partially drain it, or leave inter-area traffic on it, depending on the pair of vendors. A procedure validated on one vendor pair says nothing about the others.

Draining with metrics instead of the overload bit¶

The overload bit is not the only way to drain a router. RFC 3277, section 4 (Potential Alternatives), describes another one: advertise the links of the router with a very high metric, so that the other routers choose another path whenever one exists.

The advantage of a metric-based mechanism over the Overload bit mechanism model proposed here is that transit paths may still be calculated through the router.

The vendors implement it with their own command: overload max-metric true on SR OS, overload advertise-high-metrics on Junos, advertise-high-metrics on FRR. The LSP of border then has no overload bit, and its IS-IS neighbors are advertised with the metric 16777214:

l1junos> show isis database border.00-00 extensive
   IS neighbor: l1nokia.00                    Metric: 16777214
   IS neighbor: l1junos.00                    Metric: 16777214
   IS neighbor: l1frr.00                      Metric: 16777214
   IP prefix: 10.0.1.0/30                     Metric:       10 Internal Up
   IP prefix: 10.0.2.0/30                     Metric:       10 Internal Up
   IP prefix: 10.0.3.0/30                     Metric:       10 Internal Up
   IP prefix: 10.255.0.2/32                   Metric:        0 Internal Up

The value is the largest one that still counts. RFC 5305, section 3, says that the metric of this TLV is "a 24-bit unsigned integer", and that "If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation." 16777214 is 2^24 - 2: the link stays in the SPF, at a huge cost. The prefix metrics do not change: a prefix is a destination attached to border, not a link to cross, so the traffic toward it is not transit. And Junos shows the LSP with Attributes: 0x3 <L1 L2>: no overload, no attached bit.

SR OS also clears the attached bit in this mode, and max-metric needs it. In IS-IS, each router advertises the metric of its own outgoing links: RFC 5305, section 3, describes the IS reachability TLV as "a series of IS neighbors", each with "the default metric". The SPF adds only the costs in the direction of the traffic. So max-metric raises the cost of leaving border, not of reaching it: whatever the vendor, l1junos still reaches border at 10, the metric that l1junos advertises.

The default route points to the closest router with ATT, at that distance. If border kept ATT, the default route would stay on it at metric 10, and the traffic for the outside would keep crossing it. Clearing ATT is what moves that traffic.

With an SR OS sender, max-metric is therefore the drain that gives the same result on Nokia, Junos and FRR access routers.

You will not see overload. In max-metric mode, the database (show router isis database on SR OS, show isis database on Junos) shows no overload flag (OV on SR OS, the full word Overload on Junos), so the drained router looks like a normal one. On SR OS, show router isis status shows Overload Max-Metric : True and L1 LSDB Overload : Manual (Indefinitely in overload). On the other routers, the only trace is the metric 16777214 in the LSP. If you drain with max-metric, do not look for the overload flag to check it: look for the metric.

How to control it¶

These commands worked on the lab. On the sender, you decide what the drained router advertises. On the receiver, you decide what each access router does with the attached bit, whatever the sender does.

configure private
/configure router "Base" isis 0 suppress-attached-bit true
commit

configure private
/configure router "Base" isis 0 delete overload
/configure router "Base" isis 0 overload max-metric true
commit

configure
set protocols isis ignore-attached-bit
commit

configure terminal
router isis LAB
 attached-bit receive ignore
end

configure private
/configure router "Base" isis 0 ignore-attached-bit true
commit

The receiver knobs ignore ATT from every neighbor, not only overloaded ones. Use them only if the access router has another exit, such as a static default. Fixing the sender is simpler.

Lessons¶

1. Old does not mean settled. A protocol can be thirty-five years old, every feature well specified, and the combination of two features still unclear once one of them is used for something new.
2. The result depends on a pair of vendors. The sender decides which bits are in the LSP, the receiver decides what to do with them. Validate a drain procedure for every pair you run.
3. Know the knobs. suppress-attached-bit, ignore-attached-bit, attached-bit receive ignore and the max-metric modes exist because the default behavior is not always the one you need.
4. A lab costs less than an incident. The whole experiment fits in five containers and takes minutes to run.

The lab is here: labs/isis_interop. If you run it on other releases or other vendors, I would like to know what you see.