MPLS VPN Service Requests

This chapter describes how to provision and audit service requests in IP Solution Center (ISC). It contains the following major sections:

Overview of Service Requests

Service Request Transition States

The focus of ISC is the service provided for a customer on the link between a customer CE and a provider PE. The service request model is the centerpiece of service provisioning. With the service request model, the ISC can capture the specified VPN service provisioning request, analyze the validity of the request, and audit the provisioning results.

The service provider operators take all service request information from their customers. ISC can assist the operator in making entries because the product has customer information such as the VPN information, the list of the assigned PEs and CEs, and so forth.

ISC steps the operator through the process and simplifies the task of provisioning the CE and PE by automating most of the tasks required to set up an MPLS VPN.

Note ISC service requests are processed in parallel, except when multiple service requests attempt to configure the same device. In this case, the service requests are processed sequentially (that is, only one write to the device can happen at a time).

Table 6-1 Summary of Cisco IP Solution Center Service Request States
Service Request Type	Description
Broken (valid only for MPLS services)	The router is correctly configured but the service is unavailable (due to a broken cable or Layer 2 problem, for example). An MPLS service request moves to Broken if the auditor finds the routing and forwarding tables for this service, but they do not match the service intent.
Closed	A service request moves to Closed if the service request should no longer be used during the provisioning or auditing process. A service request moves to the Closed state only upon successful audit of a decommission service request. ISC does not remove a service request from the database to allow for extended auditing. Only a specific administrator purge action results in service requests being removed.
Deployed	A service request moves to Deployed if the intention of the service request is found in the router configuration file. Deployed indicates that the configuration file has been downloaded to the router, and the intent of the request has been verified at the configuration level. That is, ISC downloaded the configlets to the routers and the service request passed the audit process.
Failed Audit	This state indicates that ISC downloaded the configlet to the router successfully, but the service request did not pass the audit. Therefore, the service did not move to the Deployed state. The Failed Audit state is initiated from the Pending state. After a service request is deployed successfully, it cannot re-enter the Failed Audit state (except if the service request is redeployed).
Failed Deploy	The cause for a Failed Deploy status is that DCS reports that either the upload of the initial configuration file from the routers failed or the download of the configuration update to the routers failed (due to lost connection, faulty password, and so on).
Functional (valid only for MPLS services)	An MPLS service request moves to Functional when the auditor finds the VPN routing and forwarding tables (VRF) for this service and they match with the service intent. This state requires that both the configuration file audit and the routing audit are successful.
Invalid	Invalid indicates that the service request information is incorrect in some way. A service request moves to Invalid if the request was either internally inconsistent or not consistent with the rest of the existing network/router configurations (for example, no more interfaces were available on the router). The Provisioning Driver cannot generate configuration updates to service this request.
Lost	A service request moves to Lost when the Auditor cannot find a configuration-level verification of intent in the router configuration files. The service request was in the Deployed state, but now some or all router configuration information is missing. A service request can move to the Lost state only when the service request had been Deployed.
Pending	A service request moves to Pending when the Provisioning Driver determines that the request looks consistent and was able to generate the required configuration updates for this request. Pending indicates that the service request has generated the configuration updates and the configuration updates are successfully downloaded to the routers. The Auditor regards pending service requests as new requests and begins the audit. If the service has been freshly provisioned and not yet audited, it is not an error (pending audit). However, if an audit is performed and the service is still pending, it is in an error state.
Requested	If the service is newly entered and not yet deployed, it is not an error. However, if a Deploy is done and it remains Requested, the service is in an error state.
Wait Deploy	This service request state pertains only when downloading configlets to a Cisco CNS-CE server, such as a Cisco CNS IE2100 appliance. Wait Deploy indicates that the configlet has been generated, but it has not been downloaded to the Cisco CNS-CE server because the device is not currently online. The configlet is staged in the repository until such time as the Cisco CNS-CE server notifies ISC that it is up. Configlets in the Wait Deploy state are then downloaded to the Cisco CNS-CE server.

