Juniper JunOS L3-VPN vrf-table-label

vrf-table-label introduces several features that changes JunOS behavior with L3-VPNs. But first let’s review the default behavior of JunOS regarding label allocation and some other QoS and Filtering Features.

By default, JunOS allocates labels per customer interface “next-hop” in L3-VPNs, meaning that if a PE has two connected CE routers with two Ethernet interfaces under the same VRF. JunOS will allocate one label for each CE interface. Also any routing updates received from this interface or static routes that points to the CE interface will have the same VPN Label. If there’s a loopback interface that is configured under this L3-VPN; it will always have a different label.

vrf-table-label will create a label for all the routes present on a PE VRF, thus; conserving resources for label allocations. Instead of having a label for each next-hop and for loopback interfaces, the ingress PE will allocate one label for the whole VRF

From a security perspective, JunOS doesn’t export (Redistribute)  direct interface prefix of a CE customer as a VPNV4 update to other PEs unless this interface has a dynamic routing protocol running between it and the CE, or there’s a static route pointing to a certain prefix and using this interface as a next-hop.

This behavior can be overridden when using vrf-table-label

On an egress PE router, if the PE-CE link is a point to point interface, then there will be no need to do an IP lookup. In case it is a shared medium or a multi-access network, a secondary lookup is needed to resolve which destination CE is exactly needed to forward the packet to. For JunOS to do this, a hardware card called Tunnel Service PIC is needed to achieve this. If there’s no TS PIC installed, vrf-table-label creates a logical “LSI” Label Switched Interface for that VRF and it is used by Egress PE router to receive VPN labeled packets, after removing that label, a secondary IP lookup takes place on the logical LSI interface, which can also be used to filter traffic and apply QoS features before doing the ARP lookup on the shared medium.

Now for the good part, let’s see before and after configuring vrf-table-label on a PE router

As shown below in the diagram, we have PE1 that connects CE-A1 and CE-B1 while CE-B2 is connected to PE3. The PE-CE routing protocol

The protocol running between PE1 – CEA1 is OSPF and between PE1 and CE-B1 is static. Both are exported to VRF B on PE1 and exchanged via VPNv4 with PE3.

Here’s what the configuration looks like on PE1

admin@PE1> show configuration routing-instances B
instance-type vrf;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.30;
route-distinguisher 20.20.1.1:2;
vrf-import B-Import;
vrf-export B-Export;
vrf-table-label;
routing-options {
    static {
        route 30.3.3.3/32 next-hop 30.0.2.2;
    }
}
protocols {
    ospf {
        export EXPORTB-BGP-TO-OSPF;
        area 0.0.0.0 {
            interface lo0.30;
            interface ge-0/0/0.0;
        }
    }
}

 
admin@PE1> show configuration policy-options policy-statement B-Export
term 1 {
    from protocol direct;
    then {
        community add B;
        accept;
    }
}
term 2 {
    from protocol ospf;
    then {
        community add B;
        accept;
    }
}
term 3 {
    from protocol static;
    then {
        community add B;
        accept;
    }
}

Now let’s check what PE3 has in VRF B routing table

admin@PE3> show route table B.inet.0 protocol bgp   

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

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

20.20.1.1/32       *[BGP/170] 00:00:08, localpref 100, from 20.20.1.1

                      AS path: I

                    > to 20.3.4.4 via ge-0/0/0.0, Push 299984, Push 300352(top)

30.0.1.0/24        *[BGP/170] 00:00:08, localpref 100, from 20.20.1.1

                      AS path: I

                    > to 20.3.4.4 via ge-0/0/0.0, Push 300000, Push 300352(top)

30.0.2.0/24        *[BGP/170] 00:00:08, localpref 100, from 20.20.1.1

                      AS path: I

                    > to 20.3.4.4 via ge-0/0/0.0, Push 300016, Push 300352(top)

30.1.1.1/32        *[BGP/170] 00:00:08, MED 1, localpref 100, from 20.20.1.1

                      AS path: I

                    > to 20.3.4.4 via ge-0/0/0.0, Push 300000, Push 300352(top)

30.3.3.3/32        *[BGP/170] 00:00:08, localpref 100, from 20.20.1.1

                      AS path: I

                    > to 20.3.4.4 via ge-0/0/0.0, Push 300016, Push 300352(top)

