SR Support in Vyos 1.4 (rolling)
8 min read

SR Support in Vyos 1.4 (rolling)

I recently went on a quick trip to Chicago, followed by a brief 'staycation'. I am very proud that I was able to effectively check-out from tech life. However, this also meant that I had 400 + articles to read in my RSS feed.

While tackling my RSS feed – and getting rid of the redundant feeds – I came across an interesting VyOS project update from November:

Thanks to our long-time contributor Cheeze-It, IS-IS segment routing support has been refactored and brought much closer to the OSPF segment routing implementation (T4739).

Very fascinating work from a familiar name on r/networking . Not only did he add the much needed ISIS-SR configuration to Vyos, he also helped the FRR team add the missing opaque LSA knob for the OSPF implementation.

I was very excited by the prospect of SR-MPLS now working in Vyos, as XRv & XRv9k can be quite beefy and clumsy to utilize in my labs. Vyos, on the other hand, is lean & mean as a CE/PE implementation.

I figured I'd put it to the test. I went to the Vyos site and downloaded the latest rolling image. I then imported it into GNS3 & plopped it directly into my TI-LFA / SR-TE refresher lab. After some configuration tweaking, it worked beautifully. The next part was to test it's potential as an LSR in my topology; Could I create a TI-LFA recovery path, using the SR labels/SIDs on the router?

To simulate a TI-LFA hard coverage scenario, I suspended some links and add a SRLG (shared risk link group) to a crucial node in the path.

Messy – I know – but it did the trick! The end topology looks a little more like this:

Let's consider the normal path for router 3 to reach router 10's loopback. The shortest path would be via router 6, then router 9. If the link towards router 6 failed, the natural second best path would be via router 7 or router 4.

But what if I told you that router 6's path to router 4 & router 9 had a shared risk.... such as a common DWDM shelf, a common fiber conduit, shared ASIC, shared line card, etc. We can program that into the device to protect against the common faults introduced by router 6.

First, here's the SR-MPLS & TI-LFA configuration on router 3:

RP/0/0/CPU0:XRv-3#show run formal | i "isis|mpls"

Building configuration...
 router isis '.*' 
 router isis '.*'  interface 'GigabitEthernet.*' 
 router isis '.*'  interface 'GigabitEthernet.*'  address-family ipv4 unicast 
 router isis '.*'  interface 'GigabitEthernet.*'  address-family ipv4 unicast  fast-reroute per-prefix
 router isis '.*'  interface 'GigabitEthernet.*'  address-family ipv4 unicast  fast-reroute per-prefix ti-lfa
ipv4 unnumbered mpls traffic-eng Loopback0
router isis zeal apply-group GROUP_TILFA
router isis zeal 
router isis zeal is-type level-2-only
router isis zeal net 49.0000.0000.0003.00
router isis zeal address-family ipv4 unicast 
router isis zeal address-family ipv4 unicast metric-style wide
router isis zeal address-family ipv4 unicast fast-reroute per-prefix tiebreaker node-protecting index 100
router isis zeal address-family ipv4 unicast fast-reroute per-prefix tiebreaker srlg-disjoint index 200
router isis zeal address-family ipv4 unicast microloop avoidance
router isis zeal address-family ipv4 unicast microloop avoidance rib-update-delay 65535
router isis zeal address-family ipv4 unicast advertise passive-only
router isis zeal address-family ipv4 unicast segment-routing mpls sr-prefer
router isis zeal interface Loopback0 
router isis zeal interface Loopback0 passive
router isis zeal interface Loopback0 address-family ipv4 unicast 
router isis zeal interface Loopback0 address-family ipv4 unicast prefix-sid index 3
router isis zeal interface GigabitEthernet0/0/0/0 
router isis zeal interface GigabitEthernet0/0/0/0 address-family ipv4 unicast 
router isis zeal interface GigabitEthernet0/0/0/1 
router isis zeal interface GigabitEthernet0/0/0/1 address-family ipv4 unicast 
router isis zeal interface GigabitEthernet0/0/0/2 
router isis zeal interface GigabitEthernet0/0/0/2 address-family ipv4 unicast 
router isis zeal interface GigabitEthernet0/0/0/3 
router isis zeal interface GigabitEthernet0/0/0/3 bfd minimum-interval 100
router isis zeal interface GigabitEthernet0/0/0/3 bfd multiplier 3
router isis zeal interface GigabitEthernet0/0/0/3 bfd fast-detect ipv4
router isis zeal interface GigabitEthernet0/0/0/3 address-family ipv4 unicast 
mpls traffic-eng 
mpls traffic-eng auto-tunnel p2p tunnel-id min 10000 max 14094
mpls ip-ttl-propagate disable
RP/0/0/CPU0:XRv-3#