Table 6-2 User Operations on ISC Service Requests
User Operations	Description
Decommission	This user operation removes the service from all devices in the service request.
Force Deploy	This user operation allows you to Deploy a service request from any state except Closed. This is equivalent to restarting the state diagram. The service request can move from its current state to any other possible state. However, it does not move to the Requested state.
Force Purge	This user operation removes a service request from the database irrespective of its state. If you Force Purge a service request from the ISC repository before first decommissioning the service request, the service remains running on the network (specifically, the configuration remains on the devices on which the service was provisioned), but all record of the service request that created the service is removed from ISC.
Purged	When a service request is Purged, it is removed from the ISC database.

Service Enhancements

With this release of MPLS VPN Management, a number of enhancements to the service function are available:

•

A service is no longer limited to a single PE-CE link at a time. Under ISC, a service can be comprised of multiple PE-CE links per service request.

A multicast address is a single address that represents a group of machines. Unlike a broadcast address, however, the machines using a multicast address have all expressed a desire to receive the messages sent to the address. A message sent to the broadcast address is received by all IP-speaking machines, whether they care what it contains or not. For example, some routing protocols use multicast addresses as the destination for their periodic routing messages. This allows machines that have no interest in routing updates to ignore them.

To implement multicast routing, ISC employs the concept of a multicast domain (MD), which is a set of VRFs associated with interfaces that can send multicast traffic to each other. A VRF contains VPN routing and forwarding information for unicast. To support multicast routing, a VRF also contains multicast routing and forwarding information; this is called a Multicast VRF.

Although a route target provides the mechanisms to identify which VRFs should receive routes, a route target does not provide a facility that can prevent routing loops. These routing loops can occur if routes learned from a site are advertised back to that site. To prevent this, the Site of Origin (SOO) feature identifies which site originated the route, and therefore, which site should not receive the route from any other PE routers.

How ISC Accesses Network Devices

Checks to see if a terminal server is associated with the device, and if this is the case, ISC uses the terminal server to access the device.

If there is no terminal server, ISC looks for the management interface on the device.

If there is no management interface, ISC tries to access the device using the fully-qualified domain name (host name plus domain name).

If any step in the VPN Solutions Center device-access algorithm fails, the entire device access operation fails—there is no retry or rollover operation in place. For example, if there is a terminal server and ISC encounters an error in attempting to access the target device through the terminal server, the access operation fails at that point. With the failure of the terminal server access method, ISC does not attempt to find the management interface to access the target device.

Examples of Creating MPLS VPN Service Requests

A service request is an instance of service contract between a customer edge router (CE) and a provider edge router (PE). The service request user interface asks you to enter several parameters, including the specific interfaces on the CE and PE routers, routing protocol information, and IP addressing information.You can also integrate an ISC template with a service request, and associate one or more templates to the CE and the PE. To create a service request, a service policy must already be defined, as described in Chapter 5, "MPLS VPN Service Policies."

MPLS VPN Topology Example

Figure 6-2 shows the topology for the network used to define the service requests in this section.

In the PE-CE example, the service provider needs to create an MPLS service for a CE (mlce1) in their customer site Acme_NY (in New York).

In the Multi-VRF example, the service provider needs to create an MPLS service between a CE (mlce4) in their customer site Widgets_NY (in New York) and a Multi-VRFCE (mlce3) located in their customer site Widgets_NY (in New York).

The goal is to create a single service request that defines a link between the customer site in New York and the PE (mlpe2).

In the PE-Only example, the service provider needs to create an MPLS service for a PE (mlpe2.)

Creating an MPLS VPN PE-CE Service Request

For an example of creating an MPLS VPN PE-CE service request, perform the following steps:

Step 1

Choose Service Inventory > Inventory and Connection Manager > Service Requests.

The Select MPLS Policy dialog box appears. It displays the list of all the MPLS service policies that have been defined in ISC.

The MPLS Service Request Editor now displays a set of fields, as shown in Figure 6-3. Notice that the Select CE field is enabled. Specifying the CE for the link is the first task required to define the link for this service.

From the "Show CPEs with" drop-down list, you can display CEs by Customer Name, by Site, or by Device Name.

