Cisco IP Solution Center API Programmer Guide, 4.0
MPLS Provisioning
Download this chapter
MPLS ProvisioningMPLS Provisioning
Download the complete book
Cisco IP Solution Center API Programmer Guide, 4.0Cisco IP Solution Center API Programmer Guide, 4.0 (PDF - 3 MB)
 Feedback

Table Of Contents

MPLS Provisioning

MPLS Service Definitions

MPLS Policy Attributes

MPLS Service Requests

Provisioning Example

Process Summary

Create Inventory

Create Resource Pools

Collect Device Configurations

Create an MPLS Policy

Creating an MPLS Service Request

Auditing Service Requests


MPLS Provisioning

The service provider's backbone is comprised of the core provider edge (PE) device and its provider routers. An MPLS VPN consists of a set of customer sites that are interconnected through an MPLS provider core network. At each site, there are one or more customer edge (CE) devices, which attach to one or more PEs.

The Cisco IP Solution Center (ISC) provisioning engine for MPLS accesses the configuration files on both the CE and PE to compute the necessary changes to the configuration files to support the service on the PE to CE link (or PE to CLE, PE to MVRFCE to CE, or PE to MVRFCE to CLE).

This chapter describes MPLS VPN service concepts and the steps required to provision MPLS VPN services using the ISC API. The provisioning example includes the process flow from creating the inventory to auditing the service deployment.

For information on MPLS provisioning using the ISC GUI, refer to the Cisco IP Solution Center Integrated VPN Management Suite MPLS VPN User Guide, 4.0.

This chapter contains the following sections:

•MPLS Service Definitions

•MPLS Service Requests

•Provisioning Example

MPLS Service Definitions

An MPLS service definition defines attributes for the policy type (MPLSPolicyAttributes), and can include the CE routing community (CERC) membership and redistributed protocol information.

CERC membership defines the CE routing community for this policy and is represented by the VPN routing and forwarding tables (VRFs), and the redistributed protocols define the metric attributes. MPLS policy attributes are described in the MPLS Policy Attributes section.

Figure 6-1 shows the schema diagram for an MPLS service definition.

Figure 6-1 MPLS Service Definition Schema Diagram

For each service definition property, you can set an additional attribute, editable=true, to allow the network operator to override these attributes when creating the service request. If an attribute is set to editable=false, these attributes cannot be changed in the service request.

Note When a property has the additional attribute editable=true, all the related and child attributes are also editable.

See the following example: 

<objectPath xsi:type="ns1:CIMObjectPath"> 

       <className xsi:type="xsd:string">ServiceDefinitionDetails</className>  

       <properties xsi:type="ns1:CIMPropertyList" 

                   soapenc:arrayType="ns1:CIMProperty[]">  

        <item xsi:type="ns1:CIMProperty">

         <name xsi:type="xsd:string">SubType</name>

         <value xsi:type="xsd:string">PE_CE</value>

        </item>

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">PE_Intf_Type</name>

         <value xsi:type="xsd:string">GigabitEthernet</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

		<item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">PE_Intf_Desc</name>

         <value xsi:type="xsd:string">Interface Description</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

		<item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">PE_Intf_Shutdown</name>

         <value xsi:type="xsd:string">TRUE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

MPLS Policy Attributes

The MPLS policy attributes include; the policy subtype, device interfaces and encapsulation types, IP addressing schemes, routing protocols, and VPN membership information. These values are set based on the policy subtype.

ISC 3.1 supports the following MPLS policy subtypes:

•PE_CE—A standard MPLS policy for the PE_CE link. This is the default MPLS policy for ISC.

•PE_NO_CE—In this policy type, you specify only the PE interface information. The CE device at the customer location is not managed by ISC.

•PE_MVRFCE_CE—A Multi-VPN routing and forwarding CE (MVRFCE) network has multiple CE devices that connect to one MVRFCE device. The MVRFCE stores the VRFs for all VPNs in the customer network and connects directly with the PE device at the edge of the provider network. ISC manages the PE to MVRFCE to CE link.

•PE_MVRFCE_NO_CE—ISC manages the PE to MVRFCE link. The CE device at the customer site is not managed by ISC.

Note For all policy subtypes with no CE present, you do not declare the CE devices to be CPEs, and you do not set policy attributes for the CE devices in the service definition.

There are numerous properties that can be set for an MPLS policy. Figure 6-2 shows a partial schema diagram for the MPLSPolicAttributes with SubType=PE_CE.

Figure 6-2 MPLS Policy Attributes Schema Diagram

The following XML example shows a partial list of the properties that can be specified for the MplsPolicyAttributes: 

<objectPath xsi:type="ns1:CIMObjectPath"> 

          <className xsi:type="xsd:string">ServiceDefinitionDetails</className>  

          <properties xsi:type="ns1:CIMPropertyList" 

                   soapenc:arrayType="ns1:CIMProperty[]">  

            <item xsi:type="ns1:CIMProperty">

              <name xsi:type="xsd:string">SubType</name>

              <value xsi:type="xsd:string">PE_CE</value>

            </item>

              <item xsi:type="ns1:CIMProperty">

                <name xsi:type="xsd:string">PE_CE_IP_Unnumbered</name>

                <value xsi:type="xsd:string">false</value>

                <qualifier xsi:type="ns1:CIMQualifier">

                  <name xsi:type="xsd:string">editable</name>

                  <value xsi:type="xsd:string">true</value>

                </qualifier>

              </item>

              <item xsi:type="ns1:CIMProperty">

                <name xsi:type="xsd:string">IGMP_Query_Time</name>

                <value xsi:type="xsd:string">25</value>

                <qualifier xsi:type="ns1:CIMQualifier">

                  <name xsi:type="xsd:string">editable</name>

                  <value xsi:type="xsd:string">true</value>

                </qualifier>

              </item>

              <item xsi:type="ns1:CIMProperty">

                <name xsi:type="xsd:string">IGMP_Mode</name>

                <value xsi:type="xsd:string">COMPATIBLE</value>

                <qualifier xsi:type="ns1:CIMQualifier">

                  <name xsi:type="xsd:string">editable</name>

                  <value xsi:type="xsd:string">true</value>

                </qualifier>

              </item>

              <item xsi:type="ns1:CIMProperty">

                <name xsi:type="xsd:string">Overidden_Vrf_Name</name>

                <value xsi:type="xsd:string">vrf1</value>

                <qualifier xsi:type="ns1:CIMQualifier">

                  <name xsi:type="xsd:string">editable</name>

                  <value xsi:type="xsd:string">true</value>

                </qualifier>

              </item>

			 <item xsi:type="ns1:CIMProperty">

                <name xsi:type="xsd:string">Autopick_Vlan_ID</name>

                <value xsi:type="xsd:string">true</value>

                <qualifier xsi:type="ns1:CIMQualifier">

                  <name xsi:type="xsd:string">editable</name>

                  <value xsi:type="xsd:string">true</value>

                </qualifier>

              </item>

		<item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">Extra_CE_Loopback_Required</name>

         <value xsi:type="xsd:string">FALSE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">Auto_Assign_IP_Address</name>

         <value xsi:type="xsd:string">TRUE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>          

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">IP_Address_pool_type</name>

         <value xsi:type="xsd:string">Region Pool</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">PE_CE_Routing_Protocol</name>

         <value xsi:type="xsd:string">RIP</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

        <item xsi:type="ns1:CIMProperty">   

        <name xsi:type="xsd:string">Is_Default_Routes_Sent_To_CE</name>

         <value xsi:type="xsd:string">FALSE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">Redistribute_Static</name>

         <value xsi:type="xsd:string">TRUE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>        

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">Redistribute_Connected</name>

         <value xsi:type="xsd:string">TRUE</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

        <item xsi:type="ns1:CIMProperty">   

         <name xsi:type="xsd:string">Max_Routes</name>

         <value xsi:type="xsd:string">10000</value>

        <qualifier xsi:type="ns1:CIMQualifier">

            <name xsi:type="xsd:string">editable</name>

            <value xsi:type="xsd:string">true</value>

          </qualifier>

        </item>

MPLS Service Requests

An MPLS service request specifies the MPLS policy (service definition) to use, the list of links, referred to as MPLS VPN links, and the link attributes. Use the link attribute settings in the service request to override any policy settings defined as editable in the service definition.

Note You can also integrate an ISC template with an MPLS service request and associate one or more templates to the CPE and PE devices. See "Using Templates," for more information.

ISC supports an extensive list of properties that can be set for MPLS VPN links. Figure 6-3 shows a partial schema diagram for the MplsVpnLink in a service request.

Figure 6-3 MPLS VPN Link Schema Diagram

Provisioning Example

The following sections describe the required steps for using the API to provision MPLS VPNs, and include the operation, class, and required parameters for each step.

Process Summary

This MPLS provisioning example includes the following operations:

•Create Inventory

•Create Resource Pools

•Collect Device Configurations

•Create an MPLS Policy

•Creating an MPLS Service Request

This section provides an example provisioning process using XML examples. The inventory of XML examples for the ISC API can be found at the following location: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/isc/4_0/api/apiref/examples/index.htm

Create Inventory

Step 1 Create a Provider and Region.

The provider is the administrative domain of an Internet service provider (ISP), with one border gateway protocol (BGP) autonomous system (AS) number. The network owned by the provider is called the backbone network. If an ISP has two AS numbers, you must define it as two provider adrministrative domains (PADs). Each provider can contain multiple regions.

Table 6-1 Create Provider and Region

Operation
className
Required Keywords

createInstance

Provider

•Name

•AsNumber

 

Region

•Name

•Provider


XML Examples:

•CreateProvider.xml

•CreateRegion.xml

Step 2 Create a Customer (Organization) and Site.

Table 6-2 Create Customer and Site

Operation
className
Required Keywords

createInstance

Organization

•Name

 

Site

•Name

•Organization


XML Examples:

•CreateOrganization.xml

•CreateSite.xml

Step 3 Create devices.

In most cases, devices are Cisco IOS routers and Catalyst switches.

Table 6-3 Create Devices

Operation
className
Required Keywords

createInstance

•CiscoRouter

•CatOS

One or more of the following:

•ManagementIPAddress

•HostName

•DomainName


XML Examples:

•CreateCiscoRouter.xml

•CreateCat.xml

Step 4 Declare devices as PEs and assign them to regions.

Table 6-4 Create PEs

Operation
className
Required Keywords

createInstance

PE

•Provider

•Region

•Role=

–PE_POP

–PE_CLE

•Device

•Interface


XML Example:

•CreatePE.xml

Step 5 Declare devices as Cpes and assign them to sites.

When you declare a device as a Cpe, you also specify a ManagementType and interface information.

Table 6-5 Create CPEs

Operation
className
Required Keywords

createInstance

Cpe

•Site

•Device

•ManagementType


XML Example:

•CreateCpe.xml

Create Resource Pools

For MPLS provisioning, you define route targets, route distinguishers, CERCs, and VPNs.

A route target informs PEs which routes should be inserted into the appropriate VRFs. Every VPN route is tagged with one or more route targets when it is exported from a VRF and offered to other VRFs.

The IP subnets advertised by the CE routers to the PE routers are augmented with route distinguishers (RDs). The RD value must be a globally unique value to avoid conflict with other prefixes.

Table 6-6 Create Resource Pools

Operation
classNames
Required Keywords

createInstance

•RouteTarget

•RouteDistinguisher

•Start

•Size

•AssocClassType

•AssocClassId


Create a VPN and select a CERC.

Table 6-7 Create VPNs and CERCs

Operation
className
Required Parameters

createInstance

•VPN

•Name

•CERC

or

•CreateDefaultCERC

 

•CERC

•Name

•Provider

•SpokeRouteTarget

•HubRouteTarget


A CERC can either be full mesh or hub and spoke. If you specify hub and spoke, you must specify both the SpokeRouteTarget and HubRouteTarget. For a full mesh CERC, only SpokeRouteTarget is required.

XML Examples:

•CreateRouteTarget.xml

•CreateRouteDistinguisher.xml

•CreateCERC.xml

•CreateVPN.xml

Collect Device Configurations

A device configuration collection is a task. This task uploads the current configuration from the device to the ISC database. The collection task is executed through a service request, and the service request is scheduled using a service order.

Table 6-8 Collect Device Configurations

Operation
className
Required Parameters

createInstance

ServiceOrder

•ServiceName

•NumberofRequests

•ServiceRequest

 

ServiceRequest

•RequestName

•Type=Task

•ServiceRequestDetails

 

ServiceRequestDetails

•SubType=Collection

•Device (or DeviceGroup)

Note You must select at least one device or device group.

•RetrieveVersion=true

•RetrieveDeviceInterfaces=true


The following example is a partial XML request used to collect the configuration from device ensw4000-1: 

