SR-MPLS – Fallback for inetcolor.0
1. Intro
This is a continuation of the previous post: SR-MPLS – Static colored LSP. There we configured a colored LSP and we saw how the next-hop is installed in the inetcolor.0 table.
But, what will happen if that LSP goes down? With no more valid next-hops in the inetcolor.0 table the traffic will be discarded. Well, why not use the next-hops that are available in the inet.3 table?
Because this is a continuation of the previous post, the topology is the same:

2. Configure backup routes for the inetcolor.0 table
If the R7 router goes down, obviously the R1-to-R8 colored LSP will be down as well. This will impact our traffic. We will configure a rib-group to copy routes form inet.3 to inetcolor.0 so then can be used as backups when the Colored LSP are down:
### Initially we have one next-hop in the inet.0 table:
root@R1# run show route table inetcolor.0
inetcolor.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.8-1818<c>/64
*[SPRING-TE/8] 00:00:22, metric 1, metric2 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801008, Push 801007(top)
### Bring down the R7 router:
root@R7# show | compare
[edit interfaces ge-0/0/2]
+ disable;
[edit interfaces ge-0/0/3]
+ disable;
### The LSP is down, so the inetcolor.0 table is empty:
root@R1# run show spring-traffic-engineering lsp
To State LSPname
17.0.0.8-1818<c> Down R8-PATH
root@R1# run show route table inetcolor.0
[edit]
root@R1#
### Ping fails as expected:
root@R1# run ping routing-instance Cust-A 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 192.168.8.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
### But why not use the next-hops available in the inet.3 table:
root@R1# run show route table inet.3
inet.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.2.3.4/32 *[L-ISIS/14] 00:02:01, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801234
17.0.0.2/32 *[L-ISIS/14] 00:02:01, metric 10
> to 17.1.2.2 via ge-0/0/1.0
17.0.0.3/32 *[L-ISIS/14] 00:02:01, metric 10
> to 17.1.3.3 via ge-0/0/2.0
17.0.0.4/32 *[L-ISIS/14] 00:02:01, metric 20
> to 17.1.3.3 via ge-0/0/2.0, Push 801004
17.0.0.5/32 *[L-ISIS/14] 00:02:01, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801005
17.0.0.6/32 *[L-ISIS/14] 00:02:01, metric 20
> to 17.1.3.3 via ge-0/0/2.0, Push 801006
17.0.0.7/32 *[L-ISIS/14] 00:02:01, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801007
17.0.0.8/32 *[L-ISIS/14] 00:02:01, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801008
### For this, we will configure a rib-group to copy prefixes from the inet.3 to inetcolor.0 table:
set routing-options rib-groups INETCOLOR-FALLBACK import-rib inet.3
set routing-options rib-groups INETCOLOR-FALLBACK import-rib inetcolor.0
set routing-options rib-groups INETCOLOR-FALLBACK import-policy INETCOLOR-FALLBACK-POLICY
set policy-options policy-statement INETCOLOR-FALLBACK-POLICY term FALLBACK from protocol l-isis
set policy-options policy-statement INETCOLOR-FALLBACK-POLICY term FALLBACK then accept
set policy-options policy-statement INETCOLOR-FALLBACK-POLICY then reject
set protocols isis rib-group inet3 INETCOLOR-FALLBACK
### Now the inetcolor.0 table was populated with the same inet.3 next hops.
### Notice we have color 0 this time. This will act as a wildcard and it will match any color:
root@R1# run show route table inetcolor.0
inetcolor.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.2.3.4-0<c>/32
*[L-ISIS/14] 00:14:08, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801234
17.0.0.2-0<c>/32
*[L-ISIS/14] 00:14:08, metric 10
> to 17.1.2.2 via ge-0/0/1.0
17.0.0.3-0<c>/32
*[L-ISIS/14] 00:14:08, metric 10
> to 17.1.3.3 via ge-0/0/2.0
17.0.0.4-0<c>/32
*[L-ISIS/14] 00:14:08, metric 20
> to 17.1.3.3 via ge-0/0/2.0, Push 801004
17.0.0.5-0<c>/32
*[L-ISIS/14] 00:14:08, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801005
17.0.0.6-0<c>/32
*[L-ISIS/14] 00:14:08, metric 20
> to 17.1.3.3 via ge-0/0/2.0, Push 801006
17.0.0.8-0<c>/32
*[L-ISIS/14] 00:14:08, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801008
### Ping is working again:
root@R1# run ping routing-instance Cust-A 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
64 bytes from 192.168.8.1: icmp_seq=0 ttl=62 time=4.754 ms
64 bytes from 192.168.8.1: icmp_seq=1 ttl=62 time=4.555 ms
^C
--- 192.168.8.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.555/4.654/4.754/0.100 ms
### As the packet leaves the R1 router, we can see the basic label to R8, so the L-ISIS is being used:
11:36:15.022653 MPLS (label 801008, exp 0, ttl 64) (label 25, exp 0, [S], ttl 64) IP 192.168.1.1 > 192.168.8.1: ICMP echo request, id 17243, seq 61, length 64
### Bring back UP the R7 router:
root@R7# show | compare
[edit interfaces ge-0/0/2]
- disable;
[edit interfaces ge-0/0/3]
- disable;
### The LSP is back up on R1:
root@R1# run show spring-traffic-engineering lsp
To State LSPname
17.0.0.8-1818<c> Up R8-PATH
### The Colored LSP next-hop is installed again and there is something important to note:
### The Colored 1818 prefixe will be chosen once available, due to the longest prefix match:
root@R1# run show route table inetcolor.0 match-prefix "17.0.0.8-*"
inetcolor.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.8-0<c>/32
*[L-ISIS/14] 00:11:54, metric 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801008
17.0.0.8-1818<c>/64
*[SPRING-TE/8] 00:08:12, metric 1, metric2 30
> to 17.1.3.3 via ge-0/0/2.0, Push 801008, Push 801007(top)
### Ping still works:
root@R1# run ping routing-instance Cust-A 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
64 bytes from 192.168.8.1: icmp_seq=0 ttl=62 time=39.243 ms
64 bytes from 192.168.8.1: icmp_seq=1 ttl=62 time=5.469 ms
^C
--- 192.168.8.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.469/22.356/39.243/16.887 ms
### With a tcpdump capture, we can see the additional label imposed by our Colored LSP, to reroute via R7.
### This is to confirm that the Colored LSP is the longest prefix match that was actually selected:
11:55:33.335428 MPLS (label 801007, exp 0, ttl 64) (label 801008, exp 0, ttl 64) (label 25, exp 0, [S], ttl 64) IP 192.168.1.1 > 192.168.8.1: ICMP echo request, id 7009, seq 6, length 64
Here we copied L-ISIS (SR) routes to the inetcolor.0, but nothing is holding us to copy LDP/RSVP routes if those are available.