You can use the Find button to either search for a specific CE, or to refresh the display.

This dialog box displays the first page of the list of currently defined CE devices. The number of pages of information is displayed in the lower right corner of the dialog box. To go to the another page of CE devices, click the number of the page you want to go to.

Step 7

In the Select column, choose the name of the CE for the MPLS link, then click Select.

You return to the Service Request Editor window, where the name of the selected CE is now displayed in the CE column.

Step 8

CE Interface: Choose the CE interface from the drop-down list, as shown in Figure 6-5.

From the "Show PEs with" drop-down list, you can display PEs by Customer Name, by Site, or by Device Name.

You can use the Find button to either search for a specific PE, or to refresh the display.

This dialog box displays the first page of the list of currently defined PE devices. The number of pages of information is displayed in the lower right corner of the dialog box.

To go to the another page of PE devices, click the number of the page you want to go to.

Step 10

In the Select column, choose the name of the PE for the MPLS link, then click Select.

You return to the Service Request Editor window, where the name of the selected PE is now displayed in the PE column.

The MPLS Link Attribute Editor appears, showing the fields for the interface parameters, as shown in Figure 6-6.

The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on each of the PE and CE interface fields, see Specifying PE and CE Interface Parameters, page 5-4.

Note The VLAN ID is shared between the PE and CE, so there is one VLAN ID for both.

Step 13

Edit any interface values that must be modified for this particular link, then click Next.

The MPLS Link Attribute Editor for the IP Address Scheme appears. The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the IP address scheme fields, see Specifying the IP Address Scheme, page 5-8.

Step 14

Edit any IP address scheme values that must be modified for this particular link, then click Next.

The MPLS Link Attribute Editor for Routing Information appears, as shown in Figure 6-7.

The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the routing information for the PE and CE, see Specifying the Routing Protocol for a Service, page 5-11.

Because the service policy used for this service specified the routing protocol as editable, you can change the routing protocol for this service request as needed.

Step 15

Edit any routing protocol values that must be modified for this particular link, then click Next.

Note

If this interface is dual stacked (IPv4 and IPv6), you will be prompted to enter the routing information for both IPv4 and IPv6 independently.

The MPLS Link Attribute Editor for the VRF and VPN attributes appears. The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the VRF and VPN information, see Defining VRF and VPN Information, page 5-29.

Note

If you want to set the VRF and VPN attributes via a previously defined VRF object, check the Use VRF Object check box. For more information on this feature, see Chapter 3, "Independent VRF Management." That chapter describes how to use independent VRF objects in MPLS VPN service policies and service requests.

Step 16

If multicast is enabled, choose the PIM (Protocol Independent Multicast) Mode:

Tip

Multicast routing architecture allows the addition of IP multicast routing on existing IP networks. PIM is an independent unicast routing protocol. It can be operated in two modes: dense and sparse.

Step 17

Edit any VRF and VPN values that must be modified for this particular link, then click Finish.

You return to the MPLS Service Request Editor. You can define multiple links in this service request.

Step 18

To save your work on this first link in the service request, click Save.

You return to the Service Requests dialog box, where the information for the link you just defined is now displayed, as shown in Figure 6-8.

As you can see, the service request is in the Requested state. When all the links for this service have been defined, you must deploy the service, as described in Deploying Service Requests.

Note By default, all service requests in the ISC system are shown in the Service Request window. You can filter the list of service requests to be displayed by choosing different selections from the Show Services with, matching, and of type drop-down lists and clicking the Find button.

Note If you have only ACTIVATION, L3MPLSVPN, and VPN licenses installed for ISC, you cannot display all service requests based on the VPN used (by choosing VPN Name in the Show Services with drop-down list, where Type is All). The workaround for this is to display the service requests based the MPLS VPN type (by choosing MPLS VPN in the of type drop-down list). This problem does not occur if all ISC licenses are installed.

Viewing Configlets Generated by the MPLS VPN Service Request

To view configlets generated on the PE and CE device by the MPLS VPN service request, perform the following steps:

Step 1

