SOURCECODEBD.NET

Live Experience

Setting Up a Simple Layer 3 VPN
 
You want to set up a Layer 3 VPN for a customer who wants a private network for internal network communication and transactions.
 
Creating a Layer VPN for the customer involves setting up your PE and P routers. The customer (or you) can set up the customer's 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, RouterB:
 
[edit protocols]
source@RouterB# set ospf area 0.0.0.0 interface so-0/0/0
source@RouterB# set ospf area 0.0.0.0 interface lo0.0 passive
source@RouterB# set ospf area 0.0.0.0 interface fe-0/0/0 disable
source@RouterB# set ospf traffic-engineering
 
On the PE router, enable MPLS and RSVP on the interfaces that connect to the P router:
 
source@RouterB# set mpls interface so-0/0/0
source@RouterB# set rsvp interface so-0/0/0
 
Also, remember to configure family mpls on all interfaces between the PE and P router that carry MPLS and RSVP:
 
[edit interfaces]
source@RouterB# set so-0/0/0 unit 0 family mpls
 
The IGP, MPLS, and RSVP configuration for the other PE router, RouterY, and for the P router, RouterH, is the same, substituting the appropriate interface names.
 
On each PE router, set up an IBGP session to the other PE router. For PE RouterB, the following commands set up the session:
 
[edit protocols bgp group RouterB-PE-to-RouterY-PE ]
source@RouterB# set type internal 
source@RouterB# set local-address 192.168.20.1 
source@RouterB# set neighbor 192.168.50.1 
source@RouterB# set family inet-vpn unicast 
 
Include the equivalent configuration on the other PE router, RouterY:
 
[edit protocols bgp group RouterY-PE-to-RouterB-PE ]
source@RouterY# set type internal 
source@RouterY# set local-address 192.168.50.1 
source@RouterY# set neighbor 192.168.20.1 
source@RouterY# 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 RouterB, configure the LSP to RouterY:
 
[edit protocols mpls]
source@RouterB# set label-switched-path RouterB-PE-to-RouterY-PE to 192.168.50.1
 
Remember that LSPs are unidirectional, so on RouterY, which is the far-end PE router, configure a return LSP to RouterB:
 
[edit protocols]
source@RouterY# set label-switched-path RouterY-PE-to-RouterB-PE to 192.168.20.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 RouterB:
 
[edit routing-instances VPN2 ]
source@RouterB# set instance-type vrf 
source@RouterB# set interface ge-1/0/0 
source@RouterB# set route-distinguisher 65500:2 
source@RouterB# set vrf-target target:65520:100 
source@RouterB# set routing-options static route 192.168.10.1/32 next-hop ge-1/0/0 
 
This diagram 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, RouterB and RouterY, and one internal router (the P router), RouterH. At Site A, RouterB connects to the customer's CE router, RouterA. At Site B, RouterY connects to the customer's CE router, RouterX.
 
 

                       Simple Layer 3 VPN topology

 
Let's start by looking at what the service provider needs to do to support the customer's 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 RouterB, these commands confirm that OSPF is operational and that the router is learning routes from OSPF:
 
source@RouterB> 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
so-0/0/0.0             PtToPt   0.0.0.0         0.0.0.0   0.0.0.0         1
 
source@RouterB> show ospf neighbor
  Address         Interface             State  ID           Pri  Dead
10.0.0.2         so-0/0/0.0             Full  192.168.30.1  128  39
 
source@RouterB> 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 so-0/0/0.0
                    [OSPF/10] 00:48:34, metric 65
                    > via so-0/0/0.0
10.0.0.1/32        *[Local/0] 2d 08:35:10
                      Local via so-0/0/0.0
10.0.8.0/24        *[OSPF/10] 00:48:34, metric 66
                    > via so-0/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.50.1/32    *[OSPF/10] 00:48:34, metric 66
                    > via so-0/0/0.0
