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
Service Request States
Managing Service Requests
This chapter 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 chapter 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
•Service Request States
Accessing the Service Requests Window
To manage TE service requests, go to Service Inventory > Inventory and Connection Manager > Service Requests.
Figure B-1 shows the Service Requests window.
Figure B-1 Service Requests List
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 B-1 describes ISC service request states.
•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, QoS, or TE.
•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 "Basic Tunnel Management", "Advanced Primary Tunnel Management", or "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.
•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 "Basic Tunnel Management", "Advanced Primary Tunnel Management", or "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 Select 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 B-2.
Figure B-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 ISC 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 B-3, Figure B-4, and Figure B-5 show the Service Request History Report window.
Figure B-3 Service Request History Report (top)
Figure B-4 Service Request History Report (middle)
Figure B-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 B-6).
Figure B-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 B-7).
Figure B-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 Select 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 8-2 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 B-8.
Figure B-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 Select 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 8-2 appears.
Figure B-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 B-10.
Figure B-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 DEPLOYED to indicate a successful deployment.
Purging a Service Request
The Purge operation is designed to remove a service request from the repository without affecting the network.
The Purge button is 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 since 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 for more information.
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.
Table B-1 describes the transition states for an ISC service request.
Table B-1 Cisco IP Solution Center Service Request States
Service Request Type
|
Description
|
Broken
|
A Functional Audit has been run against the TE Tunnel SR or TE Protection SR and this audit has found that one or more tunnels are not using their first path option.
|
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
|
A Functional Audit has been succesfully run against the TE Tunnel SR or TE Protection SR, meaning that all tunnels have been found to be using their first path option.
|
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
|
The provisioning engine has successfully deployed the requested changes to the network, but the config audit has not yet completed its checking that the network configuration agrees with the expected configuration stored in the repository.
|
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.
|
Figure B-11 illustrates which service request states relate to the configuration auditing process, and which states relate to the provisioning process.
Figure B-11 Service Requests States
Feedback
