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