As shown in the above output, we can see PE1 VPN loopback interface. We can also see the exported static and OSPF routes from PE1 along with the directly connected interfaces between PE1 and both CEs.

Now notice how inner VPN labels are being pushed to reach networks on PE1, this is the default behavior of Junos when it comes to VPN label assignment as mentioned earlier

1.      Label 299984 is being pushed to reach PE1 VPN B loopback

2.      Label 300000 is being pushed  to reach CE-A1 directly connected interface and loopback

3.      Label 300016 is being pushed  to reach CE-B1 directly connected interface and loopback

Now let’s remove the static routing and OSPF between PE1 and it’s CEs. This is what will the export policy look like

admin@PE1# show policy-options policy-statement B-Export              
term 1 {
    from protocol direct;
    then {
        community add B;
        accept;
    }
}
 Now let’s check PE2 VPN B table again

admin@PE3> show route table B.inet.0 protocol bgp
 B.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both 20.20.1.1/32       *[BGP/170] 00:11:50, localpref 100, from 20.20.1.1                      AS path: I                    > to 20.3.4.4 via ge-0/0/0.0, Push 299984, Push 300352(top)

Notice that now we can only see PE1 VPN loopback prefix even though the links between PE1 and CEs fall under direct routes, it’s not exported. Now let’s enable vrf-table-label and check if we get CE directly connected routes again on PE3

 admin@PE1# show routing-instances B
instance-type vrf;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.30;
route-distinguisher 20.20.1.1:2;
vrf-import B-Import;
vrf-export B-Export;
vrf-table-label;

let’s check PE3 VPN B table again

admin@PE3> show route table B.inet.0 protocol bgp
 B.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 20.20.1.1/32       *[BGP/170] 00:02:54, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.0.1.0/24        *[BGP/170] 00:02:54, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.0.2.0/24        *[BGP/170] 00:02:54, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)

Now you can see that the direct routes has been exported without the need of having a next-hop or an IGP with the CE routers. You’ll also notice that the inner VPN label being pushed is 16 regardless of the prefix origin interface.

Let’s enable exporting static and OSPF to MP-BGP again on PE1 and check the routes received on PE3

admin@PE1> show configuration policy-options policy-statement B-Export
term 1 {
    from protocol direct;
    then {
        community add B;
        accept;
    }
}
term 2 {
    from protocol ospf;
    then {
        community add B;
        accept;
    }
}
term 3 {
    from protocol static;
    then {
        community add B;
        accept;
    }
}

 B.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
 20.20.1.1/32       *[BGP/170] 00:17:02, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.0.1.0/24        *[BGP/170] 00:17:02, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.0.2.0/24        *[BGP/170] 00:17:02, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.1.1.1/32        *[BGP/170] 00:01:14, MED 1, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
30.3.3.3/32        *[BGP/170] 00:01:14, localpref 100, from 20.20.1.1
                      AS path: I
                    > to 20.3.4.4 via ge-0/0/0.0, Push 16, Push 300352(top)
 

Back to PE1, let’s check the Label Switched interface and see what we’ve got there

admin@PE1> show interfaces lsi
Physical interface: lsi, Enabled, Physical link is Up
  Interface index: 4, SNMP ifIndex: 4
  Type: Software-Pseudo, Link-level type: LSI, MTU: 1496, Speed: Unlimited
  Device flags   : Present Running
  Link flags     : None
  Last flapped   : Never
    Input packets : 0
    Output packets: 0
   Logical interface lsi.0 (Index 72) (SNMP ifIndex 526)
    Flags: Point-To-Point SNMP-Traps Encapsulation: LSI-NULL
    Input packets : 0
    Output packets: 0    Security: Zone: Null
    Protocol inet, MTU: 1496
      Flags: None
    Protocol iso, MTU: 1496
      Flags: Is-Primary
    Protocol inet6, MTU: 1496
      Flags: Is-Primary

Indeed an logical LSI has been created with unit 0. Let’s ping from PE3 to PE1 loopback and see if there’s any traffic passing through it

admin@PE3> ping 20.20.1.1 routing-instance B rapid count 10
PING 20.20.1.1 (20.20.1.1): 56 data bytes
!!!!!!!!!!
--- 20.20.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 11.965/13.287/14.027/0.873 ms
  admin@PE1> show interfaces lsi
