Sub-request parameters

Configuring Sub-Request Ownership

By default, when the status of a change request changes, the owner of the parent request is not automatically assigned to the sub-requests. Configure this behavior as needed, for all or specific status changes.

Tip: This parameter is particularly relevant when using the GetRealGroupName hook. For details, see GetRealGroupName .

Configuration Parameter Name Value
DoNotCopyOwnerToSubTicketsStatuses

{"All":1}. (Default) Determines that sub-requests never inherit the owner value from their parent request.

{"None":1}. Determines that sub-requests always inherit the owner value from their parent request.

{ "All":1 } During all statuses, the parent ticket will not copy their owner to its sub tickets.

{ "None":1 } During all statuses, the parent ticket will copy their owner to its sub tickets.

{ "check":1 } The parent ticket will copy their owner to its sub tickets, except in the Approve (also known as 'Check') status.

{ "open":1, "check":1 } The parent ticket will copy their owner to its sub tickets, except in the Plan and Approve statuses.

{ "open":1, "check":1, "validate":1 } The parent ticket will copy its owner to its sub tickets, except in the Plan, Approve and Validate statuses.

Back to top

Configuring Sub-requests to Include Traffic for the Whole Change Request

By default, if a whole traffic line in a change request is not in a network map path that passes through the device, that traffic line will not be included in that device's sub-request. Furthermore, if NAT is taking place in some devices in the path, the IP addresses of the sub-request will change accordingly. If desired, you can configure FireFlow to include all traffic lines in all sub-requests.

Note: If the network map is inaccurate (paths are missing in), it is advised to disable the FIP algorithm in AFA. In this case, this feature will automatically be disabled and sub-requests will consequently include all traffic.

Configuration Parameter Name Value
PerSubRequestTrafficDifferentiation

0. To configure sub-requests to include all traffic lines as is.

1. To configure sub-requests to include only traffic lines in path and to modify their values according to NAT taking place in devices in the path. (Default)

Back to top

Enabling/Disabling Sub-Request Traffic Modification

By default, FireFlow does not allow users to modify traffic specified in sub-requests. If desired, you can enable sub-request traffic modification.

Note: When traffic modification in sub-requests is enabled you may edit existing traffic lines in sub-requests. Addition and removal of traffic lines is never allowed.

Configuration Parameter Name Value
ModifySubTicketChangeTraffic

0. To disable sub-request traffic modification. (Default)

1. To enable sub-request traffic modification.

Back to top

Configuring the Risk Check Method for Change Requests with Multiple Devices

In the Approve stage of a traffic change request's lifecycle, FireFlow performs a risk check, to determine whether implementing the change specified in the change request will introduce risks. The risk check is run on the device(s) specified in the change request, using the Risk Profile that the device was assigned when generating the last successful report in AFA.

When performing a risk check for a parent request with sub-requests, there are multiple devices and potentially multiple Risk Profiles involved. You can configure FireFlow to use any of the following risk check methods:

FireFlow runs the risk check on one random device out of all the sub-request devices.

For example, let us assume that there are three sub-requests, as follows:

Sub-request

Device

Risk Profile

500

Check Point A

r1

501

Check Point B

r2

502

Cisco C

r1

FireFlow will select a device at random (such as Cisco C) and run the risk check on it (using Risk Profile r1).

Only risk check results for the selected device will be displayed.

FireFlow runs the risk check on one random device per Risk Profile used by the sub-request devices.

In our example, there are two Risk Profiles, r1 and r2. FireFlow will select a device at random (either Check Point A or Cisco C) to run the risk check on using Risk Profile r1, and it will also run a risk check on Check Point B using Risk Profile r2.

Risk check results will be displayed per risk profile.

FireFlow runs the risk check on each of the sub-request devices.

In our example, FireFlow will run a risk check on Check Point A, Check Point B, and Check Point C, using their respective Risk Profiles.

Note that the risk check may take a while, and the results for each device may be similar.

Risk check results will be displayed for each device.

Configuration Parameter Name Value
RiskCheckOnParentTicket

one. To use the One method.

profile. To use the Profile method. (Default)

all. To use the All method.

Back to top