Link Search Menu Expand Document

QoS Policies Tab

Configuration > Templates & Policies > Policies > QoS Policies

QoS Policy determines how flows are queued and marked.

The QoS Policies tab displays the QoS policy entries that exist on the appliances. This includes the appliance-based defaults, entries applied manually (via 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. Think of it as the Shaper defines and the QoS Policy assigns.

Use the Templates tab to create and manage QoS policies for multiple appliances, or click the Edit icon to manage QoS Policies directly for a particular appliance.

img

The QoS Policy’s SET actions determine two things:

  • To what traffic class a shaped flow—optimized or pass-through—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 Pass-through Traffic

  • The appliance applies the QoS Policy’s DSCP markings to all pass-through flows—shaped and unshaped.

  • Pass-through traffic does not receive an additional header, so it is handled differently:

    • The Optimization 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

  • These are universal across all policy maps—Route, QoS, Optimization, NAT (Network Address Translation), and Security.

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

  • The available parameters are Application, Address Map (for sorting by country, IP address owner, or SaaS application), Domain, Geo Location, Interface, Protocol, DSCP, IP/Subnet, Port, and Traffic Behavior.

  • To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

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

  • 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 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. The correct way to specify this range is 10.130-139.*.64-94.

  • The same rules apply to IPv6 addressing.

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

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

QoS Policies Edit Row

QoS Policy determines how flows are queued and marked.

The QoS Policies tab displays the QoS policy entries that exist on the appliances. This includes the appliance-based defaults, entries applied manually (via 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. Think of it as the Shaper defines and the QoS Policy assigns.

Use the Templates tab to create and manage QoS policies for multiple appliances, or click the Edit icon to directly manage QoS Policies for a particular appliance.

The QoS Policy’s SET actions determine two things:

  • To what traffic class a shaped flow—optimized or pass-through—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 Pass-through Traffic

  • The appliance applies the QoS Policy’s DSCP markings to all pass-through flows—shaped and unshaped.

  • Pass-through traffic does not receive an additional header, so it is handled differently:

    • The Optimization 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

  • These are universal across all policy maps—Route, QoS, Optimization, NAT (Network Address Translation), and Security.

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

  • The available parameters are Application, Address Map (for sorting by country, IP address owner, or SaaS application), Domain, Geo Location, Interface, Protocol, DSCP, IP/Subnet, Port, and Traffic Behavior.

  • To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

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

  • 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 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. The correct way to specify this range is 10.130-139.*.64-94.

  • The same rules apply to IPv6 addressing.

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

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


Back to top

© Copyright 2022 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.