Physical interface: lsi, Enabled, Physical link is Up
  Interface index: 4, SNMP ifIndex: 4
  Type: Software-Pseudo, Link-level type: LSI, MTU: 1496, Speed: Unlimited
  Device flags   : Present Running
  Link flags     : None
  Last flapped   : Never
    Input packets : 0
    Output packets: 0
   Logical interface lsi.0 (Index 72) (SNMP ifIndex 510)
    Flags: Point-To-Point SNMP-Traps Encapsulation: LSI-NULL
    Input packets : 10
    Output packets: 0
    Security: Zone: Null
    Protocol inet, MTU: 1496
      Flags: None
    Protocol iso, MTU: 1496
      Flags: Is-Primary
    Protocol inet6, MTU: 1496
      Flags: Is-Primary

Hopfully that clears up what the vrf-table-label command do

Juniper Route Leaking Part 4 - Static Routes and Filter Based Forwarding

In previous post, we discussed how to route leak routes in JUNOS using RIB Groups, Instance Import and VRF Route Targets and Auto-Export. In this final post we’re going to discuss how we do this using firewall filters and static routes, both of them are really easy to configure but with a few caveats.

Static Routes

 

Let’s configure a static route in the routing table R2.inet.0 that points to R1 loopback 1.1.1.1 in the routing table inet.0

root@R3> show configuration routing-instances R2 routing-options

static {

    route 1.1.1.1/32 next-table inet.0;

}

After we commit

root@R3> show route table R2.inet.0

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

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

1.1.1.1/32         *[Static/5] 00:00:53

                      to table inet.0

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

                    > to 10.0.23.2 via ge-0/0/2.0

10.0.23.0/24       *[Direct/0] 00:45:32

                    > via ge-0/0/2.0

10.0.23.3/32       *[Local/0] 00:45:32

                      Local via ge-0/0/2.0

224.0.0.5/32       *[OSPF/10] 00:45:33, metric 1

                      MultiRecv

Checking R2.inet.0 routing table on router R3, the static route to 1.1.1.1/32 is clearly there with inet.0 as a next-hop. Let’s export (redistribute) to R3.inet.0 OSPF protocol so that R2 can reach the prefix 1.1.1.1/32

root@R3# show policy-options policy-statement EXPORT-TO-R2-OSPF

term 1 {

    from protocol static;

}

then accept;

root@R3# show routing-instances R2 protocols ospf

export EXPORT-TO-R2-OSPF;

area 0.0.0.1 {

    interface ge-0/0/2.0;

}

And the route 1.1.1.1/32 arrived safely to the router R2 as an OSPF external route

root@R2> show route

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

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

2.2.2.2/32         *[Direct/0] 01:43:20

                    > via lo0.10

1.1.1.1/32         *[OSPF/150] 00:00:04, metric 0, tag 0

                    > to 10.0.23.3 via ge-0/0/2.0

10.0.23.0/24       *[Direct/0] 01:43:15

                    > via ge-0/0/2.0

10.0.23.2/32       *[Local/0] 01:43:16

                      Local via ge-0/0/2.0

10.94.160.0/20     *[Direct/0] 01:43:08

                    > via ge-0/0/0.0

10.94.169.241/32   *[Local/0] 01:43:08

                      Local via ge-0/0/0.0

224.0.0.5/32       *[OSPF/10] 01:43:26, metric 1

                      MultiRecv

Now, here’s the catch, we’ve managed to get the R2 to reach the prefix 1.1.1.1/32, but what about the other way around? Let’s try to configure a route from inet.0 to R2.inet.0 on R3 to allow 2 way communication

[edit]

root@R3# set routing-options static route 2.2.2.2/32 next-table R2.inet.0

[edit]

root@R3# commit

error: [rib inet.0 routing-options static]

    next-table may loop

error: configuration check-out failed

The commit Failed, the reason is JUNOS prevents you from configuring bi-directional static routes between 2 routing-instances to eliminate the possibility of a routing loop happening.

In this case, we’ll have to use of the previously mentioned route leaking methods in conjunction with static route leaking to accomplish bi-directional communication between routing instances OR we can also use the Filter Based Forwarding which will be the final method to close this series.

