3. Network QoS Policies
3.1. Network QoS Policies Overview
The ingress component of the policy defines how DiffServ Code Points (DSCPs) and MPLS EXP bits are mapped to internal forwarding class and profile state. The forwarding class and profile state define the Per Hop Behavior (PHB) or the QoS treatment through the router. The mapping on each network interface defaults to the mappings defined in the default network QoS policy until an explicit policy is defined for the network interface.
The egress component of the network QoS policy defines the DiffServ oriented queuing parameters associated with each forwarding class.
Each forwarding class defined within the system automatically creates a queue on each network interface. This queue gets all the parameters defined within the default network QoS policy 1 until an explicit policy is defined for the network interface.
If the egressing packet originated on an ingress SAP, or the remarking parameter is defined for the egress interface, the egress QoS policy also defines the IP DSCP or MPLS EXP bit marking based on the forwarding class and the profile state.
Network policy-id 1 exists as the default policy that is applied to all network interfaces by default. The network policy-id 1 cannot be modified or deleted. It defines the default DSCP-to-FC mapping and MPLS EXP-to-FC for the ingress. For the egress, it defines six forwarding classes that represent individual queues and the packet marking criteria.
New (non-default) network policy parameters can be modified. The no form of this command reverts the object to the default values. A new network policy must include the definition of at least one queue and specify the default-action. Incomplete network policies cannot be applied to network interfaces.
Changes made to a policy are applied immediately to all network interface where the policy is applied. For this reason, when a policy requires several changes, it is recommended to copy the policy to a work area policy-id. The work-in-progress copy can be modified until all the changes are made, then the original policy-id can be overwritten with the config qos copy command.
For information about the tasks and commands necessary to access the CLI and to configure and maintain router devices, refer to the CLI Usage chapter in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide.
3.2. Network Ingress Tunnel QoS Override
3.2.1. Override For Tunnel Terminated IP Routing Decisions
This section describes a mechanism that provides the ability to ignore the network ingress QoS mapping of a terminated tunnel containing an IP packet that is to be routed to a base router or VPRN destination. This is advantageous when the mapping for the tunnel QoS marking does not accurately or completely reflect the required QoS handling for the IP routed packet. When the mechanism is enabled on an ingress network IP interface, the IP interface will ignore the tunnel’s QoS mapping and derive the internal forwarding class and profile based on the precedence or DiffServe Code Point (DSCP) values within the routed IP header ToS field compared to the Network QoS policy defined on the IP interface.
3.2.1.1. Normal QoS Operation
The following types of QoS mapping decisions are applicable on a network ingress IP interface.
- Ethernet dot1p value mapping (if defined)
- Default QoS mapping
- IP ToS precedence mapping
- IP ToS DSCP mapping
- MPLS LSP EXP mapping
The default QoS mapping always exists on an ingress IP interface and every received packet will be mapped to this default if another explicitly defined matching entry does not exist.
A tunnel that terminates on the ingress IP interface (the node is the last hop for the tunnel) is evaluated based on the type of tunnel: IP GRE or MPLS LSP. An IP tunneled packet may match a dot1p entry, IP ToS precedence entry, or IP ToS DSCP entry when defined in the applied policy. An MPLS LSP may match a dot1p entry or MPLS EXP entry when defined.
The internal tunnel encapsulated packet is never evaluated for QoS determination when operating in normal mode.
3.2.1.2. Network Ingress IP Match Criteria
IP match criteria classification is supported in the ingress section of a network QoS policy.
The classification only applies to the outer IPv4 header of non-tunneled traffic; consequently, the use of an ip-criteria statement in a network QoS policy is ignored for received traffic when the network QoS policy is applied on the ingress network IP interface in the following cases:
- Mesh SDPs in VPLS services
- Spoke SDPs in VPLS and Xpipe services
- Spoke SDPs under an IP interface in an IES or VPRN service
- Spoke SDPs in a VPRN service
- Automatically created bindings using the auto-bind-tunnel command in a VPRN service
- IPv6 over IPv4 tunnels
- VXLAN bindings (egress VTEP, VNI)
The only exception is for traffic received on a Draft Rosen tunnel, for which classification on the outer IP header only is supported.
Attempting to apply a network QoS policy containing an ip-criteria statement to any object except a network IP interface will result in an error.
The following is a sample configuration:
3.2.1.3. Network Ingress IPv6 Match Criteria
IPv6 match criteria classification is supported in the ingress section of a network QoS policy.
The classification only applies to the outer IPv6 header of non-tunneled traffic; consequently, the use of an ipv6-criteria statement in a network QoS policy is ignored for received traffic when the network QoS policy is applied on the ingress network IP interface in the following cases:
- Mesh SDPs in VPLS services
- Spoke SDPs in VPLS and Xpipe services
- Spoke SDPs under an IP interface in an IES or VPRN service
- Spoke SDPs in a VPRN service
- Automatically created bindings using the auto-bind-tunnel command in a VPRN service
- IPv6 over IPv4 tunnels
- VXLAN bindings (egress VTEP, VNI)
Attempting to apply a network QoS policy containing an ipv6-criteria statement to any object except a network IP interface will result in an error.
The following is a sample configuration:
3.2.1.4. Storing Match-Criteria Entries
FP2-, FP3-, and FP4-based cards store QoS policy match-criteria entries in dedicated memory banks in hardware, also referred to as CAM tables:
- IP/MAC ingress
- IP/MAC egress
- IPv6 ingress
- IPv6 egress
3.2.1.4.1. FP4-based Cards
To optimize both scale and performance, policy match-criteria entries configured by the operator are compressed by each FP4 line card prior to being installed in hardware.
This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition where entries for a line card QoS policy on a line card FP are not programmed. This overload condition can occur when applying a QoS policy for the first time on a line card FP or when adding entries to a QoS policy.
Applying a QoS Policy
A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP or ESM subscriber host was using the policy on this FP.
A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP. In this case, none of the entries for the affected QoS match-criteria policy are programmed, and the QoS policy queuing, FC mapping, and FC marking are unaffected.
Adding QoS Match-Criteria Entries
Adding an additional entry to a QoS policy can lead to a compression failure resulting in an overload condition.
In this case, the newly added entry is not programmed on the affected FP. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP as the system attempts to install all outstanding additions in order.
The CPM QoS management task controls the maximum number of match criteria entries per FP. If the operator attempts to go over the scaling limit, the system will return an interactive error message.
Note: A trap is raised if a policy is in overload, there is no interactive error message.
Removing QoS Match-Criteria Entries
Removing match-criteria entries from a QoS policy is always successful.
Resolving Overload
The overload condition should be resolved by the network operator before adding new entries in the affected policy.
To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted memory bank. Based on this information, the tools>dump>qos>match-criteria-overload command allows the operator to identify the affected policy and policy entries in the system.
To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.
3.2.1.5. Tunnel Termination QoS Override Operation
Tunnel termination QoS override only applies to IP routing decisions when the tunnel encapsulation is removed. Non-IP routed packets within a terminating tunnel are ignored by the override and are forwarded as described in the Normal QoS Operation section.
When tunnel termination QoS override is enabled, the ToS field within the routed IP header is evaluated against the IP ToS precedence and DSCP entries in the applied network QoS policy on the ingress IP interface. If an explicit match entry is not found, the default QoS mapping is used. Any dot1p and MPLS LSP EXP bits within the packet are ignored. If the packet was IP GRE tunneled to the node, the tunnel IP header ToS field is ignored as well.
Any tunnel received on the ingress IP interface that traverses the node (the node is not the ultimate hop for the tunnel) is not affected by the QoS override mechanism and is forwarded as described in Normal QoS Operation section.
3.2.1.6. Enabling and Disabling Tunnel Termination QoS Override
Tunnel termination QoS override is enabled and disabled within the network QoS policy under the ingress node. The default condition within the policy is not to override tunnel QoS for IP routed packets.
3.3. Egress Packet Reclassification Based on IPv4/IPv6 Criteria
The user enables IP precedence or DSCP based egress re-classification by applying the following command in the context of the network QoS policy applied to the egress context of a spoke-SDP.
config>qos>network>egress>prec ip-prec-value [fc fc-name] [profile {exceed | out | in | inplus}]
config>qos>network>egress>dscp dscp-name [fc fc-name] [profile {exceed | out | in | inplus}]
The IP precedence bits used to match against DSCP reclassification rules come from the Type of Service (ToS) field within the IPv4 header or the Traffic Class field from the IPv6 header.
The IP DSCP bits used to match against DSCP reclassification rules come from the Type of Service (ToS) field within the IPv4 header or the Traffic Class field from the IPv6 header.
If the packet does not have an IP header, DSCP or IP-precedence based matching is not performed.
The IP precedence and DSCP based re-classification are supported on a network interface, on a CSC network interface in a VPRN, and on a PW used in an IES or VPRN spoke-interface. The CLI blocks the application of a network QoS policy with the egress re-classification commands to a network IP interface or to a spoke-SDP part of L2 service. Conversely, the CLI does not allow the user to add the egress re-classification commands to a network QoS policy if it is being used by an L2 spoke-SDP.
In addition, the egress re-classification commands only take effect if the redirection of the spoke-SDP or CSC interface to use an egress port queue-group succeeds; for example, the following CLI commands succeed:
config>service>vprn>if>spoke-sdp>egress>qos network-policy-id port-redirect-group queue-group-name instance instance-id
config>service>ies>if>spoke-sdp>egress>qos network-policy-id port-redirect-group queue-group-name instance instance-id
config>service>vprn>nw-if>qos network-policy-id port-redirect-group queue-group-name instance instance-id
When the redirection command fails in CLI, the PW uses the network QoS policy assigned to the network IP interface, however any reclassification in the network QoS policy applied to the network interface will be ignored.
3.4. QoS for Self-Generated (CPU) Traffic on Network Interfaces
Differentiated services code point (DSCP), forwarding class (FC), and IEEE 802.1p values can be specified to be used by protocol packets generated by the node. This enables prioritization or deprioritization of every protocol (as required). The markings effect a change in behavior on ingress when queuing.
DSCP marking for internally generated control and management traffic should be used for the given application. This can be configured per routing instance. For example, OSPF packets can carry a different DSCP marking for the base instance than for a VPRN service. ARP, IS-IS, and PPPoE are not IP protocols, so only 802.1p values can be configured.
The DSCP value can be set per application. When an application is configured to use a specified DSCP value, the 802.1p and MPLS EXP bits will be marked in accordance with the network (default 802.1p value of 7) or access (default 802.1p value of 0) egress policy as it applies to the logical interface that the packet will be egressing.
The configuration of self-generated QoS is supported in the base router, VPRN, and management contexts.
The default values for self-generated traffic on network interfaces are:
- Routing protocols (OSPF, BGP, etc.)
- Forwarding class: Network Control (NC)
- DSCP value: NC1 (not applicable for ARP, IS-IS, and PPPoE)
- 802.1p value: according to the egress QoS policy (7 by default)
- Management protocols (SSH, SNMP, etc.)
- Forwarding class: Network Control (NC)
- DSCP value: AF41
- 802.1p value: according to the egress QoS policy (7 by default)
The default QoS values for self-generated traffic on network interfaces are listed in Table 19.
Table 19: Default QoS Values for Self-Generated Traffic
Protocol | DSCP |
ANCP | NC1 |
APS | NC1 |
ARP | N/A |
BFD | NC1 |
BGP | NC1 |
Cflowd | NC1 |
DHCP | NC1, AF41, NC2 |
Diameter | AF41 |
DNS | AF41 |
FTP | AF41 |
GTP | NC2 |
ICMP | BE, NC1 |
IGMP | NC1 |
IGMP Reporter | NC1 |
IS-IS | N/A |
L2TP | NC1 |
LDP/T-LDP | NC1 |
LMP | NC1 |
MLD | NC1 |
MSC (Multichassis Support) | NC1 |
MSDP | NC1 |
ND (NDIS) | NC1, NC2 |
NTP/SNTP | NC1 |
OpenFlow | NC1 |
OSPF | NC1 |
PCEP | NC1 |
PIM | NC1 |
PPPoE | N/A |
PTP | NC1 |
RADIUS | NC1 |
RIP | NC1 |
RSVP | NC1 |
sFlow | NC1 |
SNMP Gets/Sets | AF41 |
SNMP Traps | AF41 |
SRRP | NC1 |
SSH, SCP, SFTP | AF41 |
Syslog | AF41 |
TACACS+ | AF41 |
Telnet | AF41 |
TFTP | AF41 |
Traceroute | BE |
TWAMP, TWAMP Light | N/A |
VRRP | NC1 |
WSC | NC1 |
XMPP | NC1 |
 | Note: ICMP echo requests (type 8) and ICMPv6 echo requests (type 128) initiated from the router will use the DSCP value set by the sgt-qos command. The FC value is NC by default, or the value specified in the ping command parameter fc fc-name. |
