Setting Up a Simple Layer 3 VPN

Problem

You want to set up a Layer 3 VPN for a customer who wants a private network for internal network communication and transactions.

Solution

Creating a Layer VPN for the customer involves setting up your PE and P routers. The customer (or you) can set up the customers routers (the CE routers). The PE and P routers must run an IGP, IBGP, MPLS, and a signaling protocol (RSVP or LDP). You establish an MPLS LSP between the PE routers and configure the VPN itself on the PE routers.

As a first step, set up the routing protocols necessary for the Layer 3 VPN. The PE and P routers must be running an IGP (this recipe uses OSPF). Following is the configuration for one of the PE routers, RouterG:

	[edit protocols]
	aviva@RouterG# set ospf area 0.0.0.0 interface t1-4/0/0
	aviva@RouterG# set ospf area 0.0.0.0 interface lo0.0 passive
	aviva@RouterG# set ospf area 0.0.0.0 interface fe-0/0/0 disable
	aviva@RouterG# set ospf traffic-engineering

On the PE router, enable MPLS and RSVP on the interfaces that connect to the P router:

	aviva@RouterG# set mpls interface t1-4/0/0
	aviva@RouterG# set rsvp interface t1-4/0/0

Also, remember to configure family mpls on all interfaces between the PE and P router that carry MPLS and RSVP:

	[edit interfaces]
	aviva@RouterG# set t1-4/0/0 unit 0 family mpls

The IGP, MPLS, and RSVP configuration for the other PE router, RouterF, and for the P router, RouterJ, is the same, substituting the appropriate interface names.

On each PE router, set up an IBGP session to the other PE router. For PE RouterG, the following commands set up the session:

	[edit protocols bgp group RouterG-PE-to-RouterF-PE ]
	aviva@RouterG# set type internal 
	aviva@RouterG# set local-address 192.168.19.1 
	aviva@RouterG# set neighbor 192.168.16.1 
	aviva@RouterG# set family inet-vpn unicast 

Include the equivalent configuration on the other PE router, RouterF:

	[edit protocols bgp group RouterF-PE-to-RouterG-PE ]
	aviva@RouterF# set type internal 
	aviva@RouterF# set local-address 192.168.16.1 
	aviva@RouterF# set neighbor 192.168.19.1 
	aviva@RouterF# set family inet-vpn unicast 

The second step is to create an MPLS LSP between the two PE routers to carry the VPN traffic. On RouterG, configure the LSP to RouterF:

	[edit protocols mpls]
	aviva@RouterG# set label-switched-path RouterG-PE-to-RouterF-PE to 192.168.16.1

Remember that LSPs are unidirectional, so on RouterF, which is the far-end PE router, configure a return LSP to RouterG:

	[edit protocols]
	aviva@RouterF# set label-switched-path RouterF-PE-to-RouterG-PE to 192.168.19.1

The third and final step is to configure the VPN itself. You do this by creating a routing instance for the VPN. The following commands configure the routing instance on RouterG:

	[edit routing-instances VPN2 ]
	aviva@RouterG# set instance-type vrf 
	aviva@RouterG# set interface se-5/0/1 
	aviva@RouterG# set route-distinguisher 65500:2 
	aviva@RouterG# set vrf-target target:65520:100 
	aviva@RouterG# set routing-options static route 192.168.13.1/32 next-hop se-5/0/1 

Discussion

This recipe shows how to configure a simple Layer 3 VPN for the network topology shown in Figure 15-1. In this network, a service provider connects two customer sites, Site A and Site B, with a VPN. The service provider network consists of two PE routers, RouterG and RouterF, and one internal router (the P router), RouterJ. At Site A, RouterG connects to the customers CE router, RouterA. At Site B, RouterF connects to the customers CE router, RouterD.

Figure 15-1. Simple Layer 3 VPN topology

Lets start by looking at what the service provider needs to do to support the customers VPN. For the VPN to work, you first need to configure basic routing and signaling protocols within the service provider network. An IGP must be running on the network. This recipe uses OSPF, but you can also use IS-IS (see Recipe 11.1) or RIP (see Recipe 10.1). Use the show ospf interface, show ospf neighbor, and show route table inet.0 commands to make sure that the OSPF configuration in this recipe is working as expected.