Filter-Based Forwarding

Filter based forwarding is very similar in implementation to Policy-Based Routing(PBR). In our case here, we’ll use FBF to direct incoming packets from R1 to R2.inet.0 routing table

There are two components of FBF

1.       A firewall filter that has certain match criteria ( SRC/DST IP, Port numbers, COS etc..) which then points to a specific routing table

2.       Apply that firewall filter under the incoming interface

Let’s see how we can do this

First, let’s create a firewall filter that matches source IP 1.1.1.1/32 and redirect it to R2.inet.0, and then we apply that under the incoming interface ge-0/0/1

root@R3> show configuration firewall

family inet {

    filter FROM-R1-TO-R2-ROUTING-TABLE {

        term 1 {

            from {

                source-address {

                    1.1.1.1/32;

                }

            }

            then {

                routing-instance R2;

            }

        }

        term 2 {

            then accept;

        }

    }

}

root@R3> show configuration interfaces ge-0/0/1 

unit 0 {

    family inet {

        filter {

            input FROM-R1-TO-R2-ROUTING-TABLE;

        }

        address 10.0.13.3/24;

    }

    family mpls;

}

Up till now, R1 doesn’t know how to get to 2.2.2.2/32, we can simply configure a static route on R1 pointing to R3 in order to reach 2.2.2.2/32 subnet

root@R1> show configuration routing-options

