Cisco Prime Provisioning API Programmer Guide, 7.2

Devices

The inventory APIs for devices allow you to define a physical device in the Prime Provisioning repository. 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 3-1 shows the devices available as inventory objects.

Resource Pools

Resource pools allow you to manage various pool types and to associate a pool with any service model object in the Prime Provisioning repository. Pools help to automate service deployment.

Prime Provisioning supports the following resource pools:

• IP address pools—Defined and assigned to regions.
• Multicast pools—Used for multicast MPLS VPNs.
• Route Distinguisher (RD) pool—The IP subnets advertised by the CPE devices to the PE devices are augmented with a 64-bit prefix, which is the route distinguisher.
• Route Target (RT) pool—The MPLS mechanism that informs PEs which routes to insert into the appropriate VPN routing and forwarding table (VRF). Every VPN route is tagged with one or more route targets when it is exported from a VRF and offered to other VRFs.
• Site-of-origin pool—The pool of values for the site-of-origin attribute. The site-of-origin attribute prevents routing loops when a site has multiple connections to the MPLS VPN backbone.
• VLAN ID pool—VLAN ID pools are attached to an access domain. To have Prime Provisioning automatically assign VLANs to end-to-end wire links (for L2VPN provisioning), you can specify the AutoPickVlanId option.
• VC ID pool—A 32-bit identifier that is shared between the two PEs. The VC ID is a globally unique value.

Note The Modify operation is not supported with resource pools.

Table 3-2 shows the resource pools available as inventory objects.

Topology

In complex topologies, it is sometimes necessary to further define the connectivity between CE and PE devices into groups, such as CE routing communities (CERCs), virtual private networks (VPNs), and named physical circuits (NPCs).

Tip Use the Topology tool in the GUI to check CERC memberships and the resulting VPNs.

Table 3-3 shows the topology elements available as Prime Provisioning inventory objects.

Tip Use ViewVRF.xml to view the VRF routing tables.

Groupings

Prime Provisioning is designed to provision a large number of devices through its distributed architecture. Groupings are provided to simplify management tasks of devices for administrative or geographical reasons or for scalability.

• Access domain—The access domain object is associated with the provider access domain (PAD). Each PE-POP is assigned to an access domain.
• Device groups—Devices that are organized for collection and management purposes.
• Organization (Customer)— A requestor of VPN services from an Internet service provider (ISP).
• Site—A set of IP systems with mutual IP connectivity between them without the use of a VPN.
• Provider— An enterprise that provides internet services for customers.
• Region—A group of PE devices within a single border gateway protocol autonomous system (BGP AS).
• Collection zones—Collection servers are used to off load the work of the master server when the number of devices in the network increases. Network devices are associated with these collection servers using collection zones.

Table 3-4 shows the groupings as inventory objects.

Create Session Example

The following example shows the XML response to a login request. The SessionId is indicated in bold.

Delete Session Example

The following example shows the XML response to a logout request. The SessionId is indicated in bold.

Viewing a Task

To obtain information about task service requests, run a view of the task (ViewTask.xml), using the TaskLocatorId.

Use this process to retrieve the TaskLocatorId:

Step 1 Record the service order LocatorId that is returned in the XML response.

When you submit a service order XML request for any task, Prime Provisioning returns a LocatorId in the XML response. This Locator ID is associated with the service order or request Name.

Step 2 Run a view of the service order using ViewServiceOrder.xml, and the LocatorId from Step 1.

Step 3 Record the TaskLocatorId that is returned in the XML response.

Step 4 Run a view of the Task using ViewTask.xml. Specify className=PersistentTask and use the TaskLocatorId from Step 3.

The API supports the following tasks:

• Certificate Enrollment Audit
• Collection
• Service Decommission
• Configuration Audit
• Service Deployment
• MPLS Functional Audit
• MPLS Functional Audit
• SLA Collection

Certificate Enrollment Audit

A certificate enrollment audit is performed on devices to verify the certificates issued to them by a certificate authority (CA).

A certificate enrollment audit does the following:

• Verifies the certificates issued by the CA to a device or device groups.
• Confirms the presence of the root certificate and device certificate for the certificate chain of the specified trust point.
• Returns a summary that indicates the certificate enrollment status and expiration status on the audited devices.

Collection

A collection operation collects configuration information from network devices and serves the following purposes:

• It loads the current configuration information for the devices that populate many of the configuration cells.
• It verifies reachability and passwords for the devices from which it collects configuration files.

Tip Performing a device collection on your network is more accurate and efficient than manually entering individual device information.

Service Decommission

Decommissioning a service request removes a service from all devices associated with the service request.

Note To decommission a service request that includes templates, you must first negate the template information on the device. See the “Removing Template Configurations” section for more information.

During the decommission process, Prime Provisioning creates the necessary removal configuration to delete the service from each device and automatically audits the configuration to ensure that the service is completely removed. Once audited, the service request changes to a Closed 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 decommission service request is automatically audited unless this flag is changed.
• NoAudit—Do not perform a configuration audit when the decommission service request is deployed.
• ForceAudit—Perform a configuration audit even if the deployment of the decommission service request is not successful.

Configuration Audit

A configuration audit is executed as part of a service request deployment. During a configuration audit, Prime Provisioning verifies that all Cisco IOS commands are present and that they have the correct syntax. A configuration audit also verifies that there were no errors during service deployment.

Service Deployment

A service deployment downloads the Prime Provisioning-generated configlet, created for a service order, to the device configuration file.

You can specify the following options for service deployment:

• ForceDeploy—Takes a configlet for a service request that is already in the Deployed state and downloads it to the network device. Use ForceDeploy when a device configuration is lost or when you replace or change equipment.

MPLS Functional Audit

An MPLS functional audit verifies that the links in a service request or VPN are working correctly. The audit checks the routes to remote CPE devices in the VRF route tables on the PE devices.

SLA Collection

Prime Provisioning uses the Cisco SA Agent MIB to monitor service level agreement (SLA) metrics. SLAs monitor the network performance by measuring response time, jitter, connect time, throughput, and packet loss. The SA Agent allows you to configure probes for performance measurements and uses a router monitor (RTRMON) MIB for access through SNMP. The MIB also supports SNMP notifications.

An SLA collection task collects all SLA data from SLA-enabled devices. Prime Provisioning collects the relevant performance data and stores it persistently in the database. To view the data, you must execute a task to aggregate the data and run the SLA Report.

Note To collect SLA data from a device, it must have SA Agent and SNMP enabled, and SNMP parameters must already be set.

SLA collection includes performance data on Jitter (voice jitter) and the following protocols:

• Dynamic Host Configuration Protocol (DHCP)
• Domain Name System (DNS)
• File Transfer Protocol (FTP)
• Internet Control Message Protocol Echo (ICMP Echo)
• Transmission Control Protocol Connect (TCP Connect)
• User Datagram Protocol Echo (UDP Echo)
• Hypertext Transfer Protocol (HTTP)