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
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:
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.
Recipes 10.1, 11.1, 14.1, and 15.2See Also
Категории