Verify change request results

Relevant for: Network operations users and requestors

This topic describes how to verify change validation results.

Tip: After making a change, you may want to wait a few minutes before validating the change. FireFlow can only detect changes after an AFA analysis has been run on the device.

In systems with scheduled monitoring configured, you must wait for the scheduled monitoring process to run.

Back to top

Verify change validation results (requestors)

Relevant for: Requestors

Once the device changes planned for your change request have been implemented, you will receive an email message from FireFlow, asking you to verify that the changes were implemented successfully.

You must check that the desired results were achieved, and respond in one of the following ways:

If your response indicates that the desired results were not achieved, your change request will be re-implemented and you will be asked to check the results again.

If your response indicates that you are satisfied with the results, the change request will be resolved.

Back to top

Verify change validation results (network operations users)

This procedure describes how network operations users can verify change validation results.

Do the following:

  1. View the change request. For details, see View change requests.

  2. If the validation results are not available or old, refresh the validation calculation by clicking Recalculate.

    The change validation results appear, indicating whether the implemented changes achieved the result specified in the change request.

    For example:

    Details are shown as follows:

    Object change, rule removal, and web filtering change requests

    The change validation verifies the changes specified in the work order were implemented by performing a traffic simulation query.

    • Validation succeeds if the query indicates the planned changes specified in the work order have been made for every traffic line in the change request.
    • Validation fails if the planned changes have not been made for at least one traffic line.
    Rule modification change requests

    The change validation displays whether the specified changes in the work order match the device policy.

    For more details, see Advanced change validation results.
    Traffic change and recertification requests

    The change validation verifies the changes specified in the work order were implemented with a traffic simulation query and a work order/device policy comparison.

    If the rule contains more traffic than recommended, FireFlow indicates this for you so that you can take any action, as required.

    For example:

    For more details, see Advanced change validation results.

    Note: If you implemented the changes even slightly differently than the work order, Validation will fail.

    For example, if the work order specified one rule with multiple sources, and you added multiple rules (with one source each), Validation will fail.

    This is particularly relevant for Amazon Web Services because rules can only include one object per field.

  3. To view extended information about the change validation, click Show details.

  4. If you do not see that the result you wanted was implemented, view device reports describing the problem by clicking the Find out why link.

    A report opens in a new window, and you can drill down to view the relevant device rules.

    Note: This option is not available for rule removal or rule modification requests.

  5. Click Next.

  6. If the desired result was not achieved, do the following:

    1. Re-implement the change(s). For details, see Resolve or return change requests.

    2. Repeat change validation.

For Palo Alto Networks Panorama devices, FireFlow will always recommend changing the lowest device group. If a higher level device group blocks the traffic the change request is attempting to allow, the traffic will still not be allowed after the work order is implemented, and validation will fail. To allow the traffic you must manually change the higher level device group.

If validation times out before the device has been analyzed, appears.

For more details, see Change validation parameters.

Back to top

Advanced change validation results

Traffic change, recertification, and rule modification requests support advanced change validation results.

  • Traffic change and recertification requests run a traffic simulation query and work order/ device policy comparison during validation.
  • Rule modification requests run a work order/ device policy comparison only.

Each change request receives an overall validation result, and individual validation results for each traffic line.

  • If all traffic line validations are successful, then the overall validation is successful.
  • If at least one traffic line validation partially succeeds or fails, the overall validation fails.

When the work order/ policy comparison determines a rule is a perfect match or more permissive, the change validation in addition verifies whether all object names used in the work order recommendation’s fields are the objects used in the matched rule’s fields.

By default, a discrepancy in object names will not cause validation to fail. For more details, see Change validation parameters.

In certain circumstances, change validation will fail even when the work order was implemented as specified.

The following are possible reasons for change validation failure:

  • The traffic is partially blocked by a rule that exists above the allowing rule. The partially blocking rule is not displayed in the validation details.
  • Part of the traffic was already allowed by another rule that is located lower in the policy.
  • The rule was added in incorrect zones/ interfaces.
  • Both a perfectly matched object and a wider rule exist, but only one of them is being matched.

Advanced change validation results are as follows, depending on the request type:

Traffic change/recertification requests
  • "Allow" traffic. Validation succeeds if the traffic simulation query indicates the planned traffic for the line is allowed, and the change on the device perfectly matches the work order recommendation.
  • "Drop" traffic. Validation succeeds if the traffic simulation query indicates the planned traffic for the line is blocked, and no rule exists on the device with the relevant IUD.
Rule modification requests

Validation succeeds if the change on the device perfectly matches the work order recommendation.

Traffic change/recertification requests

For "Allow" traffic, validation partially succeeds if the traffic simulation query indicates the planned traffic for the line is allowed, and the change on the device does not perfectly match the work order recommendation (but does not include traffic that is more permissive than the work order recommendation).
Rule modification requests

Validation partially succeeds if the change on the device does not perfectly match the work order recommendation, and does not include traffic that is wider than the work order recommendation.

Traffic change/recertification requests
  • "Allow" traffic. Validation fails if the traffic simulation indicates the planned traffic for the line is partially or fully blocked, or the change on the device is more permissive than the work order recommendation.
  • "Drop" traffic. Validation fails if the traffic simulation query indicates the planned traffic for the line is partially or fully allowed, or a rule exists on the device with the relevant IUD.
Rule modification requests

Validation fails if the change on the device is more permissive than the work order recommendation.

Back to top