Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Configuring Overlapping VPNs Using Automatic Route Export

A problem with multiple routing instances is how to export routes between routing instances. You can accomplish this in Junos OS by configuring routing table groups for each routing instance that needs to export routes to other routing tables. For information about how to configure overlapping VPNs by using routing table groups, see Configuring Overlapping VPNs Using Routing Table Groups.

However, using routing table groups has limitations:

  • Routing table group configuration is complex. You must define a unique routing table group for each routing instance that will export routes.
  • You must also configure a unique routing table group for each protocol that will export routes.

To limit and sometimes eliminate the need to configure routing table groups in multiple routing instance topologies, you can use the functionality provided by the auto-export statement.

The auto-export statement is particularly useful for configuring overlapping VPNs—VPN configurations where more than one VRF routing instance lists the same community route target in its vrf-import policy. The auto-export statement finds out which routing tables to export routes from and import routes to by examining the existing policy configuration.

The auto-export statement automatically exports routes between the routing instances referencing a given route target community. When the auto-export statement is configured, a VRF target tree is constructed based on the vrf-import and vrf-export policies configured on the system. If a routing instance references a route target in its vrf-import policy, the route target is added to the import list for the target. If it references a specific route target in its vrf-export policy, the route target is added to the export list for that target. Route targets where there is a single importer that matches a single exporter or with no importers or exporters are ignored.

Changes to routing tables that export route targets are tracked. When a route change occurs, the routing instance’s vpn-export policy is applied to the route. If it is allowed, the route is imported to all the import tables (subject to the vrf-import policy) of the route targets set by the export policy.

The sections that follow describe how to configure overlapping VPNs by using the auto-export statement for inter-instance export in addition to routing table groups:

Configuring Overlapping VPNs with BGP and Automatic Route Export

The following example provides the configuration for an overlapping VPN where BGP is used between the PE and CE routers.

Configure routing instance VPN-A:

[edit]
routing-instances {VPN-A {instance-type vrf;interface fe-1/0/0.0;route-distinguisher 10.255.14.175:3;vrf-import vpna-import;vrf-export vpna-export;routing-options {auto-export;}protocols {bgp {group vpna-site1 {peer-as 1;neighbor 192.168.197.141;}}}}}

Configure routing instance VPN-AB:

[edit]
routing-instances {VPN-AB {instance-type vrf;interface fe-1/1/0.0;route-distinguisher 10.255.14.175:9;vrf-import vpnab-import;vrf-export vpnab-export;routing-options {auto-export;}protocols {bgp {group vpnab-site1 {peer-as 9;neighbor 192.168.197.178;}}}}}

For this configuration, the auto-export statement replaces the functionality that was provided by a routing table group configuration. However, sometimes additional configuration is required.

Since the vrf-import policy and the vrf-export policy from which the auto-export statement deduces the import and export matrix are configured on a per-instance basis, you must be able to enable or disable them for unicast and multicast, in case multicast network layer reachability information (NLRI) is configured.

Configuring Overlapping VPNs and Additional Tables

You might need to use the auto-export statement between overlapping VPNs but require that a subset of the routes learned from a VRF table be installed into the inet.0 table or in routing-instance.inet.2.

To support this type of scenario, where not all of the information needed is present in the vrf-import and vrf-export policies, you configure an additional list of routing tables by using an additional routing table group.

To add routes from VPN-A and VPN-AB to inet.0 in the example described, you need to include the following additional configuration statements:

Configure the routing options:

[edit]
routing-options {rib-groups {inet-access {import-rib inet.0;}}}

Configure routing instance VPN-A:

[edit]
routing-instances {VPN-A {routing-options {auto-export {family inet {unicast {rib-group inet-access;}}}}}}

Configure routing instance VPN-AB:

[edit]
routing-instances {VPN-AB {routing-options {auto-export {family inet {unicast {rib-group inet-access;}}}}}}

Routing table groups are used in this configuration differently from how they are generally used in Junos OS. Routing table groups normally require that the exporting routing table be referenced as the primary import routing table in the routing table group. For this configuration, the restriction does not apply. The routing table group functions as an additional list of tables to which to export routes.

Configuring Automatic Route Export for All VRF Instances

The following configuration allows you to configure the auto-export statement for all of the routing instances in a configuration group:

[edit]
groups {vrf-export-on {routing-instances {<*> {routing-options {auto-export;}}}}}
apply-groups vrf-export-on;

Published: 2013-02-28

Published: 2013-02-28