| Note: The DSCP values for TWAMP and TWAMP Light test packets are not configured with sgt-qos commands. The DSCP value for TWAMP test packets reflected by the TWAMP server is specified in the TWAMP control process. The DSCP value for TWAMP Light test packets is set by the test configuration. The TWAMP Light reflector uses the arriving TWAMP test packet to determine the return DSCP value. |
| Note: Some applications have multiple DSCP default values depending on the context or service. |
| Note: Configurable values for ANCP, APS, BFD, LMP, MSC, OpenFlow, WSC, and XMPP are not supported. |
3.4.1. Default DSCP Mapping Table
*The default forwarding class mapping is used for all DSCP names/values for which there is no explicit forwarding class mapping.
3.5. Basic Configurations
A basic network QoS policy must conform to the following:
- Each network QoS policy must have a unique policy ID.
- Include the definition of at least one queue.
- Specify the default-action.
3.5.1. Creating a Network QoS Policy
Configuring and applying QoS policies other than the default policy is optional. A default network policy of the appropriate type is applied to each router interface.
To create a network QoS policy when operating, define the following:
- A network policy ID value. The system will not dynamically assign a value.
- Include a description. The description provides a brief overview of policy features.
- Egress criteria can be modified to customize the forwarding class queues to be instantiated. Otherwise, the default values are applied.
- Remarking — When enabled, this command remarks all packets that egress on the specified network port. The remarking is based on the forwarding class to DSCP and LSP EXP bit mapping defined under the egress node of the network QoS policy.
- Forwarding class criteria — The forwarding class name represents an egress queue. The forwarding class criteria define the egress characteristics of the queue and the marking criteria of packets flowing through it.
- DE marking — Specifies that the DE bit should be marked based on whether the packet profile is in-profile, inplus-profile, out-of-profile, or exceed-profile.
- dot1p — The dot1p value is used for all VLAN-tagged packets requiring marking that egress on this forwarding class queue, with the option of specifying a different value for packets that are in-profile or out-of-profile. Inplus-profile traffic is marked with the same values as in-profile traffic. Exceed-profile traffic is marked with the same values as out-of-profile traffic.
- DSCP — The DSCP value is used for all IP packets requiring marking that egress on this forwarding class queue that are in-profile or out-of-profile. Inplus-profile traffic is marked with the same values as in-profile traffic. Exceed-profile traffic is marked with the same values as out-of-profile traffic.
- LSP EXP — The EXP value is used for all MPLS-labeled packets requiring marking that egress on this forwarding class queue that are in-profile or out-of-profile. Inplus-profile traffic is marked with the same values as in-profile traffic. Exceed-profile traffic is marked with the same values as out-of-profile traffic.
- Port redirection — Specifies that the traffic should be redirected to a network egress queue group policer or queue.
- DSCP — Creates a mapping between the DSCP of the network egress traffic and the forwarding class and profile. Egress traffic that matches the specified DSCP is assigned to the corresponding forwarding class with the specified profile.
- Prec — Creates a mapping between the IP precedence of the network egress traffic and the forwarding class and profile. Egress traffic that matches the specified IP precedence is assigned to the corresponding forwarding class with the specified profile.
- Ingress criteria — Specifies the DSCP- or dot1p-to-forwarding class mapping for all IP packets and defines the MPLS EXP bits-to-forwarding class mapping for all labeled packets.
- Default action — Defines the default action to be taken for packets that have an undefined configured classification. The default action specifies the forwarding class and profile to which such packets are assigned.
- dot1p — Creates a mapping between the dot1p of the network ingress traffic and the forwarding class and profile. Ingress traffic that matches the specified dot1p is assigned to the corresponding forwarding class and profile.
- DSCP — Creates a mapping between the DSCP of the network ingress traffic and the forwarding class and profile. Ingress traffic that matches the specified DSCP is assigned to the corresponding forwarding class.
- Forwarding class — The forwarding class name represents an ingress queue.
- IP criteria — Creates a mapping between the possible match criteria of the network ingress traffic and the forwarding class and profile. Ingress traffic that matches the IPv4 criteria is assigned to the corresponding forwarding class and profile.
- IPv6 criteria — Creates a mapping between the possible match criteria of the network ingress traffic and the forwarding class and profile. Ingress traffic that matches the IPv6 criteria is assigned to the corresponding forwarding class and profile.
- LER use DSCP — Specifies that DSCP matching based on the tunneled IP packet should be used on an LER rather than matching on the outer encapsulated header.
- LSP EXP — Creates a mapping between the LSP EXP bits of the network ingress traffic and the forwarding class and profile. Ingress traffic that matches the specified LSP EXP bits is assigned to the corresponding forwarding class and profile.
Use the following CLI syntax to create a network QoS policy:
3.5.2. Applying Network QoS Policies
Use the following CLI syntax to apply network policies to the router access uplink port’s IP interfaces:
The following output displays the configuration for router interface ALA-1-2 with network policy 600 applied to the interface.
3.5.3. Default Network QoS Policy Values
The default network policy for IP interfaces is identified as policy-id 1. Default policies cannot be modified or deleted. Table 20 lists default network policy parameters.
Table 20: Network Policy Defaults
Field | Default | ||||
description | Default network QoS policy. | ||||
scope | template | ||||
ingress | |||||
default-action | fc be profile out | ||||
dscp | |||||
be | fc be | profile out | |||
ef | fc ef | profile in | |||
cs1 | fc l2 | profile in | |||
nc1 | fc h1 | profile in | |||
nc2 | fc nc | profile in | |||
af11 | fc af | profile in | |||
af12 | fc af | profile out | |||
af13 | fc af | profile out | |||
af21 | fc l1 | profile in | |||
af22 | fc l1 | profile out | |||
af23 | fc l1 | profile out | |||
af31 | fc l1 | profile in | |||
af32 | fc l1 | profile out | |||
af33 | fc l1 | profile out | |||
af41 | fc h2 | profile in | |||
af42 | fc h2 | profile out | |||
af43 | fc h2 | profile out | |||
lsp-exp | |||||
0 | fc be | profile out | |||
1 | fc l2 | profile in | |||
2 | fc af | profile out | |||
3 | fc af | profile in | |||
4 | fc h2 | profile in | |||
5 | fc ef | profile in | |||
6 | fc h1 | profile in | |||
7 | fc nc | profile in | |||
egress | |||||
remarking | no | ||||
fc af | |||||
dscp-in-profile | af11 | ||||
dscp-out-profile | af12 | ||||
lsp-exp-in-profile | 3 | ||||
lsp-exp-out-profile | 2 | ||||
fc be | |||||
dscp-in-profile | be | ||||
dscp-out-profile | be | ||||
lsp-exp-in-profile | 0 | ||||
lsp-exp-out-profile | 0 | ||||
fc ef | |||||
dscp-in-profile | ef | ||||
dscp-out-profile | ef | ||||
lsp-exp-in-profile | 5 | ||||
lsp-exp-out-profile | 5 | ||||
fc h1 | |||||
dscp-in-profile | nc1 | ||||
dscp-out-profile | nc1 | ||||
lsp-exp-in-profile | 6 | ||||
lsp-exp-out-profile | 6 | ||||
fc h2 | |||||
dscp-in-profile | af41 | ||||
dscp-out-profile | af42 | ||||
lsp-exp-in-profile | 4 | ||||
lsp-exp-out-profile | 4 | ||||
fc l | |||||
dscp-in-profile | af21 | ||||
dscp-out-profile | af22 | ||||
lsp-exp-in-profile | 3 | ||||
lsp-exp-out-profile | 2 | ||||
fc l2 | |||||
dscp-in-profile | cs1 | ||||
dscp-out-profile | cs1 | ||||
lsp-exp-in-profile | 1 | ||||
lsp-exp-out-profile | 1 | ||||
fc nc | |||||
dscp-in-profile | nc2 | ||||
dscp-out-profile | nc2 | ||||
lsp-exp-in-profile | 7 | ||||
lsp-exp-out-profile | 7 | ||||
The following output displays the default configuration:
3.6. Service Management Tasks
3.6.1. Deleting QoS Policies
A network policy is associated by default with router interfaces.
The default policy can be replaced with a non-default policy, but cannot be removed from the configuration. When a non-default policy is removed, the policy association reverts to the appropriate default network policy.
The following output displays a sample configuration.
3.6.2. Removing a Policy from the QoS Configuration
To delete a network policy, enter the following commands:
3.6.3. Copying and Overwriting Network Policies
An existing network policy can be copied to a new policy ID value or overwrite an existing policy ID. The overwrite option must be specified or an error occurs if the destination policy ID exists.
The following output displays the copied policies:
3.6.4. Editing QoS Policies
Existing policies, except the default policies and entries in the CLI, can be changed. The changes are applied immediately to all interfaces where the policy is applied. To prevent configuration errors, use the copy command to make a duplicate of the original policy in a work area, make the edits, then overwrite the original policy.