Cisco Prime Provisioning API Programmer Guide, 7.2

VPLS Autodiscovery Example

The following is an example of how to create a VPLS autodiscovery service order.

The relevant attribute that neesd to be set for this service order is DiscoveryMode, which is highlighted with bold in the example below. In the example, it is set to AutoDiscovery.

Example: CreateVPlsServiceOrder_ERS_NO_CE.xml

Related APIs

• CreateVPlsServiceOrder_ERS_NO_CE_IOSXR.xml

Process Summary

This VPLS 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 access domains and assign PEs to them.

8. Create customer.

9. Create sites.

10. Declare devices as CPEs (not required for service types with no CE present).

11. Assign CPE devices to sites.

12. Create named physical circuits (not required if ManualConfig=true).

13. Create VLAN ID pool.

14. Create VC ID pool.

15. Create VPN.

16. Create VPLS service definition (policy).

17. Create VPLS service request.

Prerequisites

For security reasons, Prime Provisioning requires the virtual terminal protocol (VTP) to be configured in transparent mode on all switches involved in Ethernet Relay Service (ERS) or Ethernet Wire Service (EWS) before provisioning VPLS service requests.

To set the VTP mode, enter the following Cisco IOS commands:

Enter the following Cisco IOS command to verify that the VTP has changed to transparent mode:

RBAC

Prime Provisioning uses a Cisco role-based access control (RBAC) product for user login and logoff. These user roles and permissions are set up using the GUI.

When you establish an API session, you are given a session token during the login. For each API XML request, the session token is verified against the RBAC processor to ensure that the API user has permissions for that operation. If the user does not have permissions, the API returns an error.

See the Cisco Prime Provisioning 7.2 User Guide for information on setting up user roles and permissions.

Provisioning Process

This section describes the process for provisioning VPLS using XML examples.

The complete list of XML examples for VPLS is available here:
Cisco Prime Provisioning API 7.2 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).

XML Examples:

• CreateDeviceGroup.xml

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:

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.

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.

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.

XML Examples:

CreateProvider.xml

Step 5 Create regions.

Each provider can contain multiple regions.

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

XML Examples:

CreatePE.xml

Step 7 Create access domains.

Prime Provisioning assigns a VLAN ID to the attachment circuit from the VLAN ID pool. Select all PE-POP devices to be associated with this domain, and later in the process, when VLAN ID pools are created, the PE-POP is automatically assigned a VLAN ID.

Note If provisioning for an Ethernet provider core, all PE devices must be in the same access domain and a single VLAN ID is used for the entire VPLS VPN. If provisioning for an MPLS provider core, the PE devices can be in different access domains.

XML Examples:

• CreateAccessDomain.xml

Step 8 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.

XML Examples:

• CreateOrganization.xml

Step 9 Create sites and assign customers (Organizations) to them.

XML Examples:

• CreateSite.xml

Step 10 Declare devices as CPEs. This step is not required for service subtypes with no CE present.

XML Examples:

• CreateCpe.xml

Step 11 Create Named Physical Circuits (NPCs). This step is not required if you plan to manually configure the physical links in the VPLS service request (Step 16).

Create an NPC for each attachment circuit (CE/UNI to PE-POP link). If there are intermediate devices, those links must also be added to the NPC using PhysicalLink.

Note When creating an NPC, you must specify the CPE as the source device and the PE-POP as the destination device. If there are intermediate devices, such as PE-CLEs, the source and destination devices must follow the direction of the CPE to PE-POP link.

You can create one XML request for the NamedPhysicalCircuit and include multiple PhysicalLinks as shown in the following example:

XML Examples:

• CreateNamedPhysicalCircuit.xml
• CreateNamedPhysicalCircuitRing.xml—Use this example if there is a Ring topology configuration on the PE-CLEs.
• CreateNamedPhysicalCircuitRingExisting.xml—Use this example to reference an NPC ring that has already been created.

Step 12 Create VLAN ID pool.

Create a VLAN ID pool, specify a range, and associate it to an access domain to manually enter the parameters for a VLAN ID pool. To have Prime Provisioning automatically assign VLANs to the attachment circuits, specify the Autopick_Vlan_ID keyword in the service definition (Step 15).

When provisioning for an Ethernet core, VPLS service requests use the VLAN ID to reference the attachment circuits.

XML Examples:

• CreateVlanIdPool.xml

Step 13 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).

XML Examples:

• CreateVcIdPool.xml

Step 14 Create a VPN.

When you create a VPN to use in VPLS provisioning, you must enable it to support VPLS (VplsVpn=true), and define the type of service (ERS or EWS).

Prime Provisioning assigns a VPN ID (from the VC ID pool) to each VPLS VPN.

XML Examples:

• CreateVPN.xml

Step 15 Create the VPLS service definition (policy).

A VPLS service definition specifies the core type, service subtype, device properties, and the attributes common to all attachment circuits.

Note If Autopick_Vlan_ID=true, be sure that an access domain is attached to the PE-POP, and a VLAN ID pool is assigned to the access domain (Step 7).

XML Examples:

• CreateVPLSServiceDefn_EWS.xml
• CreateVPLSServiceDefn_EWS_NO_CE.xml
• CreateVPLSServiceDefn_ERS.xml
• CreateVPLSServiceDefn_ERS_NO_CE.xml

Step 16 Create the VPLS service request.

An VPLS service request defines the service definition and VPN, assigns interfaces and attributes for each attachment circuit (VplsLink), and applies any template information.

Tip Record the LocatorId value from the XML response for the service request. The Locator ID is required for subsequent service request tasks.

XML Example:

• CreateVPLSServiceOrder_ERS.xml
• CreateVPLSServiceOrder_ERS_NO_CE.xml
• CreateVPLSServiceOrder_EWS.xml
• CreateVPLSServiceOrder_EWS_NO_CE.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.