For PE RouterG, these commands confirm that OSPF is operational and that the router is learning routes from OSPF:

	aviva@RouterG> show ospf interface
	Interface State Area DR ID BDR ID Nbrs
	lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
	t1-4/0/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1

	aviva@RouterG> show ospf neighbor
	 Address Interface State ID Pri Dead
	10.0.0.2 t1-4/0/0.0 Full 192.168.17.1 128 39

	aviva@RouterG> show route table inet.0
	inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 *[Static/5] 1w1d 02:59:39
	 > to 172.19.121.1 via fe-0/0/0.0
	10.0.0.0/24 *[Direct/0] 2d 08:29:31
	 > via t1-4/0/0.0
	 [OSPF/10] 00:48:34, metric 65
	 > via t1-4/0/0.0
	10.0.0.1/32 *[Local/0] 2d 08:35:10
	 Local via t1-4/0/0.0
	10.0.8.0/24 *[OSPF/10] 00:48:34, metric 66
	 > via t1-4/0/0.0
	172.19.121.0/24 *[Direct/0] 1w1d 02:59:39
	 > via fe-0/0/0.0
	172.19.121.119/32 *[Local/0] 5w1d 03:50:24
	 Local via fe-0/0/0.0
	192.168.16.1/32 *[OSPF/10] 00:48:34, metric 66
	 > via t1-4/0/0.0
	192.168.17.1/32 *[OSPF/10] 00:48:34, metric 65
	 > via t1-4/0/0.0
	192.168.19.1/32 *[Direct/0] 2d 08:35:10
	 > via lo0.0
	224.0.0.5/32 *[OSPF/10] 1d 02:40:52, metric 1
	 MultiRecv

The JUNOS software carries the VPN traffic across an MPLS LSP between the two PE routers. For the VPN to establish itself, MPLS and a signaling protocol must be running on all interfaces participating in the LSP. This recipe uses RSVP for signaling, but you can also use LDP (see Recipe 14.1). Check on each router to verify that MPLS and RSVP are running on the expected interfaces. The following commands confirm this on RouterG:

	aviva@RouterG> show mpls interface
	Interface State Administrative 
groups
	t1-4/0/0.0 Up 

	aviva@RouterG> show rsvp interface
	RSVP interface: 1 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	t1-4/0/0.0 Up 1 100% 1.536Mbps 1.536Mbps 0bps 0bps

One last protocol that you need to set up on the PE routers is BGP. These routers need to be connected by an IBGP session that will exchange VPN routing information. Heres the IBGP configuration on PE RouterG:

	[edit protocols bgp group RouterG-PE-to-RouterF-PE ]
	aviva@RouterG# set type internal 
	aviva@RouterG# set local-address 192.168.19.1 
	aviva@RouterG#  
set neighbor 192.168.16.1 
	aviva@RouterG#  
set family inet-vpn unicast 

In the set neighbor command, use the loopback address of the other PE router, even though that router is not immediately adjacent. Here, 192.168.16.1 is the loopback address of RouterF. The set family inet-vpn unicast statement identifies that the session is for a VPN. Configure the other PE router, RouterF, in the same way.

Use the show bgp summary command to verify that the IBGP session is up:

	aviva@RouterG> show bgp summary
	Groups: 1 Peers: 1 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	 
bgp.l3vpn.0 0 0 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	192.168.16.1 65500 4627 4637 0 0 1d 14:33:01 Establ
	 bgp.l3vpn.0: 0/0/0

The first line of the output shows that RouterG is in one BGP group and has one peer, and the State column in the Peer section tells you that the IBGP session is established. However, instead of the unicast routing table inet.0, the IBGP session is using the bgp.l3vpn.0 routing table, which stores the routes learned from other PE routers. Lets look at the contents of this table:

	aviva@RouterG> show route table bgp.l3vpn.0
	aviva@RouterG>

How come there aren any entries in this table? Its because we haven yet configured the VPN itself, so the PE routers are not exchanging VPN-related routes. Well come back and look at this routing table in a little while.

