IS-IS Route Leaking and the Up/Down Bit

IS-IS Route Leaking and the Up/Down Bit

An IS-IS Level 1 area carries no routes to the outside. Outbound packets go to the nearest exit, and what happens beyond it is the exit router’s business. The ATT bit that arranges this is simple, but a Level 1 router knows only which exit is closest; it cannot tell whether the destination is near that exit or far from it.

Route leaking fills that gap. Push routes learned at Level 2 down into Level 1 LSPs, and Level 1 routers can choose an exit by distance to the destination. A leaked route travelling back up into Level 2 would loop, though, so its direction is recorded in a single bit: the up/down bit.

This article works through where that bit sits, who sets it and when, and what it forbids, checking each against the RFCs and against IOS XR. The ATT bit itself is covered in The IS-IS ATT Bit and the Level 1 Default Route.

Why leak at all

RFC 5302 sums up exit selection by ATT bit:

In using the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation that the L1 router performs is similarly suboptimal.

A default route carries no per-destination distance. Exit A may be closer, but if the destination sits next door to exit B, going through B is faster. A Level 1 router has nothing to decide that with.

Route leaking therefore advertises the Level 2 routes themselves into Level 1. With the prefix and its metric in hand, a Level 1 router picks an exit with an ordinary SPF computation.

Note that route leaking is not in ISO/IEC 10589:2002. It is an IETF extension added later to the TLVs that RFC 1195 defined for carrying IP routes.

Where the up/down bit sits

The position depends on the TLV.

TLV 135’s control byte packs three things into one octet.

In the narrow TLV 128, bit 8 of the default metric was originally reserved (bit 7 is the I/E flag for internal or external, and bits 1 to 6 carry the value). RFC 5302 redefined it as the up/down bit. The structure of the TLVs is covered in The Main IS-IS TLVs.

What 0 and 1 mean

RFC 5305 settles how the value is chosen.

The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g., level 2 to level 1), the bit MUST be set to 1.

So 1 means “this came down from above”, and 0 means “this originated at this level”.

The same RFC requires 1 when a prefix is advertised from one area to another at the same level. The level may be unchanged, but crossing an area boundary still makes it a route from elsewhere.

RFC 5302 says who sets it:

L1L2 routers MUST set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit MUST be set to zero for all other IP prefixes in L1 or L2 LSPs.

RFC 7794 defines a separate R flag in another sub-TLV attached to the prefix (Prefix Attribute Flags). It is “set when the prefix has been leaked from one level to another (upwards or downwards)” — unlike the up/down bit, it does not record the direction.

The rule that prevents loops

The point of the bit is loop prevention, and this clause of RFC 5302 is the heart of it:

Prefixes with the up/down bit set that are learned via L1 routing MUST NOT be advertised by L1L2 routers back into L2.

If a route pushed down from Level 2 were pushed back up by another L1L2 router, it would circulate. A route that came down carries a mark, so an L1L2 router can see that this one must not go back up.

RFC 5305 states the same thing from the other side:

Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels.

Older implementations

A Level 1 implementation that does not know about the up/down bit takes a leaked route in as an intra-area route. RFC 5302 addresses this:

that in itself does not cause routing loops among L1-only routers.

The loop is stopped on the L1L2 side. A Level-1-only router never re-advertises the route, so failing to read the mark causes no circulation.

How much to leak

Leaking is not free. RFC 5302 puts it plainly:

It will increase the number of prefixes throughout the domain. This will result in increased memory consumption, transmission requirements, and computation requirements throughout the domain.

However, it is a compromise and does not provide the maximum scalability available with IS-IS. Domains that choose to make use of this facility should be aware of the tradeoff that they are making between scalability and optimality, and provision and monitor their networks accordingly.

The point of a Level 1 area is that its database stays small because it holds nothing from outside. Leaking spends some of that to buy optimality, so the RFC asks for only what is needed to come down, and for nothing to come down by default.

Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs.

It is also RECOMMENDED that the default configuration of L1L2 routers not advertise any L2 routes into L1. […] Implementations SHOULD force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1.

IOS XR requiring a route policy on propagate level 2 into level 1 follows exactly that.

Verification on real devices

Test environment

