- Preface
- Introduction to the Prime Provisioning API
- Getting Started
- Common APIs
- Using Templates
- Monitoring APIs
- MPLS Provisioning
- L2VPN Provisioning
- VPLS Provisioning
- EVC Provisioning
- Traffic Engineering Management Provisioning
- RAN Backhaul Provisioning
- MPLS Transport Profile Provisioning
- GUI to API Mapping
- Implementing a Notification Server
- Scripts
- Prime Provisioning XDE SDK
VPLS Provisioning
Cisco Prime Provisioning supports layer 2 provisioning with layer 2 Virtual Private Network (L2VPN) services and Virtual Private LAN services (VPLS). VPLS services are multipoint (L2VPN are point-to-point) and include Ethernet services over a Multiprotocol Label Switching (MPLS) core or over an Ethernet core.
With an MPLS-based provider core, the PE devices forward customer Ethernet traffic through the core using a VPLS VPN. Multiple attachment circuits are joined together by the provider core and simulate a virtual bridge that connects all the attachment circuits together.
With an Ethernet-based provider core, the PE devices connect two or more customer devices using 802.1Q-in-Q tag-stacking technology, which encapsulates traffic from multiple VLANs from one customer with a single service provider tag. All connections within the VPLS VPN are peers and have direct communications, like a distributed switch.
For each of the core types, Prime Provisioning supports Ethernet relay service (ERS) and multipoint Ethernet wire service (EWS).
- ERS—The PE device forwards all Ethernet packets with a particular VLAN tag received from an attachment circuit (excluding bridge protocol data units (BPDUs)), to another attachment circuit.
- EWS—The PE device forwards all Ethernet packets received from an attachment circuit (including tagged (DOT1Q), untagged (DEFAULT), and BPDUs), to either another attachment circuit or to all attachment circuits.
To provision VPLS using the Prime Provisioning API, you need a VPLS service definition and a VPLS service request. The service definition specifies the core type, policy subtype, and common device properties. The service request defines the service definition to use, VPNs, attributes for each interface in the VPLS link, and template information.
In addition, you can now use autodiscovery to discover all VPLS autodiscovery-enabled devices.
This chapter describes VPLS service concepts and the steps required to provision VPLS services using the Prime Provisioning API. The provisioning example includes all steps from creating the inventory to auditing the service deployment.
For more information on VPLS provisioning using Prime Provisioning, see the Cisco Prime Provisioning 7.0 User Guide .
VPLS Service Definitions
A VPLS service definition specifies the core type, policy subtype, device properties, and the attributes common to all attachment circuits.
Prime Provisioning supports the following:
Note For all service definition subtypes with NO_CE, you do not declare the CE devices to be CPEs and you set policy attributes for the PE and the UNI (the PE-POP or PE-CLE).
– MPLS—provider core network is MPLS-enabled
– Ethernet—provider core network uses Ethernet switches
– Device interface type (example: GigabitEthernet)
– Protocols (examples: CDP, VTP)
The properties to set for the PE and CE/UNI are based on the core type and service definition subtype. For example, if the policy subtype is:
- VPLS_ERS for an Ethernet core, you specify the CE interface type, format and encapsulation type, and whether to filter BPDU.
- VPLS_EWS_NO_CE for an MPLS core, you specify the PE/CLE interface type and format, protocol tunneling, and system MTU.
Note 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.
See the following example for a VPLS_ERS service definition:
VPLS Autodiscovery
VPLS autodiscovery eliminates the need to manually configure the VPLS neighbors. It discovers PEs within the same VPLS domain and automatically detects when PEs are added or removed from the domain.
To use VPLS autodiscovery, all PE devices in the VPLS domain must be VPLS autodiscovery enabled. Mixed topologies (that is, some PEs configured with VPLS autodiscovery enabled and some without) are not supported. The VPLS discovery mode should be enabled for all service requests under the same virtual forwarding interface (VFI).
A detailed description of VPLS autodiscovery, including other prerequites, is found in the Cisco Prime Provisioning 7.0 User Guide .
The complete list of XML examples for VPLS is available here:
Cisco Prime Provisioning API 6.8 Programmer Reference
The following example illustrates how you activate VPLS autodiscovery in Prime Provisioning via the NBI.
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.
VPLS Service Requests
A VPLS service request defines the service definition and VPN to use, assigns interfaces and attributes for each attachment circuit (VplsLink), and applies template information.
Note The attachment circuit, or VplsLink, defines the layer 2 path from the CE to the PE, including any intermediate devices. You provision attachment circuits on the PE-facing port of the CE, on all ports of intermediate devices, and on the CE-facing port on the PE.
When you deploy a VPLS service request using a service order, the attributes specified in the service definition are applied to the devices and interfaces defined in the service request, along with the link attributes for each attachment circuit.
The service request link attributes include any parameters marked as editable in the service definition and link parameters specific to each attachment circuit. The following XML example shows a partial list of the properties that can be specified for the attachment circuit LinkAttrs.
The complete list of XML examples for VPLS is available here:
Cisco Prime Provisioning API 6.8 Programmer Reference
Provisioning Example
This section describes the process for using the API to provision VPLS, and includes the operation, object definition (className), and parameter definitions.
Process Summary
This VPLS provisioning example uses the following processes:
1. Create device groups (optional).
3. Collect device configurations.
7. Create access domains and assign PEs to them.
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).
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.0 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 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).
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:
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.
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.
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.
Each provider can contain multiple regions.
Step 6 Declare devices as PEs.
The XML request that assigns a PE role to a device is also used to:
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.
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.
Step 9 Create sites and assign customers (Organizations) to them.
Step 10 Declare devices as CPEs. This step is not required for service subtypes with no CE present.
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:
- 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.
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.
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).
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.
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).
- 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.
Note If you do not specify a Provider or Organization, the service policy is global. |
||
– CE (not required for policy subtypes with no CE present) Note You can use either NPC or ManualConfig to define the VplsLink interfaces. If you use ManualConfig, you must also specify the interfaces (CE_Intf_Name, UNIDeviceInterface for NO_CE subtypes, and PE_Intf_Name). Note See the “Templates in a Service Request” section. |
Tip Record the LocatorId value from the XML response for the service request. The Locator ID is required for subsequent service request tasks.
- 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.