The above configuration, especially the fast-reroute portion, should protect us if router 6 completely fails, or that common risk SRLG path. The microloop avoidance will implement this tunnel for a set time, in the assumption that the forwarding plane takes time to propagate.

Now let's look at the SRLG configuration on router 6:

RP/0/0/CPU0:XRv-6#show run formal srlg  | i "name|value"

srlg interface GigabitEthernet0/0/0/0 name CONDUIT
srlg interface GigabitEthernet0/0/0/3 name CONDUIT
srlg name CONDUIT value 100
RP/0/0/CPU0:XRv-6#
RP/0/0/CPU0:XRv-6#show srlg name CONDUIT                            

SRLG : CONDUIT
Value : 100

Interface:
 GigabitEthernet0/0/0/0
 GigabitEthernet0/0/0/3


RP/0/0/CPU0:XRv-6#
RP/0/0/CPU0:XRv-6#show isis adjacency | i "0/0/0/0|0/0/3"

XRv-4          Gi0/0/0/0        0cd9.5942.0002 Up    6    00:32:36 Yes None None
XRv-9          Gi0/0/0/3        0c06.7e75.0002 Up    25   00:32:35 Yes None None
RP/0/0/CPU0:XRv-6#  

Great. So the playing field is set.... but how does one setup SR-MPLS (in IS-IS) on VyOS? Much simpler than you think, thanks to Mr. Cheese.

vyos@Vyos-8:~$  show configuration commands | match "isis|mpls"
set protocols isis interface eth0 network
set protocols isis interface eth1 network
set protocols isis interface eth2 metric '40'
set protocols isis interface eth2 network
set protocols isis interface lo passive
set protocols isis level 'level-2'
set protocols isis net '49.0000.0000.0008.00'
set protocols isis segment-routing global-block high-label-value '24999'
set protocols isis segment-routing global-block low-label-value '16000'
set protocols isis segment-routing local-block high-label-value '104000'
set protocols isis segment-routing local-block low-label-value '100000'
set protocols isis segment-routing prefix 10.255.255.8/32 index value '8'
set protocols mpls interface 'eth0'
set protocols mpls interface 'eth1'
set protocols mpls interface 'eth2'
vyos@Vyos-8:~$
vyos@Vyos-8:~$ show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             10.6.8.8/31                       u/u  
eth1             10.7.8.8/31                       u/u  
eth2             10.8.9.8/31                       u/u  
lo               127.0.0.1/8                       u/u  
                 10.255.255.8/32                        
                 ::1/128                                
vyos@Vyos-8:~$

I set the local-block, to be used by the Adjacency Labels, to a high value so they stand out from the Prefix SIDs.

It works:

vyos@Vyos-8:~$ show ip route isis | match label
I   10.255.255.1/32 [115/40] via 10.6.8.6, eth0 inactive, label 16001, weight 1, 00:01:11
                             via 10.7.8.7, eth1 inactive, label 16001, weight 1, 00:01:11
I   10.255.255.2/32 [115/30] via 10.6.8.6, eth0 inactive, label 16002, weight 1, 00:01:11
                             via 10.7.8.7, eth1 inactive, label 16002, weight 1, 00:01:11
I   10.255.255.3/32 [115/20] via 10.6.8.6, eth0 inactive, label 16003, weight 1, 00:06:15
                             via 10.7.8.7, eth1 inactive, label 16003, weight 1, 00:06:15
