-
Cisco IP Solution Center MPLS VPN User Guide, 3.0
-
Index
-
About This Guide
-
About Cisco IP Solutions Center
-
Setting Up the Network for ISC
-
Discovering the Network
-
Defining MPLS VPN Service Policies
-
Managing MPLS VPN Service Requests
-
Mapping IPsec to MPLS VPN
-
The ISC Management Network
-
Provisioning MPLS VPN Cable Services
-
Service Request Transition States
-
Table Of Contents
Marking a CE's Private Interface
IPsec Remote Access VPN Policy
Network-Based IPsec vs. Regular IPsec Policy
Site-to-Site IPsec Tunnels: One-Box Solution
Create a PE-CE Link with No Routing
No Routing: Create a Network-Based IPsec Policy
No Routing: Create an MPLS Policy
No Routing: Create an IPsec Service Request
No Routing: Create an MPLS Service Request
No Routing: Deploy the IPsec and MPLS Service Requests
Create a PE-CE Link with Routing Enabled
Routing: Mark a PE IPsec Private Interface
Routing: Create a Network-Based IPsec + GRE Policy
Routing: Create an MPLS Policy
Routing: Create an IPsec Service Request
Routing: Create an MPLS Service Request
Routing: Deploy the Service Requests
Site-to-Site IPsec Tunnels: Two-Box Solution
Create a PE to Multi-VRF CE to CE Link with No Routing
Multi-VRF No Routing: Create a Network-Based IPsec Policy
Multi-VRF No Routing: Create an MPLS Policy
Multi-VRF No Routing: Create an IPsec Service Request
Multi-VRF No Routing: Create an MPLS Service Request
Multi-VRF No Routing: Deploy the IPsec and MPLS Service Requests
Create a PE to Multi-VRF CE to CE Link with Routing Enabled
Multi-VRF with Routing: Mark the Multi-VRF CE's IPsec Private Interface
Multi-VRF with Routing: Create a Network-Based IPsec + GRE Policy
Multi-VRF with Routing: Create an MPLS Policy
Multi-VRF with Routing: Create an IPsec Service Request
Multi-VRF with Routing: Create an MPLS Service Request
Multi-VRF with Routing: Deploy the IPsec and MPLS Service Requests
Remote Access IPsec Tunnels: One-Box Solution
Create an IPsec Remote Access Policy
Create a Remote Access MPLS Policy
Create an IPsec Remote Access Service Request
Create an MPLS Remote Access Service Request
Deploy the IPsec and MPLS Remote Access Service Requests
Remote Access IPsec: Two-Box Solution
Create an IPsec Remote Access Policy
Create a Remote Access MPLS Multi-VRF CE Policy
Create an IPsec Remote Access Multi-VRF CE Service Request
Create an MPLS Remote Access Multi-VRF CE Service Request
Deploy the IPsec and MPLS Remote Access Service Requests
Mapping IPsec to MPLS VPN
This chapter describes how to use Cisco IP Solution Center (ISC) to map IPsec tunnels to MPLS VPNs. The following sections are included:
•
Site-to-Site IPsec Tunnels: One-Box Solution
•
•
•
•
•
•
•
Introduction
Provisioning network-based IPsec VPNs in order to map IPsec tunnels to MPLS VPNs involves both MPLS and IPsec services in IP Solutions Center. Thus, it is necessary to create both MPLS and IPsec policies, as well as MPLS and IPsec service requests.
The IPsec terminating router resides on the service provider premises. IPsec tunnels from various customers are aggregated on this router. This may be either a PE router or a Multi-VRF CE router. Depending on which type of device is employed, the IPsec- to-MPLS mapping is either the "one-box" solution or a "two-box" solution. In the "one-box" solution, the service provider uses a PE router as the IPsec aggregator (for details, see the "Site-to-Site IPsec Tunnels: One-Box Solution" section). In the "two-box" solution, the service provider uses a multi-VRF CE router for IPsec aggregation in conjunction with a PE router (see the "Site-to-Site IPsec Tunnels: Two-Box Solution" section).
Two types of IPsec tunnels can be terminated on the IPsec aggregator (the IPsec aggregator device can be either a PE or a Multi-VRF CE router):
•
•
Public and Private Interfaces
The interface on which IPsec tunnels terminate is known as the public interface. The interface behind which customer subnets reside is known as the private interface.
The PE or the Multi-VRF CE router must be running Cisco IOS release 12.2(15)T or above. ISC supports VRF-aware IPsec, which is the key feature required for mapping IPsec tunnels into MPLS VPNs.
Both the PE and CE must at least one interface marked as their public interface. It is assumed that public interfaces on the PE and CE already exist. Moreover, it is assumed that the PE and CE have basic IPv4 connectivity, that is, they can both ping each other using the public interface's IP address. Please note that ISC will not create any new subinterfaces on the PE or CE for IPsec termination. ISC provisions IPsec tunnels that terminate on existing public interfaces.
Marking a PE Public Interface
Public and private interfaces for each PE and CE must be marked prior to using them in IPsec service requests. Each PE must have a public interface. You can mark the interfaces either by using the Inventory Manager at the time the devices are imported into the ISC Repository, or by using the CPE Editor as described in this section.
The PE may or may not have a private interface. If no routing protocol is to be configured over the IPsec tunnel between the PE and CE, the PE does not need to have a private interface.
Note
To mark a PE public interfaces:
Step 1
Step 2
Step 3
The list of PE devices is displayed.
Step 4
The Edit CPE Device dialog box appears (see Figure 6-1).
Figure 6-1 Marking the IPsec Interfaces of a PE
Step 5
Step 6
Step 7
Marking a CE's Private Interface
A CE must have at least one private interface. When an interface on a CE is marked private, ISC automatically creates a subnet and associates it with the CE. A CE has one or more subnets residing behind it, that is, on the private side. These subnets are ones that IPsec protects. The list of subnets behind a CE can be edited—for example, new subnets can be added to the list, or the automatically generated subnet can be edited or removed.
To mark a CE's private interface:
Step 1
Step 2
Step 3
The list of CPE devices is displayed.
Step 4
The Edit CPE Device dialog box appears (see Figure 6-2).
Figure 6-2 Marking the IPsec Interfaces of a CE
Step 5
Step 6
IPsec Policies
There are three types of IPsec policies available in ISC:
•
•
•
IPsec Encryption Policy
An IPsec Encryption policy defines the security parameters for protecting the data traveling through the IPsec tunnels (see Figure 6-3). It consists of one or more IKE proposals, one or more IPsec proposals, and some global attributes.
For example, a typical IPsec Encryption policy would consist of the following elements:
•
•
•
Figure 6-3 IPsec Encryption Policy
IPsec Site-to-Site VPN Policy
An IPsec Site-to-Site VPN policy defines the characteristics of the site-to-site IPsec VPN, for example, whether the tunnels are IPsec tunnels or GRE tunnels + IPsec, whether a routing protocol is running over the tunnels, and so on. A site-to-site VPN policy uses an IPsec encryption policy (see Figure 6-4).
Figure 6-4 IPsec Site-to-Site Policy
IPsec Remote Access VPN Policy
An IPsec Remote Access VPN policy defines the characteristics of a Remote Access IPsec VPN, for example, the group name and group password, address pool, split tunneling subnets, and so on. An IPsec Remote Access VPN Policy uses an IPsec Encryption Policy (see Figure 6-5).
Figure 6-5 IPsec Remote Access VPN Policy
Network-Based IPsec vs. Regular IPsec Policy
It is important to select the IPsec policy type Network-based VPN instead of the standard site-to-site VPN policy. There are four variations of standard site-to-site VPN policies, as well as two variations of network-based VPN policies. Pure IPsec policy and IPsec + GRE policy options are available in both network-based policies and standard site-to-site policies.
Populating the Inventory
The major set of tasks required to populate the Inventory are as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Site-to-Site IPsec Tunnels: One-Box Solution
Site-to-site IPsec tunnels are typically used with MPLs VPNs where a customer has an existing VPN and a number of "off-net" sites. These off-net sites have access to the Internet, but not to the service provider's MPLS core. An IPsec tunnel between the off-net CE router and the service provider's IPsec aggregator router over the Internet enables the off-net site to join an existing MPLS VPN.
It is possible to map IPsec tunnels into MPLS VPNs because of VRF-aware IPsec, in which each IPsec tunnel is mapped to a VRF based on a peer IP address or a Group name.
In the one-box solution, the service provider is terminating the IPsec tunnels on a PE router. Thus, the PE serves as the IPsec aggregator, terminating IPsec tunnels from the customers' off-net CEs (see Figure 6-6). Note that the Cisco VPN Client is also known as the Unity Client.
Figure 6-6 PE Serving as an IPsec Aggregator
In effect, the service provider creates an MPLS link between the PE and CE, but this link is actually an IPsec tunnel rather than a traditional MPLS link. This can be achieved by using ISC to create both an MPLS link and an IPsec tunnel between the PE and CE.
An IPsec site-to-site policy defines the attributes of the IPsec tunnel between the PE and CE. For example, it defines whether Reverse Route Injection should be enabled, whether NAT Transparency should be enabled, the routing protocol to be used, and so on. Reverse Route Injection is used to populate the routing table of an internal router running Open Shortest Path First (OSPF) protocol or Routing Information Protocol (RIP) for remote VPN clients or site-to-site sessions.
Similarly, an MPLS policy defines the attributes of the link between the PE and CE. For example, it defines the details of the routing protocol between the PE and CE.
In order to provision an IPsec tunnel between a PE and CE, you must perform the following tasks:
1.
2.
3.
4.
5.
6.
7.
Routing Options
You can configure the IPsec tunnel between the PE and CE to either run a routing protocol or no routing. Before proceeding any further, you must decide whether you want to use the no routing option or prefer to have a routing protocol enabled over the tunnel between the PE and the CE. Depending on which option you choose, you would have to use a different IPsec policy as described in Table 6-1.
The supported routing options are:
•
•
•
Depending on the routing option chosen, you must use a different site-to-site IPsec policy (see Table 6-1). There are two types of Network-based IPsec policies available:
•
•
Create a PE-CE Link with No Routing
The steps to create a PE-CE link with No Routing specified are as follows:
•
•
•
•
•
No Routing: Create a Network-Based IPsec Policy
When it is necessary to run no routing protocols between the PE and CE, you must use a network-based IPsec policy instead of a GRE + IPsec policy.
Step 1
The Policy Manager appears (see Figure 6-7).
Figure 6-7 Creating a New Service Policy
Step 2
The IPsec Policy Create page appears.
Step 3
The IPsec Network Based Policy dialog box appears (see Figure 6-8).
Figure 6-8 IPsec Network-Based Policy
Step 4
a.
b.
c.
d.
When this option is enabled, static routes to the CEs are injected into the corresponding VRF on the PE upon establishment of the IPsec tunnels. These routes can, in turn, be redistributed into MP-BGP thereby propagating them to all the other MPLS PEs.
e.
When the No Routing option is selected in the service request, it is important to enter one or more subnets for the summarized addresses attribute. Because a PE is shared by many customers, it does have the concept of private subnets residing behind it; instead, a set of MPLS VPNs reside behind a PE. For each customer's IPsec policy, these VPNs are defined as a list of summarized IP addresses. This list is needed in order to define the interesting traffic that needs to travel through the IPsec tunnel.
f.
Step 5
No Routing: Create an MPLS Policy
Provisioning an MPLS VPN begins with defining a service policy. A service policy can be applied to multiple PE-CE links in a single service request. For details on this process, see the "Creating Service Policies" section.
To create an MPLS policy for this link, follow these steps:
Step 1
The Policy Manager appears.
Step 2
The MPLS Policy Type dialog box appears (see Figure 6-9).
Figure 6-9 Creating a Regular PE-CE MPLS Policy
Step 3
a.
b.
c.
d.
e.
Step 4
Step 5
Step 6
Figure 6-10 Specifying the Routing Information in the MPLS Policy
Step 7
a.
b.
c.
The VRF and VPN Membership dialog box appears (see Figure 6-11).
Figure 6-11 Specifying the VRF and VPN Membership Information in the MPLS Policy
Step 8
It provides the most flexibility to not select any CERCs in the service policy itself (as shown in Figure 6-11), since you can assign the CERCs when the operator creates the MPLS service request.
No Routing: Create an IPsec Service Request
To create a new IPsec service request, follow these steps:
Step 1
a.
b.
The Service Requests dialog box appears (see Figure 6-12).
Figure 6-12 Initial Service Requests Dialog Box
Step 2
A drop-down list is displayed, showing the types of service requests you can create.
Step 3
The Select IPsec Policy dialog box appears. This dialog box displays the list of all the IPsec service policies that have been defined in ISC.
Step 4
The IPsec Service Editor appears (see Figure 6-13).
Figure 6-13 Creating an IPsec to MPLS Mapping Service Request
Step 5
Step 6
a.
b.
Step 7
The Policy Chooser window displays only the network-based policies owned by the current customer (see Figure 6-14).
Figure 6-14 IPsec Policy Chooser
a.
You return to the IPsec Service Editor.
Step 8
a.
The IPsec PE Chooser is displayed (see Figure 6-15).
Figure 6-15 IPsec PE Chooser
b.
You return to the IPsec Service Editor.
c.
The IPsec CPE Chooser is displayed (see Figure 6-16).
Figure 6-16 IPsec CPE Chooser
d.
You return to the IPsec Service Editor.
The PE will automatically be marked as the hub. When all the CEs are added to the service request, you can save the service request.
e.
The IPsec Service Editor displays the settings you have specified for the IPsec service (see Figure 6-17).
Figure 6-17 IPsec Service Request Defined
No Routing: Create an MPLS Service Request
The next step is to create an MPLS service request. Because the procedures for creating MPLS service requests are fully described in the previous chapter, this section summarizes the main tasks. For details on this process, see the "Creating Service Requests" section.
Step 1
a.
b.
The Service Requests dialog box appears (see Figure 6-18).
Figure 6-18 Initial Service Requests Dialog Box
Step 2
A drop-down list is displayed, showing the types of service requests you can create.
Step 3
The Select MPLS Policy dialog box appears (see Figure 6-19).
This dialog box displays the list of all the MPLS service policies that have been defined in ISC.
Figure 6-19 Selecting the MPLS Policy for This Service
Step 4
The MPLS Service Request Editor appears (see Figure 6-20).
Figure 6-20 MPLS Service Request Editor
Step 5
The MPLS Service Request Editor now displays a set of fields, as shown in Figure 6-21. Notice that the Select CE field is enabled. Specifying the CE for the link is the first task required to define the link for this service.
Figure 6-21 Initial Fields Displayed to Define the PE-CE Link
Step 6
The Select CPE Device dialog box is displayed (see Figure 6-22).
Figure 6-22 Selecting the CE for the MPLS Link
Step 7
Step 8
Figure 6-23 CE and CE Interface Fields Defined
This CE interface must be the interface that has already been marked as an IPsec public interface.
If the CE's public interface is a subinterface, select the major interface for that subinterface.
Step 9
The Select PE Device dialog box is displayed.
Step 10
Step 11
Note
If the PE public interface is a subinterface, select the major interface.
Figure 6-24 PE Selected and PE Interface Defined
Step 12
The MPLS Link Attribute Editor is displayed, showing the fields for the interface parameters (see Figure 6-25).
Figure 6-25 Confirming the PE and CE Interfaces' IPsec Attributes
In this dialog box, only interface names for the PE and CE should be displayed. Next to each interface, you should see "(IPsec public interface)".
Note
Entering a Subinterface Number
If the public interface for the PE or CE is a subinterface, you must type in the subinterface number in the Interface Name field, then press Tab. When you press Tab, all attributes except for Interface Name will disappear, and the string "(IPsec public interface)" will be displayed next to the subinterface name.
For example, let's assume that the IPsec public interface for CE 5 is its Serial1/0.100 subinterface. When the operator gets to the PE-CE Interface dialog box, he would see the screen shown in Figure 6-26:
Figure 6-26 Specifying the Subinterface Number
–
The PE-CE Interface dialog box automatically updates as shown in Figure 6-27:
Figure 6-27 Subinterface Number Specified for Interface
Thus, all the fields except for Interface Name are removed from the dialog box, and the subinterface now displays the appropriate "IPsec public interface" label.
Step 13
The MPLS Link Attribute Editor for the IP Address Scheme appears.
The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the IP address scheme fields, see the "Specifying the IP Address Scheme" section.
Step 14
The MPLS Link Attribute Editor for Routing Information appears (see Figure 6-28).
Figure 6-28 Specifying the MPLS Link Routing Protocol Attributes
The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the routing information for the PE and CE, see the "Specifying the Routing Protocol for a Service" section.
Because the service policy used for this service specified the routing protocol as editable, you can change the routing protocol for this service request as needed.
Step 15
The MPLS Link Attribute Editor for the VRF and VPN attributes appears (see Figure 6-29).
Figure 6-29 Specifying the MPLS Link VRF and VPN Attributes
The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the VRF and VPN information, see the "Defining the Service Policy VRF and VPN Information" section.
Step 16
The CERC Chooser dialog box appears (see Figure 6-30).
Figure 6-30 Specifying the CERC for the MPLS Link
a.
b.
c.
d.
e.
Your CERC selection is added to the VRF and VPN page.
Step 17
Step 18
No Routing: Deploy the IPsec and MPLS Service Requests
Tip
To deploy the IPsec and MPLS service requests:
Step 1
Step 2
Step 3
The Service Requests dialog box appears.
Step 4
Step 5
The Deploy Service Requests dialog box appears, which allows you to schedule when you want to deploy the selected service request.
Step 6
Step 7
You return to the Service Requests dialog box. Check the Status display in the lower left corner of the window. If the service request has been deployed successfully, the Status display appears as shown in Figure 6-31.
Figure 6-31 Status for Successful Deployment
Step 8
Create a PE-CE Link with Routing Enabled
You can configure the IPsec tunnel between the PE and CE to either run a routing protocol or no routing. If a static route or a routing protocol is desired between the PE and CE, you should use the GRE + IPsec policy.
If the service provider chooses the configure the IPsec tunnel with routing, the options are as follows:
•
•
•
•
Routing: Mark a PE IPsec Private Interface
To provision static routes or a dynamic routing protocol for the PE-CE IPsec link, GRE tunnels are necessary. ISC automatically creates these Tunnel interfaces on both the PE and CE and makes them IP unnumbered. For this purpose, you must mark a loopback interface on the PE as an IPsec private interface.
The loopback interface marked as an IPsec private interface can have a nonroutable IP address. This IP address appears in Network statement of the selected routing protocol, which will in effect enable the selected routing protocol on all the GRE Tunnel interfaces, unnumbered with the loopback interface with that IP address.
To mark a PE IPsec interface as private, follow these steps:
Step 1
Step 2
Step 3
The Edit PE Devices dialog box is displayed (see Figure 6-32).
Figure 6-32 Marking the PE Loopback Interface as Private
Observe the entry for the Loopback0 interface.
Step 4
Routing: Create a Network-Based IPsec + GRE Policy
When routing is enabled between the PE and CE, you must use the IPsec + GRE IPsec policy, instead of the Pure IPsec policy.
GRE (Generic Routing Encapsulation) is a tunneling protocol developed by Cisco Systems that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers over an IP network. Ip tunneling using GRE provides a way to connect multiprotocol subnetworks across a single-protocol backbone.
To create a network-based IPsec + GRE policy:
Step 1
The Policy Manager appears.
Step 2
The IPsec Policy Create page appears.
Step 3
The IPsec + GRE Network Based Policy dialog box appears (see Figure 6-33).
Figure 6-33 IPsec + GRE Policy for a Routing Link
Step 4
a.
b.
c.
d.
e.
For each customer's IPsec policy, this VPN is defined as a list of summarized IP addresses. This list of subnets is used to generate static routes on the spokes pointing to the GRE tunnel that terminates on the PE.
f.
Step 5
Routing: Create an MPLS Policy
You can either use a new MPLS policy with the Routing option set to Static, EIGRP, RIPv2, or OSPF, or you can use an existing MPLS policy.
If you use an existing MPLS policy, change the routing protocol to the desired option when you create the MPLS service request.
Routing: Create an IPsec Service Request
This step is identical to the previous case (see the "No Routing: Create an IPsec Service Request" section), with the exception that you must select a Network-based IPsec + GRE policy for the IPsec service request.
The routing protocol is either already set to the desired option in the IPsec policy, or you can set it to the desired option in the IPsec service request.
When you specify a routing protocol such as EIGRP, RIPv2, or OSPF in the IPsec service request, you must select the same routing protocol in the corresponding MPLS service request.
Routing: Create an MPLS Service Request
This step is identical to the "No Routing: Create an MPLS Service Request" section. The routing protocol is either already set to the desired option in the MPLS policy, or you can set it to the desired option in the MPLS service request.
When you specify a routing protocol such as EIGRP, RIPv2, or OSPF in the MPLS service request, you must specify the same routing protocol in the corresponding IPsec service request. In the example shown in Figure 6-33, EIGRP is specified in the IPsec service request, so the MPLS service request also uses EIGRP as the routing protocol. Notice the extra parameters that need to be specified for EIGRP (see Figure 6-34).
Figure 6-34 EIGRP Parameters for the MPLS Service Request
Routing: Deploy the Service Requests
It is important to deploy the IPsec service request before you deploy the MPLS service request because there are commands generated by the IPsec service request that the MPLS service request depends on.
Site-to-Site IPsec Tunnels: Two-Box Solution
In the two-box solution, there is an IPsec tunnel between the off-net CE and a Multi-VRF CE. The Multi-VRF CE is connected to a PE (see Figure 6-35). The IPsec aggregator in the two-box solution is the Multi-VRF CE. IPsec tunnels from the off-net CEs terminate on a single interface on the Multi-VRF CE. VRF-aware IPsec maps each IPsec tunnel to the corresponding VRF on the Multi-VRF CE.
The PE-facing interfaces are each in a customer's VRF, and the PE-facing interfaces connect to an interface on the PE, which itself is in a customer VRF.
Figure 6-35 Multi-VRF CE Serving as an IPsec Aggregator
Links to Be Provisioned
In effect, the service provider creates an MPLS link between the PE and Multi-VRF CE, and then creates another link between the off-net CE and the Multi-VRF CE. The latter link is actually an IPsec tunnel rather than a traditional MPLS link. This can be achieved by using ISC to create both an MPLS link and an IPsec tunnel between the Multi-VRF CE and the off-net CE.
In other words, there are really two links involved in this process, as shown in Figure 6-35:
•
•
Tasks to Be Completed
To provision these two links between the off-net CE, the Multi-VRF CE, and the PE, the following tasks are required:
1.
2.
3.
4.
5.
6.
7.
Define the Multi-VRF CE
In the two-box solution, all the IPsec tunnels terminate on the Multi-VRF CE public interface. It is important to ensure the Multi-VRF CE is set up correctly in ISC. To begin with, the CE management type for this device must be set to Multi-VRF.
To define a device as a Multi-VRF CE:
Step 1
Step 2
Step 3
The Customers dialog box is displayed, along with the TOC (see Figure 6-36).
Figure 6-36 Customers Dialog Box and TOC
Step 4
ISC presents the list of CPE devices (see Figure 6-37).
Figure 6-37 List of CPE Devices
Step 5
The Edit CPE Device dialog box is displayed (see Figure 6-38).
Figure 6-38 Specifying the CPE Management Type
Step 6
Step 7
The selected device is now defined as a Multi-VRF CE.
Step 8
Multi-VRF CE Routing Options
You can configure the IPsec tunnel between the off-net CE and the Multi-VRF CE to either run a routing protocol or no routing. Before proceeding any further, you must decide whether you want to use the no routing option or prefer to have a routing protocol enabled over the tunnel between the Multi-VRF CE and the off-net CE. Depending on your choice, you would apply a different IPsec policy, as described in Table 6-2.
The supported routing options are:
•
•
•
Depending on the routing option chosen, you must use a different site-to-site IPsec policy (see Table 6-1). There are two types of Network-based IPsec policies available:
•
•
The link between the Multi-VRF CE and the PE can be running the same or a different routing protocol as the other link. This option is completely under the control of the MPLS service request and has no corresponding requirements on the IPsec side.
Create a PE to Multi-VRF CE to CE Link with No Routing
The steps to create a Multi-VRF CE to CE link with No Routing specified are as follows:
•
•
•
•
•
Multi-VRF No Routing: Create a Network-Based IPsec Policy
When it is necessary to run no routing protocols between the Multi-VRF CE and off-net CE, you must use the Pure IPsec policy, instead of the GRE + IPsec policy.
Step 1
The Policy Manager dialog box appears.
Step 2
The IPsec Policy Create page appears.
Step 3
The IPsec Network Based Policy dialog box appears (see Figure 6-39).
Figure 6-39 Creating an IPsec Network-Based Policy
Step 4
a.
b.
c.
d.
When this option is enabled, static routes to the CEs are injected into the corresponding VRF on the Multi-VRF CE upon establishment of the IPsec tunnels. These routes can, in turn, be redistributed into the routing protocol running over the link between the Multi-VRF CE and the PE, which then redistributes them into MP-BGP.
e.
When the No Routing option is selected in the service request, you must enter one or more subnets for the Summarized Addresses for MPLS VPN attribute. Because the Multi-VRF CE is shared by many customers, it does not have the concept of private subnets residing behind it; instead, a set of MPLS links to a PE reside behind a Multi-VRF CE, which in turn map to a set of customer VPNs. For each customer's IPsec policy, this VPN is defined as a list of summarized IP addresses. This list is needed in order to define the interesting traffic that needs to travel through the IPsec tunnel.
f.
Step 5
Multi-VRF No Routing: Create an MPLS Policy
For this Multi-VRF CE policy, be sure to both set the Policy Type to MVRFCE: PE-CE (by default, the Policy Type is Regular: PE-CE), and enable the CE Present option.
To create an MPLS policy for the CE-Multi-VRF CE-PE links:
Step 1
The Policy Manager appears.
Step 2
The MPLS Policy Type dialog box appears (see Figure 6-40).
Figure 6-40 Creating a Multi-VRF PE to CE Policy
Step 3
a.
b.
c.
d.
e.
Step 4
The Multi-VRF CE PE Interface dialog box is displayed (see Figure 6-41).
This is a standard MPLS link. You have the option of either specifying a specific PE interface type in the policy or keeping it open and making the final PE interface selection when the operator creates the MPLS service request.
Figure 6-41 Specifying the Multi-VRF PE Interface Parameters
Step 5
For details on these parameters, see the "Specifying the PE and CE Interface Parameters" section.
The Multi-VRF-CE CE Interface dialog appears (see Figure 6-42).
Figure 6-42 Specifying the Multi-VRF CE Interface Parameters
Step 6
The IP Address Scheme for the PE to Multi-VRF CE link dialog box appears (see Figure 6-43).
The link represented in this dialog is an IPsec tunnel.
Figure 6-43 Specifying the IP Address Scheme for the PE to Multi-VRF CE Link
Step 7
For information on these parameters, see the "Specifying the IP Address Scheme" section.
The IP Address Scheme for the Multi-VRF CE to the CE link dialog box appears (see Figure 6-44).
Figure 6-44 Specifying the IP Address Scheme for the Multi-VRF CE to the CE Link
