6 mins read
L3VPN – auto-export
1. Intro
The auto-export statement enables you to leak routes between VRF instances that are locally configured on a PE router. Auto export is always applied on the local PE router, because it applies to only local prefix leaking by evaluating the export policy of each VRF and determining which route targets can be leaked. In contrast, remote PE prefix leaking which works by default with the standard VRF import and export policies).
To enable auto-export functionality, you need to configure auto-export on both export and import routing instance to leak routes from export routing instance to import routing instance.
We recommend you to consider your design requirements because when you add auto-export on the import routing instance, the import routing instance also exports its own routes to other routing instance with same import route-targets (RT), which may lead to unwanted route leaks. To prevent unwanted route leaks, use the VRF import and export policies to manipulate route-targets attached to the routes.
We will use the following topology to configure and test the auto-export feature. R1 and R8 are our PEs for the two L3VPNs that will exchange prefixes. The core network was already fully configured (MPLS, MP-BGP, etc), so we will ignore all of this. We will go straight to our L3VPNs and configure them to locally exchange prefixes:
The initial config:
### The initial R1 config (which is similar on R8):
set routing-instances Cust-A instance-type vrf
set routing-instances Cust-A interface lo0.100
set routing-instances Cust-A route-distinguisher 17.0.0.1:100
set routing-instances Cust-A vrf-import Cust-A-import
set routing-instances Cust-A vrf-export Cust-A-export
set routing-instances Cust-A vrf-table-label
set routing-instances Cust-B instance-type vrf
set routing-instances Cust-B interface lo0.200
set routing-instances Cust-B route-distinguisher 17.0.0.1:200
set routing-instances Cust-B vrf-import Cust-B-import
set routing-instances Cust-B vrf-export Cust-B-export
set routing-instances Cust-B vrf-table-label
set policy-options policy-statement Cust-A-export then community add RT-Cust-A
set policy-options policy-statement Cust-A-export then accept
set policy-options policy-statement Cust-A-import term Cust-A from community RT-Cust-A
set policy-options policy-statement Cust-A-import term Cust-A from route-filter 192.100.0.0/16 prefix-length-range /24-/24
set policy-options policy-statement Cust-A-import term Cust-A then accept
set policy-options policy-statement Cust-A-import then reject
set policy-options policy-statement Cust-B-export then community add RT-Cust-B
set policy-options policy-statement Cust-B-export then accept
set policy-options policy-statement Cust-B-import term Cust-B from community RT-Cust-B
set policy-options policy-statement Cust-B-import term Cust-B from route-filter 192.200.0.0/16 prefix-length-range /24-/24
set policy-options policy-statement Cust-B-import term Cust-B then accept
set policy-options policy-statement Cust-B-import then reject
### The routing tables are as follows:
root@R1# run show route table Cust-A.inet.0
Cust-A.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.1.0/24 *[Direct/0] 20:54:32
> via lo0.100
192.100.1.1/32 *[Local/0] 20:54:32
Local via lo0.100
192.100.8.0/24 *[BGP/170] 20:45:16, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
root@R1# run show route table Cust-B.inet.0
Cust-B.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.200.1.0/24 *[Direct/0] 20:48:05
> via lo0.200
192.200.1.1/32 *[Local/0] 20:48:05
Local via lo0.200
192.200.8.0/24 *[BGP/170] 20:45:13, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
2. Configuration
We will update our VRF policies for route leaking:
### Add the RT communities for route leaking:
set policy-options policy-statement Cust-A-import term Cust-B from community RT-Cust-B
set policy-options policy-statement Cust-A-import term Cust-B from route-filter 192.200.0.0/16 prefix-length-range /24-/24
set policy-options policy-statement Cust-A-import term Cust-B then accept
set policy-options policy-statement Cust-B-import term Cust-A from community RT-Cust-A
set policy-options policy-statement Cust-B-import term Cust-A from route-filter 192.100.0.0/16 prefix-length-range /24-/24
set policy-options policy-statement Cust-B-import term Cust-A then accept
### We can see that just manipulating the VRF policies, (by default) we can do Remote Route Leaking.
### The key word here is 'Remote'. The 2 VRFs are exchanging prefixes but only remote R8 prefixes.
### - Cust-A table has a remote Cust-B prefix from R8
### - Cust-B table has a remote Cust-A prefix from R8
root@R1# run show route table Cust-A.inet.0
Cust-A.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.1.0/24 *[Direct/0] 21:07:54
> via lo0.100
192.100.1.1/32 *[Local/0] 21:07:54
Local via lo0.100
192.100.8.0/24 *[BGP/170] 20:58:38, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.8.0/24 *[BGP/170] 00:02:18, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
root@R1# run show route table Cust-B.inet.0
Cust-B.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.8.0/24 *[BGP/170] 00:00:11, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.1.0/24 *[Direct/0] 21:01:20
> via lo0.200
192.200.1.1/32 *[Local/0] 21:01:20
Local via lo0.200
192.200.8.0/24 *[BGP/170] 20:58:28, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
### If we want Local Route leaking, then this is where we need to configure auto-export.
### Let us configure the VRFs one by one. First we configure Cust-A VRF:
root@R1# set routing-instances Cust-A routing-options auto-export
### Nothing happens:
root@R1# run show route table Cust-A.inet.0
Cust-A.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.1.0/24 *[Direct/0] 21:28:04
> via lo0.100
192.100.1.1/32 *[Local/0] 21:28:04
Local via lo0.100
192.100.8.0/24 *[BGP/170] 21:18:48, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.8.0/24 *[BGP/170] 00:22:28, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
root@R1# run show route table Cust-B.inet.0
Cust-B.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.8.0/24 *[BGP/170] 00:20:25, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.1.0/24 *[Direct/0] 21:21:34
> via lo0.200
192.200.1.1/32 *[Local/0] 21:21:34
Local via lo0.200
192.200.8.0/24 *[BGP/170] 21:18:42, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
### Let's do the same for the other VRF as well:
root@R1# set routing-instances Cust-B routing-options auto-export
### Now we see Local Route Leaking:
root@R1# run show route table Cust-A.inet.0
Cust-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.1.0/24 *[Direct/0] 21:40:04
> via lo0.100
192.100.1.1/32 *[Local/0] 21:40:04
Local via lo0.100
192.100.8.0/24 *[BGP/170] 21:30:48, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.1.0/24 *[Direct/0] 00:01:06
> via lo0.200
192.200.8.0/24 *[BGP/170] 00:34:28, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
root@R1# run show route table Cust-B.inet.0
Cust-B.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.100.1.0/24 *[Direct/0] 00:01:11
> via lo0.100
192.100.8.0/24 *[BGP/170] 00:32:21, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 25, Push 801008(top)
192.200.1.0/24 *[Direct/0] 21:33:30
> via lo0.200
192.200.1.1/32 *[Local/0] 21:33:30
Local via lo0.200
192.200.8.0/24 *[BGP/170] 21:30:38, localpref 100, from 17.0.0.4
AS path: I, validation-state: unverified
> to 17.1.3.3 via ge-0/0/2.0, Push 38, Push 801008(top)
To conclude, as the documentation is saying, we need to configure auto-export on both VRF to make it work.
External Resources: