Cisco IP Solution Center Traffic Engineering Management User Guide, 5.1
Managing Service Requests
Downloads: This chapterpdf (PDF - 361.0KB) The complete bookPDF (PDF - 7.04MB) | Feedback

Managing Service Requests

Table Of Contents

Managing Service Requests

Accessing the Service Requests Window

Service Request Operations

Viewing Service Request Details

History

Configlets

Editing a Service Request

Decommissioning a Service Request (Only Applies to TE Traffic Admission SRs)

Purging a Service Request

Verifying Service Requests

Managing Parallel Service Requests

Service Request States


Managing Service Requests


This appendix describes how to manage service requests and how to access task logs.

To apply TE device changes to network devices, you must deploy the TE service request. When you deploy a TE service request, ISC compares the device information in the Repository (the ISC database) with the current device configuration and generates a configlet.

This appendix includes the following sections:

Accessing the Service Requests Window

Service Request Operations

Viewing Service Request Details

Editing a Service Request

Decommissioning a Service Request (Only Applies to TE Traffic Admission SRs)

Purging a Service Request

Verifying Service Requests

Managing Parallel Service Requests

Service Request States.

Accessing the Service Requests Window

To manage TE service requests, go to Service Inventory > Inventory and Connection Manager > Service Requests.

Figure C-1 shows the Service Requests window.

Figure C-1 Service Requests

The Service Requests window shows the current list of service requests for this username. The list includes the following information about each service request:

JobID—The job number assigned to the service request by ISC. Table C-1 describes ISC service request states.

Data Files—This field is used for variable substitutions via templates and currently do not apply to TEM SRs.

State—The transition state for the service request. See Service Request States for more information.

Type—The type of service request. For example, MPLS VPN, L2VPN, VPLS, VRF, TE, or FlexUNI(EVC).

Operation Type—The operation type for the service request. For example, ADD means that you are adding this service request, MODIFY that a service request has been changed from an earlier state, and DELETE that you are decommissioning this service request.

Creator—Username identity of person who created or last modified the service request.

Customer Name—Customer name for the service request.

Policy Name—Name of policy assigned to this service request.

Last Modified—Date and time the service request was created or last modified.

Description—Optional text description of the service request.

Service Request Operations

From the Service Requests window you can perform the following operations for TE service requests:

Create—See the respective sections in Chapter 4, "Basic Tunnel Management", Chapter 5, "Advanced Primary Tunnel Management", or Chapter 6, "Protection Planning."

Details—See Viewing Service Request Details.

Status—Select Logs to access any available logs for a selected service request. For more details, see Viewing a Task Log, page 9-2.

Edit—See Editing a Service Request.

Deploy—Only supported for TE Traffic Admission service requests from this location. For TE Resource, TE Tunnel, and TE Protection service requests, see the respective sections in Chapter 4, "Basic Tunnel Management", Chapter 5, "Advanced Primary Tunnel Management", or Chapter 6, "Protection Planning."

Decommission—See Decommissioning a Service Request (Only Applies to TE Traffic Admission SRs). Not supported for TE Resource, TE Tunnel, and TE Protection service requests.

Purge—See Purging a Service Request.

Viewing Service Request Details

The service request details include the link endpoints for the service request, the history, and the configlet generated during the service request deployment operation. Use the service request details to help you troubleshoot a problem or error with the service request or to check the commands in the configlet.

This section describes how to view the details of a service request, including the history, link details, and configlets.

To view service request details:


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

Step 2 Select the service request and click Details.

The Service Request Details window appears as shown in Figure C-2.

Figure C-2 Service Request Details—Attributes

From the Service Request Details page, you can view more information about:

Details > History—Service request history report.

Details > Audit—Not supported by TEM.

Details > Configlets—View the ISC generated configlet for the service request.


The following sections describe the links, history, and configlet details for a service request.

History

Figure C-3, Figure C-4, and Figure C-5 show the Service Request History Report window.

Figure C-3 Service Request History Report (top)

Figure C-4 Service Request History Report (middle)

Figure C-5 Service Request History Report (bottom)

The history report shows the following information about the service request:

Element name—The device, interface, and subinterfaces participating in this service request.

State—The transition states the element has gone through.

Create Time—The time the element was created for this service request.

Report—The action taken by ISC for the element in this service request.

Configlets

To view configlets:


Step 1 Click Configlets on the Service Request Details window. The Service Request Configlets window appears (Figure C-6).

Figure C-6 Service Request Configlets

This window shows all devices whose configuration is affected by the service request.

Step 2 Select the device to view the configlet.

Step 3 Click View Configlet.

The Service Request Configlet window appears (Figure C-7).

Figure C-7 Configlet Example

The device configlet shows all commands downloaded to the device configuration during the service request deployment operation.

Step 4 Click OK to exit.


Editing a Service Request

The TE Resource, TE Tunnel and TE Protection service requests can be edited from the main Traffic Engineering Management Services window as described in chapters 4, 5, 6, and 7. This is the recommended method. Alternatively, the edit operation can be initiated from the Service Request window for these service requests.

The TE Admission service request, however, can only be initiated from the Service Requests window. We will focus on TE Admission service requests in the following procedure.

To edit a service request, use the following steps:


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

Step 2 Select the service request you want to modify and click Edit.

The TE Traffic Admission SR window in Figure 7-3 appears.

Step 3 Make the desired changes in the editor and click Save.

The Service Requests window reappears with the corresponding State set to REQUESTED and the Operation Type changed to MODIFY as shown in Figure C-8.

Figure C-8 Service Requests - MODIFY REQUESTED state

Step 4 Deploy the service request by selecting it and clicking Deploy > Deploy.

This is necessary for the changes to be provisioned to the network.

Step 5 In the Deploy Service Request window, select the time at which the deployment should take place (default is immediately), and click Save.

Step 6 After deployment, look for the service request state to go to DEPLOYED to indicate a successful deployment.


Decommissioning a Service Request (Only Applies to TE Traffic Admission SRs)

To decommission a TE Admission service request, use the following steps:


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

Step 2 Select the service request you want to decommission and click Decommission.

The Confirm Request window in Figure C-9 appears.

Figure C-9 Confirm Request - Decommissioning a TE Traffic Admission SR

Mouse over any yellow warning symbol to see the warning message.

Step 3 Click OK to confirm the decommissioning of the service request.

The Service Requests window reappears with the corresponding Operation Type changed to DELETE as shown in Figure C-10.

Figure C-10 Service Requests - Decommissioning a TE Traffic Admission SR

Step 4 Deploy the service request by selecting it and clicking Deploy > Deploy.

This is necessary for the changes to be provisioned to the network.

Step 5 In the Deploy Service Request window, select the time at which the deployment should take place (default is immediately), and click Save.

Step 6 After deployment, look for the service request state to go to CLOSED to indicate that the service request has been decommissioned successfully.


Purging a Service Request

The Purge operation is designed to remove a service request from the repository without affecting the network.

The Purge button has 2 options:

Purge—The regular purge can only be used on the service request in CLOSED state. Therefore, it cannot be used on TE Resource, TE Tunnel, or TE Protection service requests because these cannot be decommissioned. These three types of service requests can only be force purged.

Force Purge—During force purge, the repository checks the necessary dependency on the service request before it can be purged, so if a service request cannot be purged, there will be an error message.

Verifying Service Requests

After you deploy a service request, you should verify that there were no errors.

You can verify a service request through the following:

Transition state—The transition state of a service request is listed on the Service Requests window in the State column. See Service Request States for more information.

View service request details—From the Service Requests Details window, you can view the link endpoints and the configlets for this service request.

Task Logs—Access the task logs either from the Monitoring > Task Manager or from Service Inventory > Inventory and Connection Manager > Service Requests (Status button) to help you troubleshoot a failed service request or to view more details about a service request. See TE Task Logs, page 9-1 for more information.

Managing Parallel Service Requests

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

No parallel provisioning will be possible on the same SR, but given that there are SRs at router level for unmanaged tunnels, unmanaged tunnels can be provisioned on separate routers at the same time.

For more information on multiple concurrent users, see Multiple Concurrent Users, page F-4.

Service Request States

A service request transition state describes the different stages a service request enters during the provisioning process.

For example, when you deploy a service request, ISC compares the device information in the Repository (the ISC database) with the current device configuration and generates a configlet for each device. When the configlets are generated and downloaded to the devices, the service request enters the Pending state. When the devices are audited, the service request enters the Deployed state.

Figure C-11, "Service Requests States Transition Diagram," shows a high-level diagram of the relationships and movement among ISC service request states.


Note For for more information about parallel processing of ISC service requests, see Managing Parallel Service Requests.


Figure C-11 Service Requests States Transition Diagram

Table C-1, "Summary of Cisco IP Solution Center Service Request States," describes the functions of each ISC service request state. They are listed in alphabetical order.

Table C-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 C-2, "User Operations on ISC Service Requests," describes user operations and their impact on ISC service requests.

Table C-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.