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 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 detail, perform the following steps.
Step 1 Choose
Operate > Service Requests > Service Request Manager
.
Step 2 Select the service request and click Details.
The Service Request Details window appears.
From the Service Request Details page, you can view more information about:
-
Details > History
—Service request history report.
-
Details > Audit
—Not supported by Prime Provisioning.
-
Details > Configlets
—View the Prime Provisioning generated configlet for the service request.
The following sections describe the history, audit, and configlet details for a service request.
Viewing Service Request History Information
To view history information about the service request, perform the following steps.
Step 1 Click History in the Service Request Details window.
The Service Request State Change Report window appears.
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 Prime Provisioning for the element in this service request.
Step 2 Click
OK
to return to the Service Request Details window.
Viewing Audit Reports Service Requests
This section describes how to view configuration and functional audit reports for Prime Provisioning service requests.
Viewing Configuration Audit Reports
A configuration audit verifies if all the commands for a service (service intent) are present on the network elements that participate in the service. Each time a service request is deployed in Prime Provisioning, a configuration audit occurs. When a configuration audit occurs, 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. 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.
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 Prime Provisioning does not recognize commands in the configuration file. The default behavior in Prime Provisioning 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, Prime Provisioning will skip the initial command and continue to parse the subcommands in the block. This might lead Prime Provisioning to assume there is an error in the logic flow within the configuration file and cause the audit to fail.
Configuration audits can be performed manually through the Prime Provisioning Task Manager. For information on how to create a task to manually schedule a configuration audit, see This chapter contains the following sections:.
To display the Configuration Audit report for a service request, perform the following steps.
Step 1 Choose
Operate > Service Requests > Service Request Manager
.
The Service Request Manager window appears.
Step 2 Choose a service request for the configuration audit.
Step 3 Click Details.
The Service Request Details window appears.
Step 4 Click the
Audit
button and choose
Config
from the drop-down list.
The Service Request Audit Report window appears.
This window lists the device name and role, and a message regarding the status of your configuration audit. If the audit is unsuccessful, the message field lists details on the failed audit. The audit failure message indicates missing commands and configuration issues. Carefully review the information in the message field. If the audit fails, you must correct all errors and redeploy the service request.
Step 5 Click OK to return to the Service Request Details window.
Viewing a Functional Audit Report
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. Prime Provisioning automatically provides a functional audit whenever a service request is deployed or force-redeployed. A functional audit could fail if BGP peering is incorrect, MPLS setup in the core is faulty, or remote links are down.
Functional audits can be performed manually through the Prime Provisioning Task Manager. For information on how to create a task to manually schedule a functional audit, see This chapter contains the following sections:.
To display the functional audit report for a service request, perform the following steps.
Step 1 Choose
Operate > Service Requests > Service Request Manager
.
The Service Request Manager window appears.
Step 2 Choose a service request for the functional audit.
Step 3 Click Details.
The Service Request Details window appears.
Step 4 Click the
Audit
button and choose
Functional
from the drop-down list.
The Service Request Audit Report window appears.
This window lists the device name and role, and a message regarding the status of your configuration audit. If the audit is unsuccessful, the message field lists details on the failed audit. The audit failure message indicates missing commands and configuration issues. Carefully review the information in the message field. If the audit fails, you must correct all errors and redeploy the service request.
Step 5 Click OK to return to the Service Request Details window.
Viewing Service Request Configlets
After you deploy the service request, Prime Provisioning generates Cisco IOS or IOS XR commands to turn on appropriate services on all the network devices that participate in the service request.
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.
To view the configlets that are generated, perform the following steps.
Step 1 Choose
Operate
>
Service Requests > Service Request Manager
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.
Step 3 Click the
Details
button.
The Service Request Details window appears.
Step 4 Click the
Configlets
button.
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. 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.
Step 7 Click
OK
when you are finished viewing the configlet.
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. Prime Provisioning also allows the configlet to be viewed in CLI format. This feature is enabled by setting the DCPL property
DCS/getCommitCLIConfigAfterDownload
to true (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
Operate
>
Service Requests > Service Request Manager
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.
Step 3 Click the
Details
button.
The Service Request Details window appears.
Step 4 Click the
Configlets
button.
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 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.
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.
Step 8 To toggle among different formats, use the following radio buttons:
-
XML Configlet
—Displays the configlet in XML format.
-
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.
Step 9 Click
OK
when you are finished viewing the configlet.
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 1 Click the
Inventory > Physical Inventory > Devices
.
The Devices Inventory window appears.
Step 2 Check the check box next to the device name to choose the configuration file versions you want to view.
Step 3 Click
Config
.
The Device Configurations window appears.
The Device Configurations window 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 4 Choose the version of the configuration file you want to view, then click
Edit
.
The contents of the selected configuration file are displayed.
You can view or edit the displayed device configuration file.
Step 5 If necessary, edit the configuration file.
Step 6 When finished editing the file, click
Save
.
Viewing the Status of Service Requests
From the Service Request Manager window, you can obtain status information on a service request as detailed in the following sections.
Viewing Links
To view information about links associated with a service request, perform the following steps.
Step 1 Choose
Operate
>
Service Requests > Service Request Manager
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 links.
Step 3 Click the
Status
button and choose
Links
.
The SR Link window appears.
This window displays a list of links associated with this service request.
Step 4 When you are finished reviewing the information, click the
Return to SRs
button.
Viewing Logs
To view logs associated with a service request, perform the following steps.
Step 1 Choose
Operate
>
Service Requests > Service Request Manager
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 links.
Step 3 Click the
Status
button and choose
Logs
.
The Task Logs window appears.
This window displays the task by
Runtime Task Name
, and the
Action
,
Start Time
,
End Time
, and the
Status
of the task. You can use this window to view or delete the logs.
Step 4 To view the log, check the check box for the row that represents the task and click the
View Log
button.
The Task Log page appears.
It is possible to set the types of log level you want to view. Specify the Log Level and click
Filter
button to view that information you want to view.
Step 5 Click
Return to Logs
to specify another log to view.
Step 6 When you are finished reviewing the log information, click the
Close
button.
Previewing Configlets for Deploy and Decommission
The preview configlet operation allows you to preview the configlet(s) that are sent to a device (or devices) for a selected service request before the device is actually provisioned. This allows you to ensure that the service request is generating the expected configlet(s), including relevant templates that may be applied.
Note the following caveats:
-
The preview deployed configlet feature is available to service requests in all states except Delete.
-
The preview configlet feature is not supported for TEM service requests.
To preview configlets for a service request, perform the following steps.
Step 1 Choose
Operate
>
Service Requests > Service Request Manager
.
Step 2 In the Service Request Manager window, select a service request and click the Preview drop-down list.
Step 3 To preview the configlet for deploy, select Preview Deploy.
Step 4 To preview the configlet for decommissioning, select Preview Decommissioning.
The Configlet Preview window displays the generated configlets for each device in the service request.
This operation may take some time, as the configlet(s) must be uploaded from the device.
Note Preview Decommission does not support the display of configlets derived from Templates. When you request Preview Decommissioning for a service Request associated with Templates, it will throw the exception/error, “Preview Decommission is not supported for Service Requests associated with templates.”
Step 5 After you review the configlets, click OK to return to the Service Request Manager window.
Deploying Service Requests
To apply either policies or device changes to network devices, you must first deploy the service request. When you deploy a service request, Prime Provisioning compares the device information in the Repository (the Prime Provisioning database) with the current device configuration and generates a configlet.
While deploying multiple service requests, the below mentioned points can result in deployment failure.
-
The type of service request being performed, and the resources that would be required for these services.
-
The device(s) that are being interacted with and if these devices are used by other Service Requests being requested at the same time.
-
The current running-configuration on the device.
-
The number of services that are currently present and modelled on each device.
-
Network latency between the NMS and the managed devices
For a successful deployment, it is advised to have 2 to 3 seconds time gap between each service request deployment.
Service Deployment
To deploy the service requests immediately or schedule their deployment, perform the following steps.
Step 1 Choose
Operate > Service Requests > Service Request Manager
.
The Service Requests Manager window appears.
Step 2 Check the check box next to the Job ID for the service request you want to deploy.
Step 3 Click the
Deploy
drop-down list.
You have the following deployment options:
-
Deploy Now
—This performs an immediate Force Deploy of the service request.
-
Deploy Later
—This brings up the scheduler, which allows you to schedule when you want to deploy the service request. This performs a Force Deploy of the service request.
-
Simulated Deploy Now
—See Simulated Deployment of Service Requests, for information on this choice.
If you choose
Deploy Later
, the Deploy Service Request dialog box appears.
Step 4 Complete the fields in this dialog box to schedule the service requested as needed.
Step 5 When satisfied with the schedule settings, click
Save
.
You return to the Service Request Manager window.
Step 6 Once the service request has been deployed, check the Status display in the pop-up window at the lower corner of the window.
If the service request has been deployed successfully, the Status display appears and shows a check in the Succeeded check box.
Step 7 To update the State from Requested to Deployed, check the
Auto Refresh
check box.
Note You can view logs to check on the task status and whether or not it completed successfully. For information on viewing logs, see Viewing Logs.
Monitoring Service Requests
To monitor a service request that is being deployed, you must use the task logs to help you troubleshoot why a service request has failed or to find more details about a service request.
To monitor a service request, perform the following steps.
Step 1 Choose
Operate > Tasks > Task Manager
.
The Task Logs window appears.
Step 2 Click
Find
to refresh the window.
The task that is executing will be the first in the list of tasks that are being performed in Prime Provisioning.
Step 3 Choose the task you want to monitor and click
Logs
.
Step 4 Choose the run-time task that you want to monitor and click
View Log
.
Step 5 Choose the log level from the
Log Level
drop-down list and click Filter.
The log levels are All, Severe, Warning, Info, Config, Fine, Finer, and Finest.
Step 6 Click
Return to Logs
.
Step 7 Click
Close
in the Task Logs window.
Simulated Deployment of Service Requests
Simulate deploy is an additional option when deploying a service request. To use this feature, you must first set the DCPL property
Services\Common\allowSimulateDeploy
to true. When enabled, any service request that you can deploy by a standard deploy operation (for example, moving a service request from the Requested to Deployed state) can also be deployed in simulation mode. In a simulated deployment the provisioning flow proceeds as normal up to the point at which the configlet is to be downloaded to the device. For example, a live configuration will still be uploaded from the device. However, when downloading a configlet, Prime Provisioning will act as if in echo mode (that is, the configuration will not be downloaded to the actual device). In effect, this is echo mode on a per service request basis. Multiple deployment operations, both standard and simulated, can run concurrently using a mixture of echo-based transport and live device interactions.
To simulate deploy a service request, perform the following steps.
Step 1 Choose
Operate > Service Requests > Service Request Manager
.
The Service Requests Manager window appears.
Step 2 Check the check box next to the Job ID for the service request you want to deploy.
Step 3 Click the
Deploy
drop-down list.
Assuming the DCPL property
Services\Common\allowSimulateDeploy
has been set to true, you have three deployment options:
-
Deploy Now
-
Deploy Later
-
Simulate Deploy Now
Step 4 Choose
Simulate Deploy Now
.
The Deploy Service Request dialog box appears, which allows you to schedule when you want to simulate deploy the selected service request.
Step 5 Complete the fields in this dialog box to schedule the service requested as needed.
Step 6 When satisfied with the schedule settings, click
Save
.
You return to the Service Request Manager window.
Check the Status display in the pop-up window at the lower corner of the window. If the service request has been deployed successfully, the Status display appears and shows a check in the Succeeded check box.
Step 7 To update the State from Requested to Deployed, check the
Auto Refresh
check box.
Note You can view logs to check on the task status and whether or not it completed successfully. For information on viewing logs, see Viewing Logs.
Decommissioning Service Requests
To decommission a service request, perform the following steps.
Step 1 Choose
Operate
>
Service Requests > Service Request Manager
.
Step 2 In the Service Request Manager window, select the service request you want to decommission.
Step 3 Click the Decommission drop-down list.
Choose one of the following options:
• Decommission Now—This performs an immediate decommissioning of the service request.
A popup window asks you to confirm the action. If you choose ‘yes’, the service request’s OpType is set to Delete and the deployment of this service request is performed immediately. If you choose ‘no’, the request is canceled.
• Decommission Later—This brings up the scheduler which allows you to be schedule the decommissioning at a specified date and time by specifying the number of times the service request is to be decommissioned.
Step 4 Complete the fields in this dialog box to schedule the service requested as needed.
Step 5 Click Save.
The Service Request Manager window is displayed.
Step 6 Once the service request has been decommissioned, a pop-up window displays the Status of the decommissioning in the lower right corner of your screen.
Step 7 After deployment, verify that the State of the service request state is changed to Closed. This indicates that the service request has been decommissioned successfully.
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, Prime Provisioning compares the device information in the Repository (the Prime Provisioning database) with the current device configuration and generates a configlet. When the configlet is generated and downloaded to the device, the service request enters the Pending state. When the device is audited, the service request enters the Deployed state.
Prime Provisioning 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).
Figure 10-1, “Service Requests States Transition Diagram,” shows a high-level diagram of the relationships and movement among Prime Provisioning service request states.
Figure 10-1 Service Requests States Transition Diagram
Table 10-1
, “
Summary of Prime Provisioning Service Request States
,” describes the functions of each Prime Provisioning service request state. They are listed in alphabetical order.
Table 10-1 Summary of Prime Provisioning Service Request States
|
|
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. Prime Provisioning does not remove a service request from the database to allow for extended auditing. Only a specific administrator delete 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, Prime Provisioning downloaded the configlets to the routers and the service request passed the audit process.
|
Failed Audit
|
This state indicates that Prime Provisioning 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.
|
In Progress
|
Whenever a service request is requested for deployment, irrespective of its current state, it displays the In Progress state. The In Progress state is an intermediate state between Requested and Deployed. Whenever multiple service requests are concurrently requested for deployment, they all display the state of In Progress.
|
Table 10-2
, “
User Operations on Prime Provisioning Service Requests
,” describes user operations and their impact on Prime Provisioning service requests.
Table 10-2 User Operations on Prime Provisioning Service Requests
|
|
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 Delete
|
This user operation removes a service request from the database irrespective of its state. If you Force Delete a service request from the Prime Provisioning 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 Prime Provisioning.
|
Delete
|
When a service request is deleted, it is removed from the Prime Provisioning database.
|