To view the PE and CE configlets for a service request that has been successfully deployed, from the Service Request window, choose the service request you want to see, then click Details.

Step 3

Choose the IP address for the desired configlet, then click View Configlet.

Setting Static Routing Protocol Attributes (for IPv4 and IPv6)

For the static routing protocol, in addition to the attributes that you can specify in the service policy, there are additional attributes that you can add via the Link Attribute Editor.

•

Advertised Routes for CE: allows you to add a list of IP addresses, static routes to put on the PE, that describes all the address space in the CE's site.

•

Routes to Reach other Sites: allows you to add a list of IP addresses, static routes to put on the CE, that describes all the address space throughout the VPN.

IPv4 Routing Information

Step 1

When you perform Step 14 on page 4-10 for static routing protocols, the MPLS Link Attribute Editor for Routing Information appears ( Figure 6-10).

You can edit Advertised Routes for CE: and Routes to Reach other Sites: for this service request.

IPv6 Routing Information

Step 1

When you perform Step 14 on page 4-10 for static routing protocols, the MPLS Link Attribute Editor for Routing Information appears ( Figure 6-11).

Step 9

Enter an IP address (in IPv6 format) in the Next Hop IP Address: field.

For information on formats supported formats for entering IPv6 addresses, see MPLS VPN Service Policies.

Creating a Multi-VRF Service Request

MPLS-VPNs provide security and privacy as traffic travels through the provider network. The CE router has no mechanism to guarantee private networks across the traditional LAN network. Traditionally to provide privacy, either a switch needed to be deployed and each client be placed in a separate VLAN or a separate CE router is needed per each client's organization or IP address grouping attaching to a PE.

These solutions are costly to the customer as additional equipment is needed and requires more network management and provisioning of each client site.

Multi-VRF is a new feature, introduced in Cisco IOS release 12.2(4)T, that addresses these issues. Multi-VRF extends limited PE functionality to a CE router in an MPLS-VPN model. A CE router now has the ability to maintain separate VRF tables in order to extend the privacy and security of an MPLS-VPN down to a branch office rather than just at the PE router node.

CE routers use VRF interfaces to form a VLAN-like configuration on the customer side. Each VRF on the CE router is mapped to a VRF on the PE router. With Multi-VRF, the CE router can only configure VRF interfaces and support VRF routing tables. Multi-VRF extends some of the PE functionality to the CE router—there is no label exchange, there is no LDP adjacency, there is no labeled packet flow between PE and CE. The only PE-like functionality that is supported is the ability to have multiple VRFs on the CE router so that different routing decisions can be made. The packets are sent toward the PE as IP packets.

Step 1

Choose Service Inventory > Inventory and Connection Manager > Service Requests.

The MPLS Link Attribute Editor - Interface window appears, as shown in Figure 6-16.

The MPLS Link Attribute Editor - Interface window appears, as shown in Figure 6-18.

The MPLS Service Requests window appears showing that the Service Request is in the Requested state and ready to deploy.

Creating a PE-Only Service Request

Step 1

Choose Service Inventory > Inventory and Connection Manager > Service Requests.

The Select MPLS Policy dialog box appears. This dialog box displays the list of all the MPLS service policies that have been defined in ISC.

The MPLS Service Request Editor now displays a set of fields, as shown in Figure 6-20. Notice that the Select PE field is enabled. Specifying the PE for the link is the first task required to define the link for this service, unless a CLE switch link is needed. If a CLE switch is needed go to "Adding a CLE to a Service Request" section.

From the "Show PEs with" drop-down list, you can display PEs by Provider Name, by Region, or by Device Name.

You can use the Find button to either search for a specific PE, or to refresh the display.

This dialog box displays the first page of the list of currently defined PE devices. The number of pages of information is displayed in the lower right corner of the dialog box.

To go to the another page of PE devices, click the number of the page you want to go to.

Step 7

In the Select column, choose the name of the PE for the MPLS link, then click Select.

You return to the Service Request Editor window, where the name of the selected PE is now displayed in the PE column.

Step 8

PE Interface: Choose the PE interface from the drop-down list, as shown in Figure 6-21.