R1, R2 and R3 sit in area 49.0001, with R1 alone as level-1. R2 and R3 are level-1-2 and reach R4, a level-2-only router in area 49.0002. R4 carries Loopback1 (172.16.4.1/32), which is what gets leaked.

The metric style is wide (TLV 135). The bit means the same thing in the narrow TLV 128, but it is easier to observe in wide, where it lives in a control byte of its own.

The STEPs

I also intended to force and ignore the ATT bit, but IOS XR 26.1.1 (XRd) has no command corresponding to attached-bit (both attached-bit and set-attached-bit return % Invalid input detected). How the ATT bit is set depends on the level configuration and the shape of the areas.

STEP 0: the only way out is the default route

R1’s routing table:

RP/0/RP0/CPU0:R1#show route isis
Fri Sep 11 12:29:53.589 UTC

i*L1 0.0.0.0/0 [115/10] via 10.1.2.2, 00:13:00, GigabitEthernet0/0/0/0
i L1 2.2.2.2/32 [115/10] via 10.1.2.2, 00:14:42, GigabitEthernet0/0/0/0
i L1 3.3.3.3/32 [115/20] via 10.1.3.3, 00:13:36, GigabitEthernet0/0/0/1
i L1 10.2.4.0/24 [115/20] via 10.1.2.2, 00:14:42, GigabitEthernet0/0/0/0
i L1 10.3.4.0/24 [115/30] via 10.1.3.3, 00:13:36, GigabitEthernet0/0/0/1

The single outbound route is i*L1 0.0.0.0/0, and 172.16.4.1/32 is nowhere to be seen. R2 and R3 both set the ATT bit, and R1 picked R2 because its metric is lower (10).

STEP 1: configure leaking on R2

R2 gets a route policy matching only 172.16.4.1/32, applied with propagate level 2 into level 1. On IOS XR the route policy is mandatory on that command; without it you get % Incomplete command.

RP/0/RP0/CPU0:R2#show rpl route-policy LEAK-L2-TO-L1
Fri Sep 11 12:33:09.993 UTC
route-policy LEAK-L2-TO-L1
  if destination in (172.16.4.1/32) then
    pass
  endif
end-policy
!

R1’s Level 1 database:

