Colored LSPs and fallback routes

We have seen it is possible to create colored LSPs from one router to another.

A colored route can come from an explicitly configured LSP or from Flex Algos, to make some examples.

Colored routes end up in a special table called inetcolor.0.

Then, we can use well known BGP to attach a color community to an advertised prefix and have our router to resolve the next-hop taking into consideration the color as well.

To refresh these concepts. Think of our topology:

  • there is a colored LSP from R1 to R8 (color red)
  • R8 advertises prefix 1.2.3.4/32 to R1 with community color red
  • R1, instead of resolving the BGP route with an inet.3 route (non colored), is configured so to consider the color as well
  • R1 will use the red colored route found in inetcolor.0 to resolve 1.2.3.4/32

To resolve BGP routes using color community we need this:

set protocols bgp group ibgp family inet unicast extended-nexthop-color

Once enabled, if a colored route comes, Junos tries to resolve it using colored routes only.

Now, consider this scenario:

  • R8 advertises route 5.6.7.8/32 with color purple
  • R1 has 3 routes within inetcolor.0, each with a different color: red, blue, yellow
  • as there is no purple lsp, 5.6.7.8/32 will remain hidden

Once we enable color resolution it is a bit like “all or nothing”.

Is there anything we can do?

Most likely, we have alternative routes into inet.3: uncolored lsp or classic ldp lsps.

What we can do is to leak those routes into inetcolor.0 so to provide fallback routes.

Let’s see how.

In this example R8 is advertising 8.3.2.1/32 with a color community that does not correspond to any inetcolor.0 route at R1:

root@r1_re> show route receive-protocol bgp 8.8.8.8 hidden table inet.0 extensive

inet.0: 29 destinations, 29 routes (28 active, 0 holddown, 1 hidden)
  8.3.2.1/32 (1 entry, 0 announced)
     Accepted
     Nexthop: 8.8.8.8
     Localpref: 100
     AS path: I
     Communities: color:0:4321

root@r1_re> show route table inetcolor.0 match-prefix *-4321*

inetcolor.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

root@r1_re>

As you can see, there is no route for color 4321.

The solution is pretty easy and relies on rib-groups:

set routing-options rib-groups ldp-to-inetcolor import-rib inet.3
set routing-options rib-groups ldp-to-inetcolor import-rib inetcolor.0
set routing-options rib-groups ldp-to-inetcolor import-policy ldp-to-inetcolor

set policy-options policy-statement ldp-to-inetcolor term ldp from protocol ldp
set policy-options policy-statement ldp-to-inetcolor term ldp then accept
set policy-options policy-statement ldp-to-inetcolor then reject

set protocols ldp rib-group ldp-to-inetcolor

Basically, we tell to copy routes from inet.3 to inetcolor.0.
Via policy, we tell junos to only accept ldp routes.
Last, we apply the rib group to ldp (which makes “from protocol ldp” within the policy redundant).

As a result:

root@r1_re> show route table inetcolor.0 match-prefix *-4321*

inetcolor.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)

root@r1_re> show route 8.3.2.1 extensive | match "Protocol "
                Protocol next hop: 8.8.8.8-4321<c>
                        Protocol next hop: 8.8.8.8-4321<c> Metric: 1

                Composite next hops: 1
                        Protocol next hop: 8.8.8.8-4321<c> Metric: 1
                        Composite next hop: 0x6ade6b0 571 INH Session ID: 0x0
                        Indirect next hop: 0x7411884 1048582 INH Session ID: 0x0
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 192.168.14.1 via ge-0/0/2.0 weight 0x1
                                Session Id: 0x0
                                8.8.8.8-0<c>/32 Originating RIB: inetcolor.0
                                  Metric: 1 Node path count: 1
                                  Forwarding nexthops: 1
                                        Next hop type: Router
                                        Next hop: 192.168.14.1 via ge-0/0/2.0 weight 0x1
                                        Session Id: 0x0

Still no routes for color 4321.

Anyhow, Junos tells us the route was resolved using 8.8.8.8-4321<c>….which does not exist.

What’s the trick?
Behind 8.8.8.8-4321<c> there is 8.8.8.8-0<c>. What’s that route?

root@r1_re> show route table inetcolor.0 protocol ldp

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

2.2.2.2-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 24
3.3.3.3-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 23
4.4.4.4-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0
5.5.5.5-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 25
6.6.6.6-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 28
7.7.7.7-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 27
8.8.8.8-0<c>/32
                   *[LDP/9] 01:17:27, metric 1
                    >  to 192.168.14.1 via ge-0/0/2.0, Push 26

It’s the ldp route copied from inet.3.

As, natively, it does not have a color associated, it uses color 0 which acts as a wildcard color. This allows those routes to work as a fallback option.

Junos will always try to perform longest prefix match into inetcolor.0 for a colored route. This means finding the best match for the ip:color pair.
If it cannot find it, then it will do a “softer” longest prefix match using “wildcard” routes that are ip:0 (color 0 as we have just seen).

And here we are! Fallback routes and no more hidden prefixes!

Ciao
IoSonoUmberto

Leave a comment