<className xsi:type="xsd:string">ServiceRequestDetails</className>

       <properties xsi:type="ns1:CIMPropertyList" 

                   soapenc:arrayType="ns1:CIMProperty[]">         

        <item xsi:type="ns1:CIMProperty">

           <name xsi:type="xsd:string">SubType</name>

           <value xsi:type="xsd:string">COLLECTION</value>

        </item>

			<item xsi:type="ns1:CIMProperty">

          <name xsi:type="xsd:string">Device</name>

          <value xsi:type="xsd:string">ensw4000-1</value>

        </item>

		 <item xsi:type="ns1:CIMProperty">

          <name xsi:type="xsd:string">DeviceGroup</name>

          <value xsi:type="xsd:string">PE-Group</value>

        </item>

        <item xsi:type="ns1:CIMProperty">

          <name xsi:type="xsd:string">RetrieveDeviceAttributes</name>

          <value xsi:type="xsd:string">true</value> </item>

        <item xsi:type="ns1:CIMProperty">

          <name xsi:type="xsd:string">RetrieveDeviceInterfaces</name>

          <value xsi:type="xsd:string">true</value> </item>

       </properties>

       </objectPath>

XML Example:

•CreateTaskServiceOrderCollection.xml

Create an MPLS Policy

An MPLS service policy (defined in a service definition) is a template of the parameters needed to define a service request. Once you define the policy template, it can be used by all MPLS service requests that share a common set of attributes.

An MPLS service definition consists of the MplsPolicyAttributes. The MplsPolicyAttributes define the properties specific to the policy subtype.

Table 6-9 Create an MPLS Policy

Operation
className
Required Parameters

createInstance

ServiceDefinition

•Name

•Type=Mpls

•ServiceDefinitionDetails

 

ServiceDefinitionDetails

•MPLSPolicyAttributes

•Provider or Organization

Note If you do not specify a Provider or Organization, the service policy becomes a global policy.

 

MPLSPolicyAttributes

•SubType=

–PE_CE

–PE_NO_CE

–PE_MVRFCE_CE

–PE_MVRFCE_NO_CE


XML Examples:

•CreateMPLSServiceDefn_PE_CE.xml

•CreateMPLSServiceDefn_PE_NO_CE.xml

•CreateMPLSServiceDefn_MVRF_CE.xml

•CreateMPLSServiceDefn_MVRF_NO_CE.xml

Creating an MPLS Service Request

An MPLS service request defines the service definition to use, the MplsVpnLink and the link attributes. The MplsVpnLink specifies the device interfaces involved in this service request. The link attributes contain any policy setting overrides for properties set as editable in the service definition. A service request can specify one or more MPLS VPN links.

Note Use performBatchOperation to group the service order and service request into one XML request.

Table 6-10 Create an MPLS Service Request

Operation
className
Required Parameters

createInstance

ServiceOrder

•ServiceName

•NumberOfRequests

•ServiceRequest

 

ServiceRequest

•RequestName

•Type=Mpls

•ServiceRequestDetails

 

ServiceRequestDetails

•ServiceDefinition

–ServiceDefinitionType=Mpls

•MplsVpnLink

 

MplsVpnLink

•NPC

or

•ManualConfig=true

–PE

–Cpe

Note You must specify either NPC or ManualConfig to define the interfaces for the MPLS VPN links. If you use ManualConfig, you must also specify the interfaces (for example, CE_Intf_Name and PE_Intf_Name).

•LinkTemplate (optional)

Note See the "Templates in a Service Request" section.


Note The attributes PE_Template, PE_Intf_Template, CE_Template, and CE_Intf_Template allow NBI access to variables designed to hold template blobs (template blobs were used during MPLS provisioning in legacy versions of ISC).

XML Examples:

•CreateMPLSServiceOrder_PE_CE.xml

•CreateMPLSServiceOrder_PE_NO_CE.xml

•CreateMPLSServiceOrder_MVFR_CE.xml

•CreateMPLSServiceOrder_MVRF_NO_CE.xml

Auditing Service Requests

A configuration audit occurs automatically each time you deploy a service request. During this configuration audit, ISC verifies that all Cisco IOS commands are present and that they have the correct syntax. An audit also verifies that there were no errors during deployment by examining the commands configured by the service request on the target devices. If the device configuration does not match what is defined in the service request, the audit flags a warning and sets the service request to a Failed Audit or Lost state.

If you do not want the configuration audit to occur, change the value for the Audit parameter. The Audit parameter supports these values:

•Audit—This is the default. A successfully deployed service request is automatically audited unless this flag is changed.

•NoAudit—Do not perform a configuration audit when the service request is deployed.

•ForceAudit—Perform a configuration audit even if the service request deployment is not successful.

You can use the Audit parameter with a Create, Modify, or Decommission service request or a Deployment task. See the "Service Decommission" section for more information. To perform a configuration audit as a separate task, or an MPLS functional audit, see the "Tasks" section.