The MPLS Link Attribute Editor appears, showing the fields for the interface parameters, as shown in Figure 6-22.

The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the PE interface fields, see Specifying PE and CE Interface Parameters, page 5-4.

Step 10

Edit any interface values that must be modified for this particular link, then click Next.

Step 11

Edit any IP address scheme values that must be modified for this particular link, then click Next.

The MPLS Link Attribute Editor for Routing Information appears, as shown in Figure 6-23.

The field values displayed in this dialog box reflect the values specified in the service policy associated with this service. For details on the routing information for the PE, see Specifying the Routing Protocol for a Service, page 5-11.

Because the service policy used for this service specified the routing protocol as editable, you can change the routing protocol for this service request as needed.

Step 12

If you check Site of Origin, the screen updates to include the required step of selecting a value:

From the available list shown, check the check box associated with a site and its SOO value, then click Select.

Step 13

Edit any routing protocol values that must be modified for this particular link.

Note

If this interface is dual stacked (IPv4 and IPv6), you will be prompted to enter the routing information for both IPv4 and IPv6 independently.

When specifying IPv6 routing protocol information, the MPLS Link Attribute Editor for Routing Information shows only a subset of options, as shown in Figure 6-24. For information on formats supported for entering IPv6 addresses, see MPLS VPN Service Policies.

Note

Step 15

Edit any VRF and VPN values that must be modified for this particular link, then click Finish.

You return to the MPLS Service Request Editor. You can define multiple links in this service request.

Step 16

To save your work on this first link in the service request, click Save.

You return to the Service Requests dialog box, where the information for the link you just defined is now displayed.

You can add additional links to this service request by choosing Add Link and specifying the attributes of the next link in the service. As you can see, the service request is in the Requested state. When all the links for this service have been defined, you must deploy the service, as described in Deploying Service Requests.

Adding a CLE to a Service Request

From the "Show PEs with" drop-down list, you can display PEs by Provider Name, by Region, or by Device Name.

You can use the Find button to either search for a specific PE, or to refresh the display.

This dialog box displays the first page of the list of currently defined PE devices. The number of pages of information is displayed in the lower right corner of the dialog box.

To go to the another page of PE devices, click the number of the page you want to go to.

Step 3

In the Select column, choose the name of the CLE for the MPLS link, then click Select.

You return to the Service Request Editor window, where the name of the selected CLE is now displayed in the CLE column.

Deploying Service Requests

When you have queued one or more service requests, you can then deploy them. This procedure automatically audits the new service requests. This audit passes the service request into an operational state.

ISC sets up a scheduled task that deploys service requests to the appropriate routers. This involves computing the configlets for each service request, downloading the configlets to the routers, and running audit reports to determine whether the service was successfully deployed.

To deploy the service requests immediately or schedule their deployment, perform the following steps:

From the Service Inventory window, choose Inventory and Connection Manager.

From the Inventory and Connection Manager window, choose Service Requests.

Step 2

Check the check box next to the Job ID for the service request you want to deploy.

•

Deploy: Use Deploy when the service request state is Requested or Invalid.

•

Force Deploy: Use Force Deploy when the service request state is Deployed or Failed Audit.

The Deploy Service Requests dialog box appears, which allows you to schedule when you want to deploy the selected service request, as shown in Figure 6-25.

Step 5

Complete the fields in this dialog box to schedule the service requested as needed.

You return to the Service Requests dialog box. Check the Status display in the lower left corner of the window. If the service request has been deployed successfully, the Status display appears as shown in Figure 6-26.

Step 7

To update the State from Requested to Deployed, enable the Auto Refresh check box.

You can view logs to check on the task status and whether or not it completed successfully. To view logs, choose Monitoring > Task Manager > Logs (for Log details, see the Cisco IP Solution Center Infrastructure Reference, 5.0.1.

Monitoring Service Requests

After you have created and deployed a service request, to monitor its status, perform the following steps:

Step 3

Check the check box for the service request in which you are interested.

Step 4

To see details about the service request deployment, click Details.

Auditing Service Requests

This section describes auditing in MPLS VPN. It contains the following sections:

Functional Audit

A functional audit verifies that the links in a service request or VPN are working correctly. The audit checks the routes to remote CEs in the VRF route tables on the PE devices. The user can optionally ping the connected CE from the PE to verify that the link is functional.

How to Perform a Functional Audit

ISC automatically provides a functional audit whenever a service request is deployed or force-redeployed.

To create a task to do a functional audit for one or more service requests, perform the following steps:

Step 2

Choose one or more service requests in Deployed, Functional, or Broken states as the targets for the task.

You can choose a VPN to audit. If you choose a VPN to audit, all the links that form the VPN are audited.

You can choose either SR(s) or VPN(s) in one task, but you cannot choose both in the same task.

In the summary page, you can uncheck the Perform Ping to verify PE/CE link check box if you do not want to invoke ping in that particular task.

For links without CEs (CE not present case), ping is not performed, whether the check box is selected or not.

Where to Find Functional Audit

Why Functional Audit Could Fail

Configuration Audit

A configuration audit verifies if all the commands for a service (service intent) are present on the network elements that participate in the service.

How to Perform a Configuration Audit

ISC automatically does a configuration audit whenever a service request is deployed or force-redeployed. To create a task to do a configuration audit for one or more service requests, perform the following steps:

Where to Find Configuration Audit

Why Configuration Audit Could Fail

A configuration audit can fail if some of the commands are removed after provisioning from the network elements. This could happen if the commands are manually removed or they are removed as part of provisioning some other service.

Another reason a configuration audit can fail is if ISC does not recognize commands in the configuration file. The default behavior in ISC is to skip unrecognized commands in the configuration file during the configuration audit. Such unrecognized commands might have be been present in an existing configuration or manually inserted in the configuration file. If an unrecognized command is at the start of a block of commands, ISC will skip the initial command and continue to parse the subcommands in the block. This might lead ISC to assume there is an error in the logic flow within the configuration file and cause the audit to fail.

Viewing Configlets Generated by a Service Request

To view configlets that have been generated by a service request for a device, perform the following steps:

Note For IOS devices, the configlets will appear as CLI commands. For IOS XR devices, the configlets can be viewed in XML or CLI format. For information about viewing configlets for IOS XR devices, see Viewing Configlets on IOS XR Devices.

Step 1

Choose Service Inventory > Inventory and Connection Manager > Service Requests to view the available service requests.

Step 2

Check the appropriate check box to select the service request for which you want to view the associated configlets.

The Service Request Configlets window appears. This window displays a list of devices for which configlets have been generated.

Step 5

To view configlets that were generated for a device, select a device and click the View Configlet button.

The Service Request Configlet window updates showing the configlet, as shown in Figure 6-29. By default, the latest generated configlet is displayed.

Step 6

If applicable, you can display configlets for a device based on the time of creation. Choose the desired time of creation in the Create Time list to display a specific configlet based on the time the configlet was generated for the service request.

Viewing Configlets on IOS XR Devices

By default, service requests for IOS XR devices log the configuration sent to the device in XML format. Therefore, when configlets are viewed for IOS XR devices, they are displayed in raw XML format. ISC also allows the configlet to be viewed in CLI format. This feature is enabled by setting the DCPL property DCS/getCommitCLIConfigAfterDownload to true (which is the default setting).

Note The DCPL property DCS/getCommitCLIConfigAfterDownload must be set to true to display the configlet(s) in CLI format. On setting the DCPL property to true, CLI configlets will only be available for subsequent service request deployments. They will not be available for configlets that were deployed before the DCPL property was set to true.

To view the configlets for IOS XR devices in XML or CLI formats, or both, perform the following steps:

Step 1

Choose Service Inventory > Inventory and Connection Manager > Service Requests to view the available service requests.

Step 2

Check the appropriate check box to select the service request for which you want to view the associated configlets.

The Service Request Configlets window appears. This window displays a list of devices for which configlets have been generated.

Step 5

To view configlets that were generated for an IOS XR device, select an IOS XR device and click the View Configlet button.

The Service Request Configlet window appears showing the configlet in CLI format. By default, the latest generated configlet is displayed.

Step 6

Step 7

To view the configlet in XML format, click the XML Configlet radio button.

The window refreshes and displays the configlet in XML format, as shown in Figure 6-30.

•

CLI Configlet — Displays the configlet in CLI format. This the default selection.

•

Both — Displays the configlet side by side in both XML and CLI formats.

Editing Configuration Files

To view or edit an existing router configuration file, perform the following steps:

Note Exercise caution when editing a configuration file, particularly if you then choose to make the edited file the running configuration file.

Step 4

Check the check box next to the device name to choose the configuration file versions you want to view.

The Device Configurations dialog box displays the list of the current versions of the configuration files for the selected device. The configurations are listed by date and time. The configuration file listed first is the latest version.

Step 6

Choose the version of the configuration file you want to view, then click Edit.

The contents of the selected configuration file are displayed, as shown in Figure 6-33.

Viewing Templates from the Service Requests Window

In the Service Requests window, a paper clip icon appears in the Data Files column if a service request has one or more templates associated with it, as shown in Figure 6-34.

Note You can use the Show Services with field to search for service requests that have a specific data or template file. Choose Data File Name or Template Name from the drop-down list and enter a search string in the matching field. The matching field is not case sensitive and supports wildcards (*). You can further limit the search by using the of Type field to confine the search to a particular service type. When listing service requests using Template Name, provide the entire path of the template file location (for example: examples\template, where examples is the folder name and template implies the template name).

To view the configlet(s) for the template(s) associated with a service request, perform the following steps:

Step 1

In the Service Requests window, check the check box for a service request with an associated template, as indicated by a paper clip icon in the Data Files column.

The Associated data file(s) row displays a link for each data file associated with the service request, as shown in the figure.

Step 4

After viewing the configlet, click OK to close the configlet display window.

Step 6

As an alternative, you can access the data files associated with a service request by clicking on the paper clip icon in the Service Requests window.

The window displays only a list of the data files associated with the service request.

Step 8

After viewing the configlet, click OK to close the configlet display window.

Step 9

Click Close to close the Service Request Datafile Details window and return to the Service Requests window.

Decommissioning Service Requests with Added Templates

This section describes how to decommission ISC service requests that have added templates.

As mentioned in the Cisco IP Solution Center Infrastructure Reference, 5.0.1, "Template commands are treated independently from those associated with a service creation (Multi Protocol Label Switching (MPLS)), Layer 2 Virtual Private Network (L2VPN), Virtual Private LAN Service (VPLS), Traffic Engineering (TE), and so on). Consequently, template commands must be removed separately from the device(s) during a service decommission. To remove prior template commands, a separate template is needed during a decommission process. Decommissioning a service request does not automatically remove the original template commands. A separate negate template needs to be added to the decommission process and the original templates must be removed. The negate template must contain the necessary NO commands to successfully remove any unwanted IOS commands added by the original template."

The standard way to create a service request with a template added is as follows:

Create the service request with the template added. The steps to do this are covered in relevant chapters of this guide.

Note To see which service requests have an associated template, choose Service Inventory > Inventory and Connection Manager > Services Requests to view the available service requests. The Data Files column displays a paperclip icon for services requests that have an associated data or template file. Click on the paper clip icon to see the details for the service request. You can also use the Show Services with field to search for service requests that have a specific data or template file. For additional information on using data files and templates, see the Cisco IP Solution Center Infrastructure Reference, 5.0.1.

To decommission a deployed service request, including associated templates, you must perform the following steps:

Create a negate template. This is used to remove the commands imposed by the original template. For an explanation of negate templates, see Chapter 4, "Using Templates" in the Cisco IP Solution Center API Programmer Guide, 5.0.

Edit (not decommission) the original service request, remove the original template, and add the negate template.

Save the service request. It will change to the Requested state with Operation Type of Modify.

Decommission the service request. It will remain as Requested, but changed to an Operation Type of Delete.

Deploy the service request. This will decommission the service request and download the negate template, which will remove the original template commands.

Table Of Contents