VPN Console: Auditing Menu

At the time of creation, the state transitions of a Service Request are done by the provisioning system. This continues until the pending state. Beyond that it is the auditor's task to make the state transitions. The auditor is the Auditor for MPLS VPN Solution. It is a mechanism to monitor and report the current state of a VPN service request over its lifetime. It also provides the reasons why the service request is in its current state (audit detail). The Auditor also saves the state transition (if any) into the VPN Inventory Repository, known as the Repository. The lifetime of a VPN service request spans from the requested state to the closed state.

Figure 7-1, "Auditing Menu," provides a view of the Auditing menu in the menu task bar.

Figure 7-1: Auditing Menu

The Auditing menu includes the following options:

The valid states are: requested; pending; invalid; failed deploy; deployed; broken; functional; lost; closed. Note that sometimes an audit can move a service request through several states.

Some examples of moving past an intermediate state are:

1. An example of one set of transitions is pending > deployed > functional. The auditor takes in the service request in state pending. It moves to deployed and then does the functional test and moves it further to functional. Therefore, the resulting state change is pending > functional, which is not otherwise possible, but is in this case because of the transient state deployed.

2. An example of one state of transition is lost > deployed > functional. The auditor takes in the service request in state lost. It moves to deployed and then does the functional test and moves it further to functional. Therefore, the resulting state change is lost > functional, which is not otherwise possible, but is in this case because of the transient state deployed.

Generate Service Request Audit Reports

To start generating Audit reports, follow the steps in this section.

Step 1 From the VPN Console window, choose Auditing > Generate Service Request Audit Reports, as shown in Figure 7-2, "Generate Service Request Audit Reports."

Figure 7-2: Generate Service Request Audit Reports

Note An alternative to selecting Auditing > Generate Service Request Audit Reports is to select Tools > Tasks and then in the Actions menu item select New Task > Generate Service Request Audit Reports and click Ok. Both paths navigate to the same wizard.

Step 2 The first window is Introduction. It explains that: This wizard sets up a scheduled task that generates web-based VPN audit reports. To access the audit reports, choose Auditing > View Latest Audit Reports. These reports audit service requests and update their state depending on whether the service has been found in the most recently observed copies of the router configuration files. Options for more extensive audits are available, including auditing all service requests and using VPN routing information during audits.

Step 3 Click Next.

Step 4 The next window is s hown in Figure 7-3, "Types of Service Requests to be Audited."

Figure 7-3: Types of Service Requests to be Audited

Check the box next to each of the types to be audited, and then click Next. The types of service requests to be audited are the following two classes of audit and a behavior modifier:

Audit new service requests

: The Audit new service requests class of audit addresses all service requests that are in the pending (intermediate) state and tests whether they can be moved away from the pending (intermediate) state. The terminal state of the audit is deployed or, if Use VPN routing information during audits is also chosen, the terminal state of the audit is functional or broken. The Audit new service requests class is a required audit. It is the mechanism needed to pass the service request from the pending-to-be-deployed state to an operational or failed-to-become-operational state. The successful passing of this audit liberates the provisioning system from reconsidering this service request, thus lessening system overhead.

Note The Audit new service requests audit is run automatically as part of the Deploy Service Requests wizard.

Audit existing service requests

: The Audit existing service requests class of audit addresses all service requests that are in deployed, lost, functional, or broken states. If Use VPN routing information during audits is enabled, the terminal state is functional or broken. Otherwise, it is deployed or lost. Unlike the Audit new service requests class of audit, the Audit existing service requests class of audit is a surveillance audit. It tests whether there is a state change to an already operational or nonoperational service request. This auditor audits all service requests. Thus, as time progresses, the number of service requests could increase without limit and so could the time taken to complete this audit. The audit reports all Service Requests that were in the broken or lost state prior to the audit run and/or are currently in the broken or lost state after the audit run.

Use VPN routing information during audits

: If you choose this behavior modifier, the auditor uses the VPN routing information during its audits. This makes the auditor an operational or dynamic verification of a Service Request. If you do not choose this behavior, the auditor is only a configuration or static verification of a Service Request. For example, with this behavior chosen, a broken cable disrupting the Service could be discovered, which would not be discovered if this behavior was not chosen.

Note To Use VPN routing information during audits, you must collect the VPN routing information. See the "Collect VPN Routing Information" section.

Step 5 In the next window, as shown in Figure 7-4, "Providing a Task Name for Generating Service Request Audit Reports," provide a unique Task Name. Then click Next.

Figure 7-4: Providing a Task Name for Generating Service Request Audit Reports

Step 6 In the next window, you can choose to schedule the task by selecting Yes and clicking Next. In this case, the next step is Step 7.

You can choose not to schedule the task by selecting No and clicking Next. In this case, the next step is Step 8.

Step 7 If you chose to schedule the task, in the next window, choose the scheduling directions and click Next. See Chapter 11, "Scheduling," for a full detailed description of scheduling.

Step 8 If you did not schedule the task, you are informed that "The task manager is about to save the task." If you did schedule the task, you are informed that "The task manager is about to save and schedule the task." If you want to change your mind on the scheduling instructions, click Back and return to Step 6 or Step 7. When you are ready to save and schedule the task, click Next.

Step 9 You are informed that "All steps are done." Click Close to close the wizard.

Note Now that you have collected data for accounting, you can view this data as directed in the "View Latest Audit Reports" section.

View Latest Audit Repo rts

To view the latest audit reports, implement the following steps.

Step 1 From the VPN Console window, choose Auditing > View Latest Audit Reports, as shown in Figure 7-5, "View Latest Audit Reports."

Figure 7-5: View Latest Audit Reports

An example of the first window is shown in Figure 7-6, "View of Latest Audit Reports."

Figure 7-6: View of Latest Audit Reports

Note If a Service Request exists in multiple VPNs, the audit is run only once. It is run in the VPN that is first in an alphabetical sequence. Be sure to look in this first VPN in the alphabetical sequence for the audit report.

The Service Request is not run in other VPNs because of the following: (a) it has already been audited and there is nothing new to audit; (b) re-auditing is a costly process; and (c) the Service Request information and the associated audit information are already available in vpnconsole.

Table of Contents