Adding a VPN for a Second Customer
Configure the VPN for the second customer on the PE router:
source@RouterB# set routing-options protocols bgp group VPN1-group neighbor 10.0.40.1
Have the customer configure an EBGP session on her CE router that connects to your PE router:
source@RouterC# set neighbor 10.0.40.2
From a service provider point of view, the whole point of Layer 3 VPNs is to allow a single edge router in your network to provide services to a number of different customers and to isolate each customer’s network so that all information pertaining to it remains private. When configuring the PE router, you set up the router to keep each customer’s routing information in separate routing tables and you establish unique route distinguishers so that the PE routers can identify which routes belong to which VPNs.
This recipe shows how to add a VPN called VPN1 for a second customer. Figure 15-2 shows the network topology with both customers’ VPNs.
Layer 3 VPNs for two customers
Configuring the VPN for the second customer is somewhat simpler than for the first customer. An IGP, MPLS, and RSVP are already up and running on the PE and P routers, and the LSP between the two PE routers is already operational. What remains to be done is to configure the VPN itself. This VPN, named VPN1, connects to the CE routers using BGP rather than static routes. The following commands set the basic properties of VPN1:
source@RouterB# set vrf-target target:65530:200
The first command defines the routing instance type, which must be vrf for Layer 3 VPNs. The PE router connects to the CE router using interface ge-3/0/0. Each VPN must use a different route distinguisher and VRF target. VPN1 has a route distinguisher of 65500:1 and a VRF target of 65530:200. The VRF target attached to a route shows the VPN to which a route belongs.
Next, configure the EBGP session to the CE router. You do this within the VPN routing instance, not in the [edit protocols bgp] configuration hierarchy, because you are creating an instance of BGP that the JUNOS software associates with the VPN. The configuration commands in this recipe are also used to create a regular EBGP session, but they are included within the VPN at the [edit routing-instance VPN1 protocols bgp] hierarchy level. Here’s what the completed configuration looks like on the router:
}
The BGP configuration establishes an external (EBGP) session with the neighbor 10.0.40.1 (the interface address of the CE router) that is in AS 65530.
For the VPN to work, the customer controlling the CE router, must establish an EBGP session with the PE router. On the CE router, the customer sets up a regular BGP session, configured at the [edit protocols bgp] hierarchy (see Recipe 13.1) and not part of a routing instance. Here’s what the configuration on the CE router in this recipe looks like:
}
autonomous-system 65530;
}
As a first step in verifying the configuration, make sure that the EBGP session between the PE and CE routers is established. Check on the CE router:
0/0/0
The CE router has one BGP session to 10.0.40.2, the PE router. This is a regular EBGP session, and routes are placed in the inet.0 unicast routing table.
Checking on the PE router shows the BGP neighbors:
VPN1.inet.0: 0/0/0
The last entry shows that the EBGP session to 10.0.40.1, the CE router, is established and that its routes are in the VPN1.inet.0 routing table.
VPN1 also has a CE router (RouterZ) at the remote site that is connected to the remote PE router, RouterY. You configure these two routers the same way as the two routers shown in this recipe. Here’s the VPN1 routing-instance configuration on the remote PE router, RouterY:
}
Now check the routing tables on the PE router. First, let’s look at the VRF table for VPN1, which is VPN1.inet.0:
> via so-0/0/0.0, label-switched-path RouterB-PE-to-RouterY-PE
This table stores the routes for VPN1:
10.0.40.0/24 and 10.0.40.2/32 are the routes to the CE router, RouterC.
10.0.50.0/24 is the subnet to the remote VPN1 CE router (RouterZ), which has a router address of 192.168.70.1/32.
If the VPN1.inet.0 table truly isolates the routes for VPN1 so they are not visible to other VPNs or routers on the network, you expect that these routes are not in any of the other routing tables. To verify this, look at the other routing tables on the PE router. Here is the inet.0 unicast routing table:
MultiRecv
This table has no knowledge of the 10.0.40.1/24 or 10.0.50.1/24 subnets, nor does it know about the two VPN1 CE routers, 192.168.60.1 and 192.168.70.1.
The VPN2 routing table also knows nothing about these prefixes:
> via so-0/0/0.0, label-switched-path RouterB-PE-to-RouterY-PE
A shortcut to verify that the VPN1 routes are only in the VPN1.inet.0 table is to look for routes to a prefix that you know is in this table:
> to 172.19.121.1 via fe-0/0/0.0
> via ge-3/0/0.0
This output confirms that the route to the VPN1 subnet to the CE RouterC is present only in the VPN1.inet.0 table. The inet.0 table has no information about this route and uses the default route to try to reach it.
Next, check the bgp.l3vpn.0 routing table, which stores the routes received from other PE routers:
> via so-0/0/0.0, label-switched-path RouterB-PE-to-RouterY-PE
The PE router is now receiving routes from the remote PE router for both VPNs. The routes for VPN1 use the route distinguisher 65500:4, and the second two routes in the bgp.l3vpn.0 table are for VPN1. The first route, for IP prefix 10.0.50.0/24, is the subnet between the remote PE and CE routers, and the second route is to the CE router itself. These two prefixes match those contained in the VPN1.inet.0 table. The other two routes in the bgp.l3vpn.0 table use the route distinguisher 65500:3, which is for VPN2.
Let’s also look at all the routing tables on the CE router to see what they contain:
> via lo0.16385
What you see here is that the CE router is just a regular router. The only routing table it has is the inet.0 unicast routing table (and the private inet.0 table that is used internally by the JUNOS software). The CE router has no knowledge of the VPN. It has a route to the PE router using the prefix 10.0.40.0/24. [Direct/0], which indicates that the CE router is directly connected to the PE router. The CE router also has a route to the subnet between the remote PE router and the remote PE router, 10.0.50.0/24, which it learned from its EBGP session with PE RouterB. It’s important to note that the CE router does not have any prefixes to reach any of the routers in VPN2. There is no prefix for CE RouterA (router address 192.168.10.1, on subnet 10.0.10.0/24), which is directly connected to PE RouterB, and there is no prefix to the remote VPN2 CE RouterX (address 192.168.40.1, subnet 10.0.20.0/24).
Just to make sure that prefixes are not leaking between VPNs, look at the routing tables on the VPN2 CE RouterA:
> via lo0.16385
The router has prefixes to reach the PE router (over the subnet 10.0.10.0/24) but has no knowledge of the VPN1 CE router, RouterC.