SIDs and prefixes

Segment Routing is a way to route traffic over a network based on the source routing paradigm.

In a previous post we built a small lab enabling SR in a ISIS L2 domain and we started looking at the first type of segments: Adjacency.

Basically, a MPLS label is associated to each ISIS neighbor of a node. Adj SID is a one-hop segment that simply tells “send packet to this neighbor”.

Adj SID is not bound to any prefix but to a directly connected neighbor.

Today, we are going to look at SIDs that allow us to reach prefixes, called…Prefix SIDs.

There are different kinds of prefix SIDs.

The first one we are going to see is Node Segment SID.

This SID is used to identify a node on the network.

To enable node SID, simply add this to the router config:

set protocols isis source-packet-routing node-segment ipv4-index 108

Each node of the network MUST use a different index (in my lab I used this rule: R1 uses 101, R2 uss 102 and so on).
Using unique indexes is fundamental in order to avoid label conflicts.

Is this enough? No! Routers need a label space to allocate labels from. The space used to create Node SIDs is called Segment Routing Global Block (SRGB). SRGB is used to allocate labels that have global meaning on a node-basis.

SRGB can be identical or different on all the nodes. It is recommended to use the same one on all the nodes.

To configure and verify SRGB:

set protocols isis source-packet-routing srgb start-label 1000
set protocols isis source-packet-routing srgb index-range 1000

root@r8_re# run show mpls label usage | match SRGB
SRGB        1000    1999     ISIS
SRGB        1000    1999     ISIS

We have 1000 available labels: from 1000 to 1999.

Let’s recall the topology:

On node 1, we check Node SID for R8:

root@r1_re> show route table inet.3 8.8.8.8

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[L-ISIS/14] 01:13:14, metric 30
                    >  to 192.168.13.1 via ge-0/0/1.0, Push 1108
                       to 192.168.14.1 via ge-0/0/2.0, Push 1108

Node SID is associated to the lo0/router-id address.

Route is placed into inet.3 as it works like a LSP.

There are 2 next-hops as there are 2 ecmp paths to reach R8: via R3 and R4.

A label is pushed: 1008. That label is node SRGB start label + remote node (r8) index…1000+108.

Each node computes its label locally. If SRGB is identical on all the nodes, then the same label will be used on all the nodes. This way, it is also easier to troubleshoot and follow the traffic.

Let’s have a look on R3:

root@r3_re> show route table inet.3 8.8.8.8

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[L-ISIS/14] 01:34:16, metric 20
                    >  to 192.168.35.1 via ge-0/0/3.0, Push 1108
                       to 192.168.36.1 via ge-0/0/4.0, Push 1108

root@r3_re> show route table mpls.0 label 1108

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1108               *[L-ISIS/14] 01:34:25, metric 20
                    >  to 192.168.35.1 via ge-0/0/3.0, Swap 1108
                       to 192.168.36.1 via ge-0/0/4.0, Swap 1108

Inet.3 route uses the same label (same SRGB).

Traffic coming from R1 with label 1108 is processed by the mpls.0 table and a label swap is performed. The same label is used (again, because SRGB is the same).

As a result, using the same SRGB on all the nodes, we know label 1108 is the label to reach R8.

Node SID is advertised as a TLV. We can see it within the isis database:

root@r1_re> show isis database r8_re extensive | match "Node SID"
      Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 108

Flag with N-bit set means it is a nod segment.

Now, let’s add this to R8:

set routing-options static route 8.1.2.3/32 discard

set policy-options policy-statement exp-anycast-sr term 8123 from protocol static
set policy-options policy-statement exp-anycast-sr term 8123 from route-filter 8.1.2.3/32 exact
set policy-options policy-statement exp-anycast-sr term 8123 then prefix-segment index 808
set policy-options policy-statement exp-anycast-sr term 8123 then accept
set policy-options policy-statement exp-anycast-sr then reject

set protocols isis export exp-anycast-sr

What Junos does is to inject the static route into ISIS along with a segment index.

As a result, R1 has a SR route to 8.1.2.3/32:

root@r1_re> show route table inet.3

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.1.2.3/32         *[L-ISIS/14] 00:00:40, metric 30
                       to 192.168.13.1 via ge-0/0/1.0, Push 1808
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 1808

Label 1808 is consistent with 1000+808.

All good? Not really… Route to 8.8.8.8/32 (Node SID) disappeared.

That happened because injecting prefixes via policy and setting node segment at [protocols isis] level are mutually exclusive.

To overcome this, we modify the policy as follows:

set policy-options policy-statement exp-anycast-sr term 8123 from protocol static
set policy-options policy-statement exp-anycast-sr term 8123 from route-filter 8.1.2.3/32 exact
set policy-options policy-statement exp-anycast-sr term 8123 then prefix-segment index 808
set policy-options policy-statement exp-anycast-sr term 8123 then accept
set policy-options policy-statement exp-anycast-sr term nodesid from protocol direct
set policy-options policy-statement exp-anycast-sr term nodesid from interface lo0.0
set policy-options policy-statement exp-anycast-sr term nodesid from route-filter 8.8.8.8/32 exact
set policy-options policy-statement exp-anycast-sr term nodesid then prefix-segment index 108
set policy-options policy-statement exp-anycast-sr term nodesid then prefix-segment node-segment
set policy-options policy-statement exp-anycast-sr term nodesid then accept
set policy-options policy-statement exp-anycast-sr then reject

Let’s check again:

root@r1_re> show route table inet.3

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.1.2.3/32         *[L-ISIS/14] 00:06:27, metric 30
                       to 192.168.13.1 via ge-0/0/1.0, Push 1808
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 1808
8.8.8.8/32         *[L-ISIS/14] 00:00:19, metric 30
                    >  to 192.168.13.1 via ge-0/0/1.0, Push 1108
                       to 192.168.14.1 via ge-0/0/2.0, Push 1108

Here we go! The following line is now useless:

set protocols isis source-packet-routing node-segment ipv4-index 108

What’s the difference between those two SIDs? Let’s look at the database:

    IP extended prefix: 8.1.2.3/32 metric 0 up
      8 bytes of subtlvs
      Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 808
    IP extended prefix: 8.8.8.8/32 metric 0 up
      8 bytes of subtlvs
      Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 108

8.1.2.3/32 is a prefix SID while 8.8.8.8/32 is a node SID.

Node SID is a just a “special” prefix SID.

Through this we’ve found out about a new SID: prefix SID. This SID is used to tell how to reach a given prefix.

The IGP shortest path is used to tell how to reach the destination prefix.

One might think “if a prefix SID is just the IGP shortest path to a prefix, what’s the point of this whole SR? Can’t I just us IGP?”.

Legit but it is beneficial to look at prefix SIDs not as IGP paths but as segments, a segment meaning “reach this node/prefix”.

The idea behind SR is to compose and stack those segments to create a wider path.

Let’s assume we want to create a path from R1 to R7.

IGP has its route but we might want traffic to follow another path, for example R1-R3-R8-R7. SR allows us this. How? A three labels stack:

  • label 1, top, adj sid R1-R3
  • label 2, middle, node-SID to R8 on R3 (if SRGB is the same on all the nodes, the label is the same on all the nodes)
  • label 3, bottom, adj sid R8-R7

What happens?

  • label stack is added to packets
  • R1 pops the first label and sends packets to R3
  • R3 analyzes second label and understands that label is the one associated with R8 node-SID
  • R8 pops the last label and sends packets to R7

When R3 processes label 2, it will swap the label as we have seen before. Up to R8, we will follow the IGP path switching labels at each intermediate hop (this is not so different from LDP). This means nodes like R5 or R6 will be crossed but that is transparent to the initial SR stack. The stack simply tells R3 to reach R8, it does not matter to him what happens between R3 and R8; it just wants that path to be taken.

Simply put, we have just specified a specific path to go from R1 to R7 (for whatever reason).

But…what’s that? Just good old Traffic Engineering. And this is one of the key benefits of SR: SR-TE.

Anyhow, that is another story. Enough for this time.

Ciao
IoSonoUmberto

One thought on “SIDs and prefixes”

  1. Pingback: One topology to rule them all: LFA, RLFA and TILFA – IoSonoUnRouter

Leave a comment