I   10.255.255.4/32 [115/20] via 10.6.8.6, eth0 inactive, label 16004, weight 1, 00:06:15
I   10.255.255.5/32 [115/20] via 10.6.8.6, eth0 inactive, label 16005, weight 1, 00:06:15
I   10.255.255.6/32 [115/10] via 10.6.8.6, eth0 inactive, label implicit-null, weight 1, 00:06:15
I   10.255.255.7/32 [115/10] via 10.7.8.7, eth1 inactive, label implicit-null, weight 1, 00:06:15
I   10.255.255.9/32 [115/20] via 10.6.8.6, eth0 inactive, label 16009, weight 1, 00:06:15
I   10.255.255.10/32 [115/30] via 10.6.8.6, eth0 inactive, label 16010, weight 1, 00:06:15
vyos@Vyos-8:~$ 
vyos@Vyos-8:~$ show mpls table
 Inbound Label  Type        Nexthop   Outbound Label  
 -----------------------------------------------------
 16001          SR (IS-IS)  10.7.8.7  16001           
 16002          SR (IS-IS)  10.7.8.7  16002           
 16003          SR (IS-IS)  10.7.8.7  16003           
 16003          SR (IS-IS)  10.6.8.6  16003           
 16004          SR (IS-IS)  10.6.8.6  16004           
 16005          SR (IS-IS)  10.6.8.6  16005           
 16006          SR (IS-IS)  10.6.8.6  implicit-null   
 16007          SR (IS-IS)  10.7.8.7  implicit-null   
 16009          SR (IS-IS)  10.6.8.6  16009           
 16010          SR (IS-IS)  10.6.8.6  16010           
 100000         SR (IS-IS)  10.8.9.9  implicit-null   
 100001         SR (IS-IS)  10.7.8.7  implicit-null   
 100002         SR (IS-IS)  10.6.8.6  implicit-null   

vyos@Vyos-8:~$ 

To further demonstrate the Microloop avoidance / node protection feature... I also set the Metric between Router 8 & 9 to be 40, rather than the default value of 10, in the topology. To demonstrates that router 3 is trying to really avoid sending the backup path via router 6.

set protocols isis interface eth2 metric '40'

vyos@Vyos-8:~$ show isis neighbor XRv-9 | match Inter
    Interface: eth2, Level: 2, State: Up, Expires in 28s
vyos@Vyos-8:~$

Now let's see what router 3 sees:

RP/0/0/CPU0:XRv-3#show isis fast-reroute 10.255.255.10/32


L2 10.255.255.10/32 [30/115]
     via 10.3.6.6, GigabitEthernet0/0/0/3, XRv-6, SRGB Base: 16000, Weight: 0
         Backup path: TI-LFA (node+srlg), via 10.3.7.7, GigabitEthernet0/0/0/1 XRv-7, SRGB Base: 16000, Weight: 0
           P node: Vyos-8.00 [10.255.255.8], Label: 16008
           Q node: XRv-9.00 [10.255.255.9], Label: 100000
           Prefix label: 16010
RP/0/0/CPU0:XRv-3#
RP/0/0/CPU0:XRv-3#show cef 10.255.255.10/32  | i "backup|16008"

   via 10.3.7.7/32, GigabitEthernet0/0/0/1, 9 dependencies, weight 0, class 0, backup (remote) [flags 0x8300]
     local label 16010      labels imposed {16008 100000 16010}
RP/0/0/CPU0:XRv-3#

You can see that an auto-engineered fast-reroute path is generated. Utilizing the following label stack:

  • Node SID of 16008 to path to Router 8
  • Adjacency SID on Router 8 to force the traffic over the less preferred link, via Router 9
  • Bottom-of-stack is the label for the node SID of Router 10.

If this were to be combined with a VPN service label – which it likely would – that would mean a label depth of 4 protecting the payload.

Here's what the backup path looks like:

This proves that Vyos – in the to-be-released 1.4 version, anyway – is a viable SR-MPLS LSR replacement for XRv, Junos, EOS, etc. – at least in your lab! It also boots way faster and utilizes modest resources. Sadly, RFC 7432 implementation and TI-LFA are not implemented in FRR, as of yet:

vyos@Vyos-8:~$ vtysh

Hello, this is FRRouting (version 8.4.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

Vyos-8# show isis fast-reroute 
% Command incomplete: show isis fast-reroute 
Vyos-8# show isis fast-reroute summary 
Area VyOS:
 IS-IS L2 IPv4 Fast ReRoute summary:

 Protection \ Priority     Critical  High      Medium    Low       Total   
 --------------------------------------------------------------------------
 Classic LFA               0         0         0         0         0       
 Remote LFA                0         0         0         0         0       
 Topology Independent LFA  0         0         0         0         0       
 ECMP                      0         0         3         0         3       
 Unprotected               0         0         6         0         6       
 Protection coverage       0.00%     0.00%     33.33%    0.00%     33.33%  

(I also tried EVPN rt-5 in my lab, without luck)

VPNv4 Unicast + SR works just fine :)

This makes me happy as I can build larger topologies & boot/restart resources faster. Thanks to the VyOS team, FRR team,  &  Cheeze_it