The show bgp neighbor command also indicates that the IBGP session has been established:

	aviva@RouterG> show bgp neighbor
	Peer: 192.168.16.1+3136 AS 65500 Local: 192.168.19.1+179 AS 65500
	 Type: Internal State: Established Flags: 
	 Last State: OpenConfirm Last Event: RecvKeepAlive
	 Last Error: None
	 Options: 
	 Address families configured: inet-vpn-unicast
	 Local Address: 192.168.19.1 Holdtime: 90 Preference: 170
	 Number of flaps: 0
	 Peer ID: 192.168.16.1 Local ID: 192.168.19.1 Active Holdtime: 90
	 Keepalive Interval: 30 Peer index: 0
	 NLRI advertised by peer: inet-vpn-unicast
	 NLRI for this session: inet-vpn-unicast
	 Peer 
supports Refresh capability (2)
	 Table bgp.l3vpn.0
	 RIB State: BGP restart is complete
	 RIB State: VPN restart is complete
	 Send state: not advertising
	 Active prefixes: 0
	 Received prefixes: 0
	 Suppressed due to damping: 0
	 Last traffic (seconds): Received 24 Sent 6 Checked 1
	 Input messages: Total 4793 Updates 0 Refreshes 2 Octets 91101
	 Output messages: Total 4807 Updates 10 Refreshes 9 Octets 91913
	 Output Queue[0]: 0

The first two lines of the output show the peers IP address, which is RouterFs address, and that the IBGP session is established. The Address families configured line shows that this interface can process VPN-IPv4 addresses (inet-vpn-unicast). Further down in the output, you see information about the bgp.l3vpn.0 routing table.

The VPN traffic between the two sites will be carried over an MPLS LSP. In the second part of the configuration, create this LSP on the two PE routers with the set label-switched-path commands. Use the show mpls lsp command to verify that the LSP is functional. Here, we check on RouterG:

	aviva@RouterG> show mpls lsp
	Ingress LSP: 1 sessions
	To From State Rt ActivePath P LSPname
	192.168.16.1 192.168.19.1 Up 0 * RouterG-PE-to-Ro
	uterF-PE
	Total 1 displayed, Up 1, Down 0

	Egress LSP: 1 sessions
	To From State Rt Style Labelin Labelout LSPname
	192.168.19.1 192.168.16.1 Up 0 1 FF 3 - RouterF-PE-to-
	RouterG-PE
	Total 1 displayed, Up 1, Down 0

	Transit LSP: 0 sessions
	Total 0 displayed, Up 0, Down 0

The output shows what you expect. RouterG has one ingress LSP session, to RouterF, and one egress session, from RouterF.

At this point, you are ready to set up the VPN itself. Each VPN requires its own routing instance so that all information related to one VPN and its routing can be isolated from other routing and forwarding and from other VPNs that the router is managing. The set instance-type vrf command indicates the routing instance as being for a VPN and that its routes will be placed in the VRF routing table.

All routes that are part of the VPN are identified by a route distinguisher, which you define with the set route-distinguisher command:

	[edit routing-instances VPN2 ]
	aviva@RouterG# set route-distinguisher  65500:02 

You can specify the route distinguisher in two ways. This recipe uses the AS number followed by a colon and an identifying value. You can also use an IP address followed by a colon and an identifying value. Neither format is better than the other. The format you choose depends entirely on your design and specific requirements. Using the IP address:value format allows you to identify the originating PE router when you are looking at a route and its communities, because you normally set the IP portion to the PE routers lo0 address. This format can assist with troubleshooting and operational monitoring. Using the AS:value format has the advantage of leaving more space for the Administrator variable (four bytes instead of two bytes). Service providers often choose this second format, using the value field to hold a numeric customer identifier. When looking at routes, this format makes it possible, on a network-wide basis, to identify the customer associated with a route.

For the VPN to know which routes belong to it, you define a VRF target using the set vrf-target command:

	[edit routing-instances VPN2 ]
	aviva@RouterG# set vrf-target target:65520:100 

The command sets the route target (the target VPN), which is one of the BGP extended community attributes. The VRF target identifies which route belongs to which VPN and allows the VPN to accept routes into its VRF routing table and to advertise them.

The set vrf-target command also associates a default import and export policy with the VRF routing table to accept and advertise routes. The default policy uses the configured target, here 65520:100, as the match condition for routes received from remote PE routers. As the import policy states, any routes containing this target are placed into the VRF table. Similarly, when sending routes to local PE routers, the export policy is for the VPN to advertise any routes matching this target. The default routing policy is a simple policy that would look something like this if you configured it manually:

	[edit policy-options]
	aviva@RouterG# set community VPN2 members target:65500:2 

	[edit policy-options policy-statement VPN2-import-policy ]
	aviva@RouterG# set term 1 from protocol bgp 
	aviva@RouterG# set term 1 from community VPN2 
	aviva@RouterG# set term 1 then accept 
	aviva@RouterG# set term 2 then reject 

	[edit policy-options policy-statement VPN2-export-policy ]
	aviva@RouterG# set term 1 from protocol static 
	aviva@RouterG# set term 1 
then community add VPN2 
	aviva@RouterG# set term 1 then accept 
	aviva@RouterG# set term 2 then reject 

If you need more involved policies, configure them in the [edit policy-options] hierarchy and apply them to the VPN with the set vrf-import and set vrf-export commands, specifying the name of your policy. As an example, the following commands apply the VPN2-import-policy and VPN2-export-policy policies to VPN2:

	[edit routing-instances VPN2 ]
	aviva@RouterG# set vrf-import VPN2-import-policy 
	aviva@RouterG# set vrf-export VPN2-export-policy 

Finally, the VPN needs to know how to forward traffic to the CE router at the customer site. This recipe creates a static route to use for forwarding:

	[edit routing-instances VPN2 ]
	aviva@RouterG# set routing-options static route 192.168.13.1/32 next-hop se-5/0/1 

You can also use BGP, OSPF, or RIP.

Now lets verify that the VPN is operational. First, check that you can ping the CE router:

	aviva@RouterG> ping 192.168.13.1 count 5
	PING 192.168.13.1 (192.168.13.1): 56 data bytes
	^C
	--- 192.168.13.1 ping statistics --
	5 packets transmitted, 0 packets received, 100% packet loss

Why does the ping transmission fail if the static route is in the routing table? Lets check the routing tables using a different command:

	aviva@RouterG> show route 192.168.13.1 protocol static
	inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	0.0.0.0/0 	 *[Static/5] 1w1d 20:56:23
	 > to 172.19.121.1 via fe-0/0/0.0

	VPN2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	192.168.13.1/32 *[Static/5] 01:21:55
	 > via se-5/0/1.0

This command shows that the static route is present in the VPN2.inet.0 routing table but not in the inet.0 routing table. To ping it, you need to specify the VPN routing instance in the ping command:

	aviva@RouterG> ping 192.168.13.1 count 5 routing-instance VPN2
	PING 192.168.13.1 (192.168.13.1): 56 data bytes
	64 bytes from 192.168.13.1: icmp_seq=0 ttl=255 time=18.399 ms
	64 bytes from 192.168.13.1: icmp_seq=1 ttl=255 time=10.436 ms
	64 bytes from 192.168.13.1: icmp_seq=2 ttl=255 time=25.565 ms
	64 bytes from 192.168.13.1: icmp_seq=3 ttl=255 time=40.311 ms
	64 bytes from 192.168.13.1: icmp_seq=4 ttl=255 time=10.346 ms
	--- 192.168.13.1 ping statistics --
	5 packets transmitted, 5 packets received, 0% packet loss
	round-trip min/avg/max/stddev = 10.346/21.011/40.311/11.186 ms

The ping operation now succeeds, and you have verified that static routing between PE RouterG and CE RouterA is working.

Lets take a moment and look back at the IBGP session between the two PE routers. When you first configured it, the session was up, but the router had not learned any routes from BGP because the VPN itself was not yet up. Now that the VPN is up, you expect to see BGP routes. Use the show bgp summary command on PE RouterG:

	aviva@RouterG> show bgp summary
	Groups: 1 Peers: 1 Down peers: 0
	Table Tot Paths Act Paths Suppressed History Damp State Pending
	bgp.l3vpn.0 2 2 0 0 0 0
	Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#A
	ctive/Received/Damped…
	192.168.16.1 65500 5021 5034 0 0 1d 17:48:00 Establ
	 bgp.l3vpn.0: 2/2/0
	 VPN2.inet.0: 2/2/0

The last two lines show the two VPN-specific routing tables, bgp.l3vpn.0 and VPN2.inet.0 (the VRF table), both with BGP routes. Each table has two active routes and has received two routes. Recipe 15.2 explains how to view the contents of these routing tables.

See Also

Recipes 10.1, 11.1, 14.1, and 15.2