Juniper Route Leaking Part 2 - Instance Import

In the Part 1 we talked about the route leaking using RIB Groups, in this post will continue to discuss how route leaking can can be achieved using the instance-import command.

We’ll use the same topology through this series for the sake of comparison between the different techniques.

One of the differences between instance-import and RIB groups is the ability to directly filter the unwanted routes. This can be achieved using policies with different criteria that can help refine the imported routes instead of just importing everything.

Let’s see how we can use it to import R2 loopback from R2.inet.0 routing table to inet.0 routing table

Let’s take a look at R3 routing table first

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[OSPF/10] 00:13:00, metric 1

                    > to 10.0.13.1 via ge-0/0/1.0

3.3.3.3/32         *[Direct/0] 00:19:18

                    > via lo0.10

4.4.4.4/32         *[OSPF/10] 00:13:00, metric 1

                    > to 10.0.34.4 via ge-0/0/3.0

10.0.13.0/24       *[Direct/0] 00:19:04

                    > via ge-0/0/1.0

10.0.13.3/32       *[Local/0] 00:19:05

                      Local via ge-0/0/1.0

10.0.14.0/24       *[OSPF/10] 00:13:00, metric 2

                      to 10.0.13.1 via ge-0/0/1.0

                    > to 10.0.34.4 via ge-0/0/3.0

10.0.34.0/24       *[Direct/0] 00:19:04

                    > via ge-0/0/3.0

10.0.34.3/32       *[Local/0] 00:19:05

                      Local via ge-0/0/3.0

224.0.0.5/32       *[OSPF/10] 00:19:28, metric 1

                      MultiRecv

                                       

R2.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.2.2.2/32         *[OSPF/10] 00:13:00, metric 1

                    > to 10.0.23.2 via ge-0/0/2.0

10.0.23.0/24       *[Direct/0] 00:19:04

                    > via ge-0/0/2.0

10.0.23.3/32       *[Local/0] 00:19:05

                      Local via ge-0/0/2.0

224.0.0.5/32       *[OSPF/10] 00:19:27, metric 1

                      MultiRecv

First we need to define the policy matches on source instance and the wanted prefix to be leaked; in our case R2 loopback interface

policy-options {

    policy-statement FROM-R2-TO-GLOBAL {

        term 1 {

            from {

                instance R2;

                protocol ospf;

                route-filter 2.2.2.2/32 exact;

            }

            then accept;

        }

        term REJECT {

            then reject;

        }

    }                      

} 

You can see here that we have three criteria’s. In plain English this is “ I need the route to be from R2.inet.0 and to be an OSPF route and it must be the prefix 2.2.2.2/32 exactly”

Let’s apply this under the routing-option hierarchy

root@R3> show configuration routing-options

instance-import FROM-R2-TO-GLOBAL;

Let’s check the routing table again

root@R3> show route

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[OSPF/10] 00:24:44, metric 1

                    > to 10.0.13.1 via ge-0/0/1.0

2.2.2.2/32         *[OSPF/10] 00:00:03, metric 1

                    > to 10.0.23.2 via ge-0/0/2.0

3.3.3.3/32         *[Direct/0] 00:31:02

                    > via lo0.10

4.4.4.4/32         *[OSPF/10] 00:24:44, metric 1

                    > to 10.0.34.4 via ge-0/0/3.0

10.0.13.0/24       *[Direct/0] 00:30:48

                    > via ge-0/0/1.0

10.0.13.3/32       *[Local/0] 00:30:49

                      Local via ge-0/0/1.0

10.0.14.0/24       *[OSPF/10] 00:24:44, metric 2

                      to 10.0.13.1 via ge-0/0/1.0

                    > to 10.0.34.4 via ge-0/0/3.0

10.0.34.0/24       *[Direct/0] 00:30:48

                    > via ge-0/0/3.0

10.0.34.3/32       *[Local/0] 00:30:49

                      Local via ge-0/0/3.0

224.0.0.5/32       *[OSPF/10] 00:31:12, metric 1

                      MultiRecv

R2.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.2.2.2/32         *[OSPF/10] 00:24:44, metric 1

                    > to 10.0.23.2 via ge-0/0/2.0

10.0.23.0/24       *[Direct/0] 00:30:48

                    > via ge-0/0/2.0

10.0.23.3/32       *[Local/0] 00:30:49

                      Local via ge-0/0/2.0

224.0.0.5/32       *[OSPF/10] 00:31:11, metric 1

                      MultiRecv

The prefix 2.2.2.2/32 is now present in the inet.0 routing table. Unlike RIB Groups, you’ll notice that prefix 10.0.23.0/24 wasn't imported, which tells that you have more control on which prefix you can import and export using that technique. The matches cover everything from BGP attributed, OSPF route types, tags, filters, virtually everything that can be used to differentiate the allowed and disallowed routes.

in Part 3 we'll see how we can do that with L3-VPN route targets and Auto-Export.