RP/0/RP0/CPU0:R1#show isis database detail
Fri Sep 11 12:32:53.923 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL
R1.00-00            * 0x00000007   0x2165        909  /*            0/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     1.1.1.1
  Hostname:       R1
  Metric: 10         IS-Extended R2.00
  Metric: 20         IS-Extended R3.00
  Metric: 0          IP-Extended 1.1.1.1/32
  Metric: 10         IP-Extended 10.1.2.0/24
  Metric: 20         IP-Extended 10.1.3.0/24
R2.00-00              0x00000008   0x4796        1107 /1200         1/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     2.2.2.2
  Hostname:       R2
  Metric: 10         IS-Extended R1.00
  Metric: 0          IP-Extended 2.2.2.2/32
  Metric: 10         IP-Extended 10.1.2.0/24
  Metric: 10         IP-Extended 10.2.4.0/24
  Metric: 10         IP-Extended-Interarea 172.16.4.1/32
R3.00-00              0x00000006   0x764a        1126 /1200         1/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     3.3.3.3
  Hostname:       R3
  Metric: 20         IS-Extended R1.00
  Metric: 0          IP-Extended 3.3.3.3/32
  Metric: 20         IP-Extended 10.1.3.0/24
  Metric: 10         IP-Extended 10.3.4.0/24

 Total Level-1 LSP count: 3     Local Level-1 LSP count: 1

The last line of R2’s LSP reads IP-Extended-Interarea 172.16.4.1/32. Every other prefix is plain IP-Extended, and that one word is how IOS XR shows that the up/down bit is 1. R3, not yet configured, does not carry the prefix at all.

In R1’s routing table the type becomes inter-area.

RP/0/RP0/CPU0:R1#show route 172.16.4.1
Fri Sep 11 12:32:53.034 UTC

Routing entry for 172.16.4.1/32
  Known via "isis 1", distance 115, metric 20, type inter-area
  Installed Sep 11 12:31:21.175 for 00:01:31
  Routing Descriptor Blocks
    10.1.2.2, from 2.2.2.2, via GigabitEthernet0/0/0/0
      Route metric is 20
  No advertising protos. 

Nothing was configured on R1, the receiving side. Leaking is the job of the routers that hold both levels; a Level 1 router simply feeds what arrives into its ordinary computation. R1’s _run.txt is byte for byte the same in every STEP.

At the router that injected it, the bit stays 0

The same prefix at Level 2, in R4’s database:

RP/0/RP0/CPU0:R4#show isis database detail
Fri Sep 11 12:36:03.318 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL
R2.00-00              0x00000008   0x6f8f        796  /1200         0/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     2.2.2.2
  Hostname:       R2
  Metric: 10         IS-Extended R4.00
  Metric: 10         IP-Extended 1.1.1.1/32
  Metric: 0          IP-Extended 2.2.2.2/32
  Metric: 30         IP-Extended 3.3.3.3/32
  Metric: 10         IP-Extended 10.1.2.0/24
  Metric: 30         IP-Extended 10.1.3.0/24
  Metric: 10         IP-Extended 10.2.4.0/24
  Metric: 40         IP-Extended 10.3.4.0/24
R3.00-00              0x00000007   0xa321        915  /1200         0/0/0
  Area Address:   49.0001
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     3.3.3.3
  Hostname:       R3
  Metric: 10         IS-Extended R4.00
  Metric: 20         IP-Extended 1.1.1.1/32
  Metric: 30         IP-Extended 2.2.2.2/32
  Metric: 0          IP-Extended 3.3.3.3/32
  Metric: 30         IP-Extended 10.1.2.0/24
  Metric: 20         IP-Extended 10.1.3.0/24
  Metric: 40         IP-Extended 10.2.4.0/24
  Metric: 10         IP-Extended 10.3.4.0/24
R4.00-00            * 0x00000006   0x02b7        857  /*            0/0/0
  Area Address:   49.0002
  LSP MTU:        1492
  NLPID:          0xcc
  IP Address:     4.4.4.4
  Hostname:       R4
  Metric: 10         IS-Extended R2.00
  Metric: 10         IS-Extended R3.00
  Metric: 0          IP-Extended 4.4.4.4/32
  Metric: 10         IP-Extended 10.2.4.0/24
  Metric: 10         IP-Extended 10.3.4.0/24
  Metric: 0          IP-Extended 172.16.4.1/32

 Total Level-2 LSP count: 3     Local Level-2 LSP count: 1

172.16.4.1/32 in R4’s own LSP (R4.00-00) is plain IP-Extended, so the bit is 0. The router that first injected the prefix advertises it with 0, and R2 and R3 change it to 1 when they push it down into Level 1.

There is not a single IP-Extended-Interarea line in this database: R2 and R3 do not put the routes they leaked into Level 1 back into their Level 2 LSPs.

The same thing in a packet

No.33 of the R1 - R2 capture is the Level 1 LSP that R2 sent right after the leak was configured. tshark splits the control byte into its three parts.

        Ext. IP Reachability: 10.2.4.0/24
            Metric: 10
            0... .... = Distribution: Up
            .1.. .... = Sub-TLV: Yes
            ..01 1000 = Prefix Length: 24
            IPv4 prefix: 10.2.4.0
            SubCLV Length: 3
            subTLV: Prefix Attribute Flags (c=4, l=1): Flags:---
                Code: Prefix Attribute Flags (4)
                Length: 1
                Flags: 0x00
                    0... .... = External Prefix: Not set
                    .0.. .... = Re-advertisement: Not set
                    ..0. .... = Node: Not set
        Ext. IP Reachability: 172.16.4.1/32
            Metric: 10
            1... .... = Distribution: Down
            .1.. .... = Sub-TLV: Yes
            ..10 0000 = Prefix Length: 32
            IPv4 prefix: 172.16.4.1
            SubCLV Length: 3
            subTLV: Prefix Attribute Flags (c=4, l=1): Flags:-RN
                Code: Prefix Attribute Flags (4)
                Length: 1
                Flags: 0x60, Re-advertisement, Node
                    0... .... = External Prefix: Not set
                    .1.. .... = Re-advertisement: Set
                    ..1. .... = Node: Set

Within one LSP, R2’s own link 10.2.4.0/24 shows Distribution: Up (bit 8 is 0) while the leaked 172.16.4.1/32 shows Distribution: Down (bit 8 is 1). The prefix length (..10 0000 = 32) and the sub-TLV flag sit in the same octet, exactly as specified.

The R flag from RFC 7794 is set as well (Flags:-RN). That one records only that the prefix was leaked between levels, with no direction, and it lives in a different sub-TLV from the up/down bit.

STEP 2: configure the same thing on R3

RP/0/RP0/CPU0:R1#show route isis
Fri Sep 11 12:35:19.279 UTC

i*L1 0.0.0.0/0 [115/10] via 10.1.2.2, 00:18:26, GigabitEthernet0/0/0/0
i L1 2.2.2.2/32 [115/10] via 10.1.2.2, 00:20:07, GigabitEthernet0/0/0/0
i L1 3.3.3.3/32 [115/20] via 10.1.3.3, 00:19:02, GigabitEthernet0/0/0/1
i L1 10.2.4.0/24 [115/20] via 10.1.2.2, 00:20:07, GigabitEthernet0/0/0/0
i L1 10.3.4.0/24 [115/30] via 10.1.3.3, 00:19:02, GigabitEthernet0/0/0/1
i ia 172.16.4.1/32 [115/20] via 10.1.2.2, 00:03:58, GigabitEthernet0/0/0/0

R3’s LSP now carries the same line, but R1’s chosen path does not change: 20 (10+10) through R2 against 30 (20+10) through R3.

STEP 3: the nearest exit and the best exit part company

R2’s link towards R4 is set to metric 100. The distance from R1 to R2 (10) is untouched.

RP/0/RP0/CPU0:R1#show route isis
Fri Sep 11 12:38:30.384 UTC

i*L1 0.0.0.0/0 [115/10] via 10.1.2.2, 00:21:37, GigabitEthernet0/0/0/0
i L1 2.2.2.2/32 [115/10] via 10.1.2.2, 00:23:18, GigabitEthernet0/0/0/0
i L1 3.3.3.3/32 [115/20] via 10.1.3.3, 00:22:13, GigabitEthernet0/0/0/1
i L1 10.2.4.0/24 [115/110] via 10.1.2.2, 00:01:50, GigabitEthernet0/0/0/0
i L1 10.3.4.0/24 [115/30] via 10.1.3.3, 00:22:13, GigabitEthernet0/0/0/1
i ia 172.16.4.1/32 [115/30] via 10.1.3.3, 00:01:50, GigabitEthernet0/0/0/1

The default route still points at 10.1.2.2 (R2), while 172.16.4.1/32 alone has moved to 10.1.3.3 (R3). The default route compares the distance from R1 to the exit; the leaked route compares the distance from R1 to the destination (30 against 110). The two differ here, and that difference is the whole reason for leaking.

STEP 4: revert

Both leaks and the metric were removed. The only difference between the STEP 0 and STEP 4 _run.txt files is the timestamp line.

Verification configs and show output

The whole test was captured on the R1 - R2 link. The LSP quoted above is No.33 in that file.

Each STEP was captured from all four routers as three files per router. The verification config is the ..._run.txt (the final state is the one from the last STEP).

STEP 0: Initial state (no leaking)

STEP 1: Configure L2-to-L1 route leaking on R2

STEP 2: Configure the same leaking on R3

STEP 3: Set metric 100 on R2’s link towards R4

STEP 4: Revert everything (final state)

References

Related articles

• What Is IS-IS
• IS-IS NSAP Addresses and the NET (System ID)
• IS-IS Level 1 and Level 2 (the hierarchy)
• IS-IS Packet Types and Header Format
• IS-IS Adjacency Formation and States
• IS-IS DIS and the Pseudonode
• IS-IS Network Types (broadcast / point-to-point)
• IS-IS Metrics (narrow and wide)
• IS-IS Authentication (hello-password and lsp-password)
• IS-IS LSPs and the Link-State Database
• The Main IS-IS TLVs
• IS-IS Flooding and LSDB Synchronisation
• IS-IS SPF Computation and Route Selection
• The IS-IS ATT Bit and the Level 1 Default Route
• IS-IS Route Leaking and the Up/Down Bit
• IS-IS Route Summarization