static {

    route 2.2.2.2/32 next-hop 10.0.13.3;

Let’s try to ping and traceroute from R2 to R1

root@R2> ping 1.1.1.1 source 2.2.2.2

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=63 time=4.890 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=8.144 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=63 time=8.310 ms

^C

--- 1.1.1.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 4.890/7.115/8.310/1.575 ms

root@R2> traceroute 1.1.1.1 source 2.2.2.2

traceroute to 1.1.1.1 (1.1.1.1) from 2.2.2.2, 30 hops max, 40 byte packets

 1  10.0.23.3 (10.0.23.3)  6.467 ms  5.239 ms  6.052 ms

 2  1.1.1.1 (1.1.1.1)  7.612 ms  6.583 ms  9.763 ms

Looks pretty good!

Before closing this, there’s a little limitation regarding the FBF method. i’ll put it into bullets

·         You can redirect packets from inet.0 to any user configured instance

·         You can redirect packets from any user configured instance to another

·         You CAN’T redirect packets from any user configured instance to inet.0

Hopefully this Series managed to make the powerful route leaking techniques in Juniper JUNOS easy to understand and to implement

Juniper Route Leaking Part 3 - VRF Route Targets and Auto-Export

In the previous posts we discusses how to leak routes using RIB Groups and Instance-Import statements. In our third tutorial, we’ll check how we can do this in L3-VPN routing instances.

The major difference between the previous methods and this one, is that RIB-Groups and Instance Import are only local route-leaking. Meaning, the routes that you import or export are only the prefixes that are present on the router. In L3-VPNs, Multi-Protocol BGP  ( MP-BGP) is used to signal and exchange prefix with remote routers using MPLS as a foundation. I highly suggest you read a lot about MPLS before going through this tutorial.

JUNOS supports to route-leaking in L3-VPNs. External Route Leaking and Internal Route Leaking. Let’s check what each one of them do.

External Route Leaking

As mentioned Earlier, MP-BGP is used to import the routes from a VRF present on a remote router using MP-BGP.

Check this topology

In L3-VPNs typical application, PE Routers connect customers in different geographical locations. In our case here, PE1 and PE2 connect Customer A Branches and Customer B Branches with each other.

Assuming that all VRF configurations is done, MP-BGP is established and customer A branches are connected and customer B branches are connected. Let’s see how Customer A routing table look like

On PE1

root@PE1> show route table cust-a

CUST-A1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

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

10.1.1.1/32        *[Direct/0] 00:26:30

                    > via lo0.20

10.2.2.2/32        *[BGP/170] 00:26:30, localpref 100, from 2.2.2.2

                      AS path: I

                    > to 10.0.13.3 via ge-0/0/1.0, Push 299840, Push 299792(top)

On PE2

root@PE2> show route table CUST-A2.inet.0  

CUST-A2.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

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

10.1.1.1/32        *[BGP/170] 00:28:26, localpref 100, from 1.1.1.1

                      AS path: I

                    > to 10.0.23.3 via ge-0/0/2.0, Push 299808, Push 299776(top)

10.2.2.2/32        *[Direct/0] 00:29:04

                    > via lo0.20

On PE1, you can see that the remote prefix 10.2.2.2/32 is known via BGP and the outgoing interface is ge-0/0/1 towards P3

Let’s try to leak Customer B routes from PE2 to Customer A present on PE1

root@PE1# show policy-options policy-statement CUST-A1-IMPORT

term 1 {

    from {

        protocol bgp;

        community CUSTA;

    }

    then accept;

}

term LEAK-FROM-PE2-CUSTB {

    from {

        community CUSTB;

    }

    then accept;

}

root@PE1# show routing-instances CUST-A1

instance-type vrf;

interface lo0.20;

route-distinguisher 1:102;

vrf-import CUST-A1-IMPORT;

vrf-export CUST-A1-EXPORT;

Let’s check Customer A Routing Table on PE1

root@PE1> show route table cust-a

CUST-A1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

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

10.1.1.1/32        *[Direct/0] 00:39:22

                    > via lo0.20

10.2.2.2/32        *[BGP/170] 00:39:22, localpref 100, from 2.2.2.2

                      AS path: I

                    > to 10.0.13.3 via ge-0/0/1.0, Push 299840, Push 299792(top)

20.2.2.2/32        *[BGP/170] 00:02:59, localpref 100, from 2.2.2.2

                      AS path: I

                    > to 10.0.13.3 via ge-0/0/1.0, Push 299856, Push 299792(top)

You can see now that Customer A can send Traffic to the remote branch of Customer B.

But what about the Customer B local Branch on the same PE1 router, it has the exact same Route Target Community like Customer B on PE2. Noting that I didn’t define a certain protocol to import from which can be anything ( direct, bgp ..etc)

The problem here is that Route Target Communities are put on the prefixes that are being sent out to other routers, whilst they have no communities when they are local, so the policy we applied earlier doesn’t apply to local prefixes of Customer B. and that’s when the Auto-Export feature Kicks in. ( this is an abstraction to avoid talking about how VRFs are being differentiated using RT and RDs and how MPLS exchange them)

Internal Route Leaking

JUNOS has this wonderful feature called auto-export that can be used to exchange prefixes between local VRFs. Let’s see how this works

This is how it simply works, you configure auto-export under the routing-instance you want to leak the routes FROM and then you import it on the routing instance you want the leaked routes AT

root@PE1> show configuration routing-instances CUST-B1 

instance-type vrf;

interface lo0.30;

route-distinguisher 1:202;

vrf-import CUST-B1-IMPORT;

vrf-export CUST-B1-EXPORT;

routing-options {

    auto-export;

}

policy-options {

    policy-statement CUST-A1-IMPORT {

        term 1 {

            from {

                protocol bgp;

                community CUSTA;

            }

            then accept;

        }

        term LEAK-FROM-PE2-CUSTB {

            from {

                protocol bgp;

                community CUSTB;

            }

            then accept;

        }

        term AUTOEXPORT-LOCAL-LEAKING {

            from {

                protocol direct;

                community CUSTB;

            }

            then accept;               

        }

    }

}

Now let’s the routes of Customer A on PE1

root@PE1> show route table cust-a

CUST-A1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

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

10.1.1.1/32        *[Direct/0] 01:01:46

                    > via lo0.20

10.2.2.2/32        *[BGP/170] 01:01:46, localpref 100, from 2.2.2.2

                      AS path: I

                    > to 10.0.13.3 via ge-0/0/1.0, Push 299840, Push 299792(top)

20.1.1.1/32        *[Direct/0] 00:07:00

                    > via lo0.30

20.2.2.2/32        *[BGP/170] 00:25:23, localpref 100, from 2.2.2.2

                      AS path: I

                    > to 10.0.13.3 via ge-0/0/1.0, Push 299856, Push 299792(top)

You can see now that Customer A1 can see Customer B1 routes locally as a direct routes.

In the next and final part, we'll see how we can use Static Routes and Filter Based Forwarding to achieve route leaking

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.