Overlapping VPNs
Configuring Overlapping VPNs Using Routing Table Groups
In Layer 3 VPNs, a CE router is often a member of more than one VPN. This example illustrates how to configure PE routers that support CE routers that support multiple VPNs. Support for this type of configuration uses a Junos OS feature called routing table groups (sometimes also called routing information base [RIB] groups), which allows a route to be installed into several routing tables. A routing table group is a list of routing tables into which the protocol should install its routes.
You define routing table groups at the [edit routing-options] hierarchy level for the default instance. You cannot configure routing
table groups at the [edit routing-instances routing-options] hierarchy level; doing so results in a commit error.
After you define a routing table group, it can be used by multiple protocols. You can also apply routing table groups to static routing. The configuration examples in this section include both types of configurations.
Figure 1 illustrates the topology for the configuration example in this section. The configurations in this section illustrate local connectivity between CE routers connected to the same PE router. If Router PE1 were connected only to Router CE2 (VPN AB), there would be no need for any extra configuration. The configuration statements in the sections that follow enable VPN AB Router CE2 to communicate with VPN A Router CE1 and VPN B Router CE3, which are directly connected to Router PE1. VPN routes that originate from the remote PE routers (the PE2 router in this case) are placed in a global Layer 3 VPN routing table (bgp.l3vpn.inet.0), and routes with appropriate route targets are imported into the routing tables as dictated by the VRF import policy configuration. The goal is to be able to choose routes from individual VPN routing tables that are locally populated.
Router PE1 is where all the filtering and configuration modification takes place. Therefore only VPN configurations for PE1 are shown. The CE routers do not have any information about the VPN, so you can configure them normally.
The following sections explain several ways to configure overlapping VPNs.
The following sections illustrate different scenarios for configuring overlapping VPNs, depending on the routing protocol used between the PE and CE routers. For all of these examples, you need to configure routing table groups.
- Configuring Routing Table Groups
- Configuring Static Routes Between the PE and CE Routers
- Configuring BGP Between the PE and CE Routers
- Configuring OSPF Between the PE and CE Routers
- Configuring Static, BGP, and OSPF Routes Between PE and CE Routers
Configuring Routing Table Groups
In this example, routing table groups are common in the four configuration scenarios. The routing table groups are used to install routes (including interface, static, OSPF, and BGP routes) into several routing tables for the default and other instances. In the routing table group definition, the first routing table is called the primary routing table. (Normally, the primary routing table is the table into which the route would be installed if you did not configure routing table groups. The other routing tables are called secondary routing tables.)
The routing table groups in this configuration install routes as follows:
vpna-vpnabinstalls routes into routing tables VPN-A.inet.0 and VPN-AB.inet.0.vpnb-vpnabinstalls routes into routing tables VPN-B.inet.0 and VPN-AB.inet.0.vpnab-vpna_and_vpnbinstalls routes into routing tables VPN-AB.inet.0, VPN-A.inet.0, and VPN-B.inet.0.
Configure the routing table groups:
[edit]
routing-options {
rib-groups {
vpna-vpnab {
import-rib [ VPN-A.inet.0 VPN-AB.inet.0 ];
}
vpnb-vpnab {
import-rib [ VPN-B.inet.0 VPN-AB.inet.0 ];
}
vpnab-vpna_and_vpnb {
import-rib [ VPN-AB.inet.0 VPN-A.inet.0 VPN-B.inet.0 ];
}
}
}
Configuring Static Routes Between the PE and CE Routers
To configure static routing between the PE1 router and the CE1, CE2, and CE3 routers, you must configure routing instances for VPN A, VPN B, and VPN AB (you configure static routing under each instance):
- Configuring the Routing Instance for VPN A
- Configuring the Routing Instance for VPN AB
- Configuring the Routing Instance for VPN B
- Configuring VPN Policy
Configuring the Routing Instance for VPN A
On Router PE1, configure 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 {
interface-routes {
rib-group inet vpna-vpnab;
}
static {
route 10.255.14.155/32 next-hop 192.168.197.141;
route 10.255.14.185/32 next-hop 192.168.197.178;
}
}
}
}
The interface-routes statement installs VPN A’s
interface routes into the routing tables defined in the routing table
group vpna-vpnab.
The static statement configures the static routes
that are installed in the VPN-A.inet.0 routing table. The first static
route is for Router CE1 (VPN A) and the second is for Router
CE2 (in VPN AB).
Next hop 192.168.197.178 is not in VPN A. Route 10.255.14.185/32 cannot be installed in VPN-A.inet.0 unless
interface routes from routing instance VPN AB are installed in this
routing table. Including the interface-routes statements
in the VPN AB configuration provides this next hop. Similarly,
including the interface-routes statement in the VPN AB
configuration installs 192.168.197.141 into VPN-AB.inet.0.
Configuring the Routing Instance for VPN AB
On Router PE1, configure 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 {
interface-routes {
rib-group vpnab-vpna_and_vpnb;
}
static {
route 10.255.14.185/32 next-hop 192.168.197.178;
route 10.255.14.155/32 next-hop 192.168.197.141;
route 10.255.14.186/32 next-hop 192.168.197.242;
}
}
}
}
In this configuration, the following static routes are installed in the VPN-AB.inet.0 routing table:
10.255.14.185/32is for Router CE2 (in VPN AB)10.255.14.155/32is for Router CE1 (in VPN A)10.255.14.186/32is for Router CE3 (in VPN B)
Next hops 192.168.197.141 and 192.168.197.242 do not belong to VPN AB. Routes 10.255.14.155/32 and 10.255.14.186/32 cannot be installed in VPN-AB.inet.0 unless
interface routes from VPN A and VPN B are installed in this
routing table. The interface route configurations in VPN A and
VPN B routing instances provide these next hops.
Configuring the Routing Instance for VPN B
On Router PE1, configure VPN B:
[edit]
routing instances {
VPN-B {
instance-type vrf;
interface fe-1/0/2.0;
route-distinguisher 10.255.14.175:10;
vrf-import vpnb-import;
vrf-export vpnb-export;
routing-options {
interface-routes {
rib-group inet vpnb-vpnab;
}
static {
route 10.255.14.186/32 next-hop 192.168.197.242;
route 10.255.14.185/32 next-hop 192.168.197.178;
}
}
}
}
When you configure the routing instance for VPN B, these static routes are placed in VPNB.inet.0:
10.255.14.186/32is for Router CE3 (in VPN B)10.255.14.185/32is for Router CE2 (in VPN AB)
Next hop 192.168.197.178 does not belong to VPN B.
Route 10.255.14.185/32 cannot be installed in VPN-B.inet.0
unless interface routes from VPN AB are installed in this routing
table. The interface route configuration in VPN AB provides this
next hop.
Configuring VPN Policy
The vrf-import and vrf-export policy statements
that you configure for overlapping VPNs are the same as policy statements
for regular VPNs, except that you include the from interface statement in each VRF export policy. This statement forces each
VPN to announce only those routes that originated from that VPN. For
example, VPN A has routes that originated in VPN A and VPN AB.
If you do not include the from interface statement, VPN A
announces its own routes as well as VPN AB’s routes, so
the remote PE router receives multiple announcements for the same
routes. Including the from interface statement restricts
each VPN to announcing only the routes it originated and allows you
to filter out the routes imported from other routing tables for local
connectivity.
In this configuration example, the vpnab-import policy
accepts routes from VPN A, VPN B, and VPN AB. The vpna-export policy exports only routes that originate in VPN A. Similarly,
the vpnb-export and vpnab-export policies export
only routes that originate within the respective VPNs.
On Router PE1, configure the following VPN import and export policies:
[edit]
policy-options {
policy-statement vpna-import {
term a {
from {
protocol bgp;
community VPNA-comm;
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpnb-import {
term a {
from {
protocol bgp;
community VPNB-comm;
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpnab-import {
term a {
from {
protocol bgp;
community [ VPNA-comm VPNB-comm ];
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpna-export {
term a {
from {
protocol static;
interface fe-1/0/0.0;
}
then {
community add VPNA-comm;
accept;
}
}
term b {
then reject;
}
}
policy-statement vpnb-export {
term a {
from {
protocol static;
interface fe-1/0/2.0;
}
then {
community add VPNB-comm;
accept;
}
}
term b {
then reject;
}
}
policy-statement vpnab-export {
term a {
from {
protocol static;
interface fe-1/1/0.0;
}
then {
community add VPNB-comm;
community add VPNA-comm;
accept;
}
}
term b {
then reject;
}
}
community VPNA-comm members target:69:1;
community VPNB-comm members target:69:2;
}
On Router PE1, apply the VPN import and export policies:
[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 {
static {
rib-group vpna-vpnab;
route 10.255.14.155/32 next-hop 192.168.197.141;
route 10.255.14.185/32 next-hop 192.168.197.178;
}
}
}
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 {
static {
rib-group vpnab-vpna_and_vpnb;
route 10.255.14.185/32 next-hop 192.168.197.178;
}
}
}
VPN-B {
instance-type vrf;
interface fe-1/0/2.0;
route-distinguisher 10.255.14.175:10;
vrf-import vpnb-import;
vrf-export vpnb-export;
routing-options {
static {
rib-group vpnb-vpnab;
route 10.255.14.186/32 next-hop 192.168.197.242;
}
}
}
}
For VPN A, include the routing-options statement
at the [edit routing-instances routing-instance-name] hierarchy level to install the static routes directly into
the routing tables defined in the routing table group vpna-vpnab. For VPN AB, the configuration installs the static route directly
into the routing tables defined in the routing table group vpnab-vpna and vpnab-vpnb. For VPN B the configuration installs
the static route directly into the routing tables defined in the routing
table group vpnb-vpnab.
Configuring BGP Between the PE and CE Routers
In this configuration example, the vpna-site1 BGP
group for VPN A installs the routes learned from the BGP session into
the routing tables defined in the vpna-vpnab routing table
group. For VPN AB, the vpnab-site1 group installs the routes
learned from the BGP session into the routing tables defined in the vpnab-vpna_and_vpnb routing table group. For VPN B, the vpnb-site1 group installs the routes learned from the BGP session
into the routing tables defined in the vpnb-vpnab routing
table group. Interface routes are not needed for this configuration.
The VRF import and export policies are similar to those defined
in Configuring Static Routes Between the PE and CE Routers,
except the export protocol is BGP instead of a static route. On all vrf-export policies, you use the from protocol bgp statement.
On Router PE1, configure BGP between the PE and CE routers:
[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;
protocols {
bgp {
group vpna-site1 {
family inet {
unicast {
rib-group vpna-vpnab;
}
}
peer-as 1;
neighbor 192.168.197.141;
}
}
}
}
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;
protocols {
bgp {
group vpnab-site1 {
family inet {
unicast {
rib-group vpnab-vpna_and_vpnb;
}
}
peer-as 9;
neighbor 192.168.197.178;
}
}
}
}
VPN-B {
instance-type vrf;
interface fe-1/0/2.0;
route-distinguisher 10.255.14.175:10;
vrf-import vpnb-import;
vrf-export vpnb-export;
protocols {
bgp {
group vpnb-site1 {
family inet {
unicast {
rib-group vpnb-vpnab;
}
}
neighbor 192.168.197.242 {
peer-as 10;
}
}
}
}
}
}
Configuring OSPF Between the PE and CE Routers
In this configuration example, routes learned from the OSPF
session for VPN A are installed into the routing tables defined in
the vpna-vpnab routing table group. For VPN AB, routes
learned from the OSPF session are installed into the routing tables
defined in the vpnab-vpna_and_vpnb routing table group.
For VPN B, routes learned from the OSPF session are installed into
the routing tables defined in the vpnb-vpnab routing table
group.
The VRF import and export policies are similar to those defined
in Configuring Static Routes Between the PE and CE Routers and Configuring BGP Between the PE and CE Routers,
except the export protocol is OSPF instead of BGP or a static route.
Therefore, on all vrf-export policies, you use the from protocol ospf statement instead of the from protocol <static | bgp> statement.
On Router PE1, configure OSPF between the PE and CE routers:
[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;
protocols {
ospf {
rib-group vpna-vpnab;
export vpna-import;
area 0.0.0.0 {
interface fe-1/0/0.0;
}
}
}
}
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;
protocols {
ospf {
rib-group vpnab-vpna_and_vpnb;
export vpnab-import;
area 0.0.0.0 {
interface fe-1/1/0.0;
}
}
}
}
VPN-B {
instance-type vrf;
interface fe-1/0/2.0;
route-distinguisher 10.255.14.175:10;
vrf-import vpnb-import;
vrf-export vpnb-export;
protocols {
ospf {
rib-group vpnb-vpnab;
export vpnb-import;
area 0.0.0.0 {
interface fe-1/0/2.0;
}
}
}
}
}
Configuring Static, BGP, and OSPF Routes Between PE and CE Routers
This section shows how to configure the routes between the PE and CE routers by using a combination of static routes, BGP, and OSPF:
The connection between Router PE1 and Router CE1 uses static routing.
The connection between Router PE1 and Router CE2 uses BGP.
The connection between Router PE1 and Router CE3 uses OSPF.
Here, the configuration for VPN AB also includes a static route to CE1.
On Router PE1, configure a combination of static routing, BGP, and OSPF between the PE and CE routers:
[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 {
static {
rib-group vpna-vpnab;
route 10.255.14.155/32 next-hop 192.168.197.141;
}
}
}
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;
protocols {
bgp {
group vpnab-site1 {
family inet {
unicast {
rib-group vpnab-vpna_and_vpnb;
}
}
export to-vpnab-site1;
peer-as 9;
neighbor 192.168.197.178;
}
}
}
}
VPN-B {
instance-type vrf;
interface fe-1/0/2.0;
route-distinguisher 10.255.14.175:10;
vrf-import vpnb-import;
vrf-export vpnb-export;
protocols {
ospf {
rib-group vpnb-vpnab;
export vpnb-import;
area 0.0.0.1 {
interface t3-0/3/3.0;
}
}
}
}
}
policy-options {
policy-statement to-vpnab-site1 {
term a {
from protocol static;
then accept;
}
term b {
from protocol bgp;
then accept;
}
term c {
then reject;
}
}
}
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
- Configuring Overlapping VPNs and Additional Tables
- Configuring Automatic Route Export for All VRF Instances
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;