Process Summary
This ATM Pseudowire provisioning example uses the following processes:
1. Create device groups (optional).
2. Create devices.
3. Collect device configurations.
4. Create provider.
5. Create regions.
6. Declare devices as PEs.
7. Create customer.
8. Create VC ID pool.
9. Create ATM Pseudowire service definition (policy).
10. Create ATM Pseudowire service request.
Detailed Process
This section describes the process for provisioning ATM Pseudowire using XML examples.
The complete list of XML examples for ATM Pseudowire is available here:
Cisco Prime Provisioning API 6.8 Programmer Reference
Note For clarity, this provisioning process shows each step as a separate XML request. Many of these steps can be combined using performBatchOperations.
Step 1 Create device groups (optional).
Table 11-13 Create Device Group
|
|
|
createInstance
|
DeviceGroup
|
Name
|
XML Examples:
Tip If you plan to create device groups, create the empty device groups before you create the devices. As you create each device, add the associated device group name as a key property in the create device XML request.
In the following example, the device group (CustDev) is added as a key property when creating the device CiscoRouter:
<objectPath xsi:type="ns1:CIMObjectPath"> <className xsi:type="xsd:string">CiscoRouter</className> <properties xsi:type="ns1:CIMPropertyList" soapenc:arrayType="ns1:CIMProperty[]"> <item xsi:type="ns1:CIMProperty"> <name xsi:type="xsd:string">DeviceGroup</name> <value xsi:type="xsd:string">CustDev</value> <item xsi:type="ns1:CIMProperty"> <name xsi:type="xsd:string">CfgUpDnldMech</name> <value xsi:type="xsd:string">DEFAULT</value> <item xsi:type="ns1:CIMProperty"> <name xsi:type="xsd:string">TransportMechanism</name> <value xsi:type="xsd:string">DEFAULT</value> <item xsi:type="ns1:CIMProperty"> <name xsi:type="xsd:string">Password</name> <value xsi:type="xsd:string">vpnsc</value>
Step 2 Create devices.
Every network element that Prime Provisioning manages must be defined as a device in the system. An element is any device from which Prime Provisioning can collect configuration information.
Table 11-14 Create Devices
|
|
|
createInstance
|
|
One or more of the following:
-
ManagementIPAddress
-
HostName
-
DomainName
|
XML Examples:
-
CreateCiscoRouter.xml
-
CreateCat.xml
Step 3 Collect device configurations.
A device configuration collection is a task. This task uploads the current configuration from the device to the Prime Provisioning database. The collection task is executed through a service request, and the service request is scheduled through a service order.
Note The service request name must be unique for each NBI API.
Table 11-15 Collect Device Configurations
|
|
|
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.
-
RetreiveVersion=true
-
RetreiveDeviceInterfaces=true
|
XML Examples:
-
CreateTaskServiceOrderCollection.xml
Step 4 Create a provider.
The provider is the administrative domain of an ISP, with one 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 administrative domains.
Table 11-16 Create a Provider
|
|
|
createInstance
|
Provider
|
|
XML Examples:
CreateProvider.xml
Step 5 Create regions.
Each provider can contain multiple regions.
Table 11-17 Create Regions
|
|
|
createInstance
|
Region
|
|
XML Examples:
CreateRegion.xml
Step 6 Declare devices as PEs.
The XML request that assigns a PE role to a device is also used to:
-
Assign PE devices to Regions/Provider
-
Specify interface information
Table 11-18 Create PE Devices
|
|
|
createInstance
|
PE
|
– N-PE
|
XML Examples:
CreatePE.xml
Step 7 Create a customer.
A customer is a requestor of VPN services. Each customer can contain multiple customer sites. Each site belongs to only one customer and can contain multiple CPEs.
Table 11-19 Create Organization
|
|
|
createInstance
|
Organization
|
|
XML Examples:
Step 8 Create VC ID pool.
For a VPLS VPN, all PE-POP routers use the same VC ID to establish the virtual circuit (VC) across the provider core. The VC ID is also the VPN ID and is assigned from the VC ID pool. Prime Provisioning ensures that VC IDs are unique among VPLS VPNs.
Note A VC ID pool is global (not associated with a provider or organization).
Table 11-20 Create VC ID Pool
|
|
|
createInstance
|
VcIdPool
|
|
XML Examples:
Step 9 Create ATM Pseudowire service definition (policy).
A ATM Pseudowire service definition specifies the service subtype, device properties, and the attributes common to all attachment circuits.
Table 11-21 Create a ATM Pseudowire Service Definition
|
|
|
createInstance
|
ServiceDefinition
|
-
Name
-
Type=EvcIpran
-
Provider or Organization
Note If you do not specify a Provider or Organization, the service policy is global
|
|
ServiceDefinitionDetails
|
– AccessType = ATM
– TransportType = PSEUDOWIRE
– AtmTransportMode
– AutopickVCId
– EnablePWRedundancy
– UsePwClass
|
XML Examples:
Step 10 Create ATM Pseudowire service request.
A ATM Pseudowire service request defines the service definition and assigns interfaces and attributes.
Table 11-22 Create a ATM Pseudowire Service Request
|
|
|
createInstance
|
ServiceOrder
|
-
ServiceName
-
NumberOfRequests
-
Provider or Organization
Note If you do not specify a Provider or Organization, the service policy is global.
|
|
ServiceRequest
|
-
RequestName
-
Type=EvcIpran
-
ServiceRequestDetails
|
|
ServiceRequestDetails
|
– ServiceDefinitionType= EvcIpran
-
VCID
-
BackupVCID
-
MCPTTimer1
-
MCPTTimer2
-
MCPTTimer3
-
Npe
-
UniInftId
-
Terminal
-
AtmInterfaceEncapType
-
AtmTransportMode
-
AtmSubInterfaceNumber
-
PVPVPINumber
-
PVPVCINumber
-
MaxCells
-
MCPTTimerToUse
-
UsePwClass
-
PwClassName
-
UseBackPwClass - Only if PW Redundancy needs to be created
-
BackPwClassName - Only if PW Redundancy needs to be created
|
Tip Record the LocatorId value from the XML response for the service request. The Locator ID is required for subsequent service request tasks.
XML Examples:
-
CreateATM_IMA_PVP_SR_PW.xml
-
CreateATM_IMA_PVP_SR_PWRedundancy.xml (only if PW redundancy needs to be created for ATM IMA PVP Service)
-
CreateATM_IMA_VCC_SR_PW.xml
-
CreateATM_IMA_VCC_SR_PWRedundancy.xml (only if PW redundancy needs to be created for ATM IMA VCC Service)
-
CreateIPRAN_ATM_SR_IOS_XR.xml
Auditing Service Requests
A configuration audit occurs automatically each time you deploy a service request. During this configuration audit, Prime Provisioning 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, see the “Configuration Audit” section.