192.168.30.1/32    *[OSPF/10] 00:48:34, metric 65
                    > via so-0/0/0.0
192.168.20.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 RouterB:
 
source@RouterB> show mpls interface
Interface            State      Administrative  
groups
so-0/0/0.0           Up         <none>
 
source@RouterB> show rsvp interface
RSVP interface:    1 active
                   Active Subscr- Static       Available   Reserved   Highwater
Interface   State  resv   iption  BW           BW          BW         mark
so-0/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. Here's the IBGP configuration on PE RouterB:
 
[edit protocols bgp group RouterB-PE-to-RouterY-PE ]
source@RouterB# set type internal 
source@RouterB# set local-address 192.168.20.1 
source@RouterB# set neighbor 192.168.50.1 
source@RouterB# 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.50.1 is the loopback address of RouterY. The set family inet-vpn unicast statement identifies that the session is for a VPN. Configure the other PE router, RouterY, in the same way.
 
Use the show bgp summary command to verify that the IBGP session is up:
 
source@RouterB> 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.50.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 RouterB 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. Let's look at the contents of this table:
 
source@RouterB> show route table bgp.l3vpn.0
source@RouterB>
 
How come there aren't any entries in this table? It's because we haven't yet configured the VPN itself, so the PE routers are not exchanging VPN-related routes. We'll 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:
 
source@RouterB> show bgp neighbor
Peer: 192.168.50.1+3136 AS 65500 Local: 192.168.20.1+179 AS 65500
  Type: Internal    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference LocalAddress HoldTime AddressFamily Rib-group Refresh>
  Address families configured: inet-vpn-unicast
  Local Address: 192.168.20.1 Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 192.168.50.1     Local ID: 192.168.20.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 peer's IP address, which is RouterY's 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 RouterB:
 
source@RouterB> show mpls lsp
Ingress LSP: 1 sessions
To              From           State Rt ActivePath     P      LSPname
192.168.50.1    192.168.20.1   Up     0                *      RouterB-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.20.1    192.168.50.1   Up     0  1 FF       3        - RouterY-PE-to-
RouterB-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. RouterB has one ingress LSP session, to RouterY, and one egress session, from RouterY.
 
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 ]
source@RouterB# 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 router's 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 ]
source@RouterB# 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]
source@RouterB# set community VPN2 members target:65500:2 
 
[edit policy-options policy-statement VPN2-import-policy ]
source@RouterB# set term 1 from protocol bgp 
source@RouterB# set term 1 from community VPN2 
source@RouterB# set term 1 then accept 
source@RouterB# set term 2 then reject 
 
[edit policy-options policy-statement VPN2-export-policy ]
source@RouterB# set term 1 from protocol static 
source@RouterB# set term 1 then community add VPN2 
source@RouterB# set term 1 then accept 
source@RouterB# 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 ]
source@RouterB# set vrf-import VPN2-import-policy 
source@RouterB# 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 ]
source@RouterB# set routing-options static route 192.168.10.1/32 next-hop ge-1/0/0 
 
You can also use BGP, OSPF, or RIP.
 
Now let's verify that the VPN is operational. First, check that you can ping the CE router:
 
source@RouterB> ping 192.168.10.1 count 5
PING 192.168.10.1 (192.168.10.1): 56 data bytes
^C
--- 192.168.10.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? Let's check the routing tables using a different command:
 
source@RouterB> show route 192.168.10.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.10.1/32     *[Static/5] 01:21:55
                   > via ge-1/0/0.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:
 
source@RouterB> ping 192.168.10.1 count 5 routing-instance VPN2
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=255 time=18.399 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=255 time=10.436 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=255 time=25.565 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=255 time=40.311 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=255 time=10.346 ms
--- 192.168.10.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 RouterB and CE RouterA is working.
 
Let's 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 RouterB:
 
source@RouterB> 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.50.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.
 
You are here: Home / Firewall & Policy / Juniper Simple Layer 3 VPN Configuration