: Add Performance Policy Rules
Focus
Focus

Add Performance Policy Rules

Table of Contents

Add Performance Policy Rules

Steps to add performance policy rules that are part of the performance sets.
Performance Policy rules can be defined with Link Quality and Application metrics thresholds. You can apply the rule at an application or transfer-type level, select Path filters; Circuit labels, Path types, and Data Center groups.
You can select a policy set and then add policy rules to the policy set. To edit the rule, click on the Policy Rule name.
To add a performance policy rule to a policy set:
  1. Go to
    Manage
    Policies
    Performance
    Performance Sets
    .
  2. Select a
    Policy Set
    Add Rule
    .
  3. In the
    Add New Rule
    General
    section, the
    Enable Rule
    is selected by default. Disable the rule if you do not want the ION device to consider this rule.
    1. Enter a
      Rule Name
      ,
      Description
      , and optional
      Tags
      for the policy rule.
    2. Enter an
      Order Number
      for the policy rule. An order of 1 will place the rule at the top of the list.
      You must organize specific rules at the top of the Policy Set list; otherwise, a less specific policy rule may be matched first.
      Performance Policy rules follow explicit ordering, wherein each rule within a policy set has an order number that is used, a set of match criteria, and a set of actions.
      The default order number will place the rule at the bottom of the policy set, just above the default rules. Rules will automatically reorder if a non-default rule order is specified.
  4. In the
    Action
    section, select one or more actions:
    1. Move Flows
      moves existing flows and excludes paths for new flows that are in violation of a performance SLA. These include both Link Quality and Application Metrics.
      When the Move Flows field is empty in a rule, the datapath won't consider Link Quality Metrics measurements during path selection.
    2. Raise Alarms
      generates incidents for both Applications and Circuits using Link Quality and application performance SLA criteria, where applicable incidents are automatically correlated.
    3. FEC
      (Forward Error Correction) must be enabled along with the
      Move Flows
      action. FEC only relies on the loss and Latency Link Quality Metrics and does not use Application metrics. FEC takes effect only on Prisma SD-WAN VPNs. If you enable FEC, note that:
      • FEC is effective on packet loss between 1% and 10%.
      • As the loss increases above 1% additional repair is added to the application session to which FEC is enabled on the VPN.
    4. Visibility
      affects the Secure Fabric Link time series by displaying the performance SLA indicator in the graph. Visibility solely depends on Link Quality Metrics and does not utilize Application metrics.
  5. In the
    Match Criteria
    section, choose the following filters:
    If the
    Match Criteria
    section is left blank, this will be considered a match any.
    1. (Optional)
      In
      App Filters
      , select an
      Application(s)
      from the drop-down to apply the policy rule. You can select 256 applications for one policy rule.
    2. (Optional)
      From the
      Application by Transfer Type
      drop-down, select the transfer type to be Bulk, Audio, Video, or Transactional.
    3. (Optional)
      In
      Path Filters
      , select the
      Path Category
      from the drop-down. Select an overlay and a Circuit Category for a path. You cannot repeat a combination of an overlay and a circuit category for a policy rule.
    4. (Optional)
      Select the
      Path Type
      as Direct, Prisma SD-WAN VPN, or Standard VPN.
    5. (Optional)
      Select the DC Group value from the drop-down. By default, if the section is left blank, all Service & DC Groups are included as well as branch to branch VPNs. If any DC Groups are specified then branch to branch VPNs are excluded.
  6. In the
    Performance SLAs
    section, you can either use an
    existing
    performance threshold, or to add a new threshold, click
    Add New
    .
    1. Select
      Link Quality Metrics
      and enter an SLA name.
      Link Quality Metrics are measured between branches and data centers when LQM is enabled on the branch circuit.
    2. Click the
      +
      sign to enter the
      Latency
      value (between 0-500ms),
      Jitter
      value (between 0-100ms), and the
      Packet Loss
      value (between 0-20%).
    3. Expand the
      Advanced Settings
      down arrow to set the values for
      Raise Above
      (between 10% to 100%) and
      Clear Below
      (between 1% to 80%).
      • Raise Above
        : If the aggregated percentage (comprising LQM samples over all paths for the same circuit) exceeds the configured percentage value, the system will raise an alarm for each circuit.
      • Clear Below
        : The system will clear the alarm for the same circuit when the aggregated percentage exceeds the configured percentage value.
    4. If you select
      Application Metrics
      , provide the
      Init Failure Rate
      (between 0-100%) and the
      RTT
      value (between 0-500ms).
      Init Failure rate is the percentage of TCP 3-way handshake failures and RTT is the TCP Round Trip Time from a client to the server and back to the client.
    5. Expand the
      Advanced Settings
      down arrow to set the values for
      Raise Above
      (between 10% to 100%) and
      Clear Below
      (between 1% to 80%).
      • Raise Above
        : If the aggregated bad sample percentage (across all prefixes) exceeds the configured threshold for bad samples, the system will raise an alarm for each application or path.
      • Clear Below
        : In case the aggregated good sample percentage (across all prefixes) exceeds the configured threshold for bad samples, the system will clear the alarm for each application or path.
    6. Use the drop-down to select the monitoring approach to control the incident generation.
      The monitoring approach actively adjusts using a time-based algorithm to control incident generation. A
      Conservative
      monitoring approach takes longer to trigger and clear an incident, as it evaluates a longer time period. Conversely, an
      Aggressive
      monitoring approach triggers and resolves incidents as conditions change. The time taken to generate and clear an incident depends on the configured percentages for raise above and clear below thresholds, the frequency of threshold violations over time, and the selected monitoring approach.

Recommended For You