Supported Platforms
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.
Figure 1: Example of an Overlapping VPN Topology
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
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-vpnab installs routes into routing tables VPN-A.inet.0 and VPN-AB.inet.0.
- vpnb-vpnab installs routes into routing tables VPN-B.inet.0 and VPN-AB.inet.0.
- vpnab-vpna_and_vpnb installs routes into routing tables VPN-AB.inet.0, VPN-A.inet.0, and VPN-B.inet.0.
Configure the routing table groups:
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:
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:
In this configuration, the following static routes are installed in the VPN-AB.inet.0 routing table:
- 10.255.14.185/32 is for Router CE2 (in VPN AB)
- 10.255.14.155/32 is for Router CE1 (in VPN A)
- 10.255.14.186/32 is 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:
When you configure the routing instance for VPN B, these static routes are placed in VPNB.inet.0:
- 10.255.14.186/32 is for Router CE3 (in VPN B)
- 10.255.14.185/32 is 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:
On Router PE1, apply the VPN import and export policies:
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:
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:
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:
