QoS Policies Tab

Configuration > Templates & Policies > Policies > QoS Policies

QoS policies determine how flows are queued and marked. Use the QoS Policies tab to view the QoS policies that exist on the appliances selected in the appliance tree. This includes the appliance-based defaults, entries applied manually by using the Appliance Manager or CLI, and entries that result from applying an Orchestrator QoS Policy template or Business Intent Overlay.

Use the Shaper to define, prioritize, and name traffic classes. The Shaper defines, and the QoS policy assigns. For information about the Shaper, see Shaper Tab.

To directly manage QoS policies for a particular appliance, click the associated edit icon. To create and manage QoS policies by using a template, click Manage QoS Policies with Templates.

For details about fields on this tab, see QoS Policies Dialog Box below.

QoS Policies Dialog Box

Use the QoS Policies dialog box to directly manage QoS policies for a particular appliance.

Set Actions for QoS policies determine two things:

  • To what traffic class a shaped flow—optimized or passthrough—is assigned

  • Whether to trust incoming DSCP markings for LAN QoS and WAN QoS, or to remark them as they leave for the WAN

Handle and Mark DSCP Packets

  • DSCP markings specify end-to-end QoS policies throughout a network.

  • The default values for LAN QoS and WAN QoS are “trust-lan”.

Apply DSCP Markings to Optimized (Tunnelized) Traffic

  • The appliance encapsulates optimized traffic. This adds an IP outer header to packets for travel across the WAN. This outer header contains the WAN QoS DSCP marking.

  • LAN QoS: The DSCP marking applied to the IP header before encapsulation.

  • WAN QoS: The DSCP marking in the encapsulating outer IP header. The remote appliance removes the outer IP header.

img

img

img

img

Apply DSCP Markings to Passthrough Traffic

  • The appliance applies the QoS policy’s DSCP markings to all passthrough flows—shaped and unshaped.

  • Passthrough traffic does not receive an additional header, so it is handled differently:

    • The QoS policy’s LAN QoS Set Action is ignored.

    • The specified WAN QoS marking replaces the packet’s existing LAN QoS DSCP marking.

    • When the packet reaches the remote appliance, it retains the modified QoS setting as it travels to its destination.

img

img

img

img

Priority

  • If you are using Orchestrator templates to add rules, Orchestrator will delete all entries from 1000 – 9999 before applying its policies.

  • You can create rules with higher priority than Orchestrator rules (1 – 999) and rules with lower priority (10000 – 19999 and 25000 – 65534).

    NOTE: The priority range from 20000 to 24999 is reserved for Orchestrator.

  • When adding a rule, the priority is incremented by 10 from the previous rule. The priority can be changed, but this default behavior helps to ensure you can insert new rules without having to change subsequent priorities.

Match Criteria

Match criteria are used universally across all policy maps for route, QoS, optimization, SaaS NAT, and firewall zone security policies.

To use the same match criteria in different maps, create an ACL (Access Control List), which is a named, reusable set of rules. For efficiency, navigate to Configuration > Templates & Policies > ACLs > Access Lists to create ACLs, and then apply them across your appliances.

Use the Match Criteria dialog box to select and configure a variety of match criteria options. Some are explained below:

  • Address Map: Use this option to sort by country, IP address owner, or SaaS application. You can also select and configure Microsoft Instance, Microsoft Category, and Proxy attributes for an address map. These attributes are secondary parameters to the address map. They are evaluated for a policy match only when the configured address map matches the flow. To select and configure these attributes, click +Attributes.

  • Match criteria options related to Secure Web Services include:

    • URL: Omit the protocol in URLs and include a slash character (/) or a slash followed by a query parameter. For example, google.com/ or google.com/maps are valid; https://google.com/ is not valid. You can also use the asterisk (*) wildcard character, such as in google.com/*, to specify a domain, but it is more appropriate to use the Domain match criteria option to specify google.com/. Separate multiple URL addresses with the pipe character (|). For example, you can specify two URL addresses as bing.com/*|google.com/*.

    • Web Category: If you select this option, click Select, and then click Strict, Moderate, or Custom. Strict and Moderate include predetermined web category selections, which you cannot change. However, if you attempt to select or clear a web category for these, the Custom group of web category selections opens automatically. You can customize web category selections in the Custom group. After you make your selections, click Ok.

    • Web Reputation: If you select this option, select one or more web reputation categories (High Risk, Suspicious, Moderate Risk, Low Risk, or Trustworthy) from the list. To select more than one, press and hold the Shift key, and then click the appropriate categories.

    • Bad IP Reputation: Selecting this option matches on flows for which the source or destination IP address (or both) has a High Risk reputation score.

  • Match criteria options related to RADIUS user role include:

    • User Role: This is the user role as specified in the authentication exchange with the ClearPass RADIUS server.

    • User Name

    • User Group

    • User Device

    • User MAC

    • User Vlan

    Configuring these match criteria related to user role enables an EdgeConnect to automatically assign traffic steering and firewall zone policies.

  • Use the Src:Dest check box associated with several match criteria options to specify separate criteria for inbound and outbound traffic. You can configure source and destination role-based policies when both source and destination users are in the same network.

Source or Destination

  • An IP address can specify a subnet; for example, 10.10.10.0/24 (IPv4) or fe80::204:23ff:fed8:4ba2/64 (IPv6).

  • To allow any IP address, use 0.0.0.0/0 (IPv4) or ::/0 (IPv6).

  • Ports are available only for the protocols tcp, udp, and tcp/udp.
  • To allow any port, use 0.

Wildcard-based Prefix Matching Rules

  • Even when using a range or a wildcard, the IPv4 address must be specified in the 4-octet format, separated by the dot notation. For example, A.B.C.D.

  • Range is specified using a single dash. For example, 128-129.

  • Wildcard is specified as an asterisk (*).

  • Range and Wildcard can both be used in the same address, but an octet can only contain one or the other. For example, 10.136-137.*.64-95.

  • A wildcard can only be used to define an entire octet. For example, 10.13*.*.64-95 is not supported. Use 10.130-139.*.64-95 to specify this range.

  • The same rules apply to IPv6 addressing.

  • CIDR notation and (Range or Wildcard) are mutually exclusive in the same address. For example, 192.168.0.1-127/24 is not supported. Use either 192.168.0.0/24 or 192.168.0.1-127.

  • These prefix-matching rules apply to the following policies only: Route, QoS, Optimization, NAT, Security, and ACLs.