The EasyQoS feature provides three levels of business-relevance groupings that provide different levels of service to the applications that have been assigned to them. The business-relevance groups essentially map to three types of traffic: high priority, neutral, and low priority. These groups include:

• Business Relevant—(High-priority traffic) The applications in this group directly contribute to organizational objectives and, as such, may include a variety of applications, including voice, video, streaming and collaborative multimedia applications, database applications, enterprise resource applications, email, file-transfers, content distribution, and so on. Applications designated as business-relevant are treated according to industry best-practice recommendations, as prescribed in IETF RFC 4594.

• Default—(Neutral traffic) This group is intended for applications that may or may not be business-relevant. For example, generic HTTP/HTTPS traffic may contribute to organizational objectives at times, while at other times such traffic may not. You may not have insight into the purpose of some applications (for instance, legacy applications or even newly deployed applications), so the traffic flows for these applications should be treated with the Default Forwarding service, as described in RFC 2747 and 4594.

• Business Irrelevant—(Low-priority traffic) This group is intended for applications that have been identified to have no contribution towards achieving organizational objectives. They are primarily consumer- and/or entertainment-oriented in nature. We recommend that this type of traffic be treated as a "Scavenger" service, as described in RFC 3662 and 4594.

Some applications are completely symmetrical and require identical bandwidth provisioning on both ends of the connection. Traffic for such applications is described as bidirectional. For example, if 100 kbps of LLQ are assigned to voice in one direction, 100 kbps of LLQ also must be provisioned for voice in the opposite direction (assuming that the same VoIP codecs are being used in both directions, and putting aside for a moment multicast Music-on-Hold [MoH] provisioning). However, certain applications, such as Streaming-Video and multicast MoH, are most often unidirectional. Therefore, it might be unnecessary and even inefficient to provision any bandwidth guarantees for such traffic on a branch router for the branch-to-campus direction of traffic flow.

EasyQoS allows you to specify whether an application is unidirectional or bidirectional for a particular policy.

On switches and wireless controllers, NBAR2 and custom applications are unidirectional by default. However, on routers, because only NBAR applications are supported, NBAR2 applications are bidirectional by default.

You can configure relationships between applications such that when traffic from one application is sent to another application (thus creating a specific a-to-b traffic flow), the traffic is handled in a specific way. The applications in this relationship are called procucers and consumers and are defined as follows:

Producer—Sender of the application traffic. For example, in a client/server architecture, the application-server would be considered the producer, as the traffic primarily flows in the server-to-client direction. In the case of a peer-to-peer application, the remote peer is considered the producer.

Consumer—Receiver of the application traffic. The consumer may be a client endpoint in a client/server architecture or it may be the local device in a peer-to-peer application. Consumers may be endpoint devices but may, at times, be specific users of such devices (typically identified by IP Addresses and/or specific subnets). There may also be times when an application is the consumer of another application's traffic flows.

Setting up this relationship allows you to configure specific service levels for traffic matching this scenario.

Custom applications are applications that you add to the EasyQoS NBAR2 application library. You can define URL-based applications and server IP address-based applications.

When you define an application according to its server IP address, you can also define a Differentiated Services Code Point (DSCP) value and port classification.

To simplify the configuration process, if you know of an application that has similar traffic and service level needs, you can define a similar application. EasyQoS copies the other application's traffic class, category, and subcategory settings to the application that you are defining.

EasyQoS does not configure Access Control Lists (ACEs) for port numbers 80, 443, and 8080, even if they are defined as part of a custom application. If the custom application has a transport IP defined, EasyQoS configures the application on the devices.

If you are using the IWAN application, and you create a custom application that IWAN does not support, EasyQoS displays a warning, and the new custom application is not visible from the IWAN application.

Note	Unless custom applications are assigned to a policy, they are not programmed on the devices.

Cisco APIC-EM allows you to flag applications that you want EasyQoS to configure on devices before all other applications, except custom applications. Flagging an application as a favorite helps to ensure that the QoS policies for your favorite applications get configured on devices. For more information, see Processing Order for Devices with Limited Resources

Although there is no limit to the number of favorite applications that you can create, selecting only a small number of favorite applications (for example, less than 25) will help to ensure that these applications are treated correctly from a business-relevance perspective in deployments with network devices that have limited TCAM.

Favorite applications can belong to any business relevancy group or traffic class and are configured system-wide, not on a per-scope basis. For example, if you flag the cisco-jabber-video application as a favorite, the application is flagged as a favorite in all policies.

Keep in mind that not only business-relevant applications may be flagged as favorites, but even business-irrelevant applications may be flagged as such. For example, if an administrator notices a lot of unwanted Netflix traffic on his network, he may chose to flag Netflix as a favorite application (despite its being assigned as business-irrelevant). In this case, Netflix would be programmed into the device policies before other business-irrelevant applications, ensuring that the business-intent of controlling this application is realized.

Some network devices have a limited memory (called Ternary Content Addressable Memory or TCAM) for storing network access control lists (ACLs) and access control entries (ACEs). So, as ACLs and ACEs for applications are configured on these devices, the available TCAM space is used. When the TCAM space is depleted, QoS settings for no additional applications can be configured on that device.

To ensure that QoS policies for the most important applications get configured on these devices, EasyQoS allocates TCAM space based on the following order:

1. Rank—Number assigned to custom and favorite applications, but not to existing, default NBAR applications. The lower the rank number, the higher the priority. For example, an application with rank 1 has a higher priority than an application with rank 2, and so on. Having no rank is the lowest priority.

   • Custom applications are assigned rank 1 by default.

   • Default NBAR applications are not assigned a rank until you mark them as favorites, at which point they are assigned rank 10,000.

2. Traffic Class—By traffic class in the following order: Signaling, Bulk Data, Network Control, Operations Administration Management (Ops Admin Mgmt), Transactional Data, Scavenger, Multimedia Streaming, Multimedia Conferencing, Real Time Interactive, Broadcast Video, and VoIP Telephony

3. Popularity—Number (1–10) that is based on Cisco Validated Design (CVD) criteria. The popularity number cannot be changed. An application with a popularity of 10 has a higher priority than an application with a popularity of 9, and so on.

   • Custom applications are assigned popularity 10 by default.

   • Default NBAR applications are assigned a popularity number (1–10) that is based on Cisco Validated Design (CVD) criteria. When you mark an application as a favorite, this does not change the popularity number (only rank is changed).

4. Alphabetization—If two or more applications have the same rank and/or popularity number, they are sorted alphabetically by the application’s name, and assigned a priority accordingly.

For example, you define a policy that has the following applications:

• Custom application, custom_realtime, which has been assigned rank 1 and popularity 10 by default.

• Custom application, custom_salesforce, which has been assigned rank 1 and popularity 10 by default.

• Application named corba-iiop, which is in the transactional data traffic class, and you have designated as a favorite, giving that application a ranking of 10,000 and popularity of 9 (based on CVD).

• Application named gss-http, which is in the Ops Admin Mgmt traffic class, and you have designated as a favorite, giving that application a ranking of 10,000 and popularity of 10 (based on CVD).

• All other, default NBAR applications, which have no rank, but will be processed according to their traffic class and default popularity (based on CVD).

According to the prioritization rules, the applications are configured on the device in this order:

In the QoS Policy Manager window, you can view the results of the policy configuration that was applied on the devices. With a policy selected, EasyQoS displays the list of the devices in the policy scope and the status of the configuration on each device.

There are two types of QoS policies, named for the way in which the policies are implemented:

• Static policies—Deployed to devices and in effect until you change or remove them. Static policies comprise the majority of the deployments.

• Dynamic policies—Used on LAN interfaces only. Dynamic policies are applied to the relevant network devices for the duration of an event, for example, during a voice or video call. When the call ends, the policy is removed from the device. For more information, see Understanding Queuing Profiles.

You can preview the command line interface (CLI) commands that EasyQoS will send to a device when you apply the policy. At any time, for example, after a policy change, you can generate the specific commands for a specified device. After reviewing the commands, you can apply the policy to all of the devices in the scope, or you can continue to make changes to the policy.

After you create or change a policy, you need to apply or reapply the policy to the devices associated with it. When you click Apply or Reapply, EasyQoS gives you the option to apply (or reapply) the policy immediately or at a specific date and time, for example, on a weekend during off-peak hours. You can schedule a policy deployment for wired or wireless devices.

After you've scheduled a policy to be deployed, the policy and policy scope are locked. You can view the policy, but you cannot edit it. If you change your mind about deploying the policy, you can cancel it up until the time that it is deployed. Once deployment begins, you cannot cancel it.

Policies are versioned. You can display previous versions of a policy and select a version to reapply to the devices in a scope.

Editing one version of a policy does not affect other versions of that policy or the components of the policy, such as the applications that the policy manages. For example, deleting an application from a policy does not delete the application from EasyQoS, other versions of that policy, or even other policies. Because policies and applications exist indepentent of each other, you may reapply a policy version that contains applications in it that no longer exist.

Note	Application level modifications like rank, port, and protocol are not captured in policy versioning.

The first time that you apply an EasyQoS policy configuration to devices, EasyQoS detaches the device's original MQC policies (leaving the MQC policy configurations on the device) and stores the device's original NBAR configurations on the Cisco APIC-EM controller. This action allows you to restore the original MQC policies and NBAR configuration onto the devices later, if needed.

Note	Because the MQC policies are detached and not deleted from the device conifguration, if you remove these policies, you will not be able to restore them using the EasyQoS original policy restore feature.

When you restore the original policy configuration onto a device, EasyQoS removes the existing EasyQoS policy configuration that you applied to the devices and reverts to the original configuration that was on the device before you applied any EasyQoS policy configurations.

Any marking and queuing (MQC) policy configurations that existed before any EasyQoS policies were configured are reattached to the interfaces. Queuing policies (MLS configurations) are not restored; instead, the devices retain the MLS configurations that were last applied through EasyQoS.

After you restore the original policy configuration to the device, the EasyQoS policy is deleted from the Cisco APIC-EM, and the status of the devices shows Policy Restored. The devices are counted in WIRED NEW DEVICES after successful restore, WIRED FAILED if unsuccessful.

Note the following additional guidelines and limitations for this feature:

• Original policy restore does not work for policies that were created and applied to devices using the Cisco APIC-EM Release 1.2.x or below, because the Cisco APIC-EM did not store devices' original policy configurations before Cisco APIC-EM Release 1.3.x

• If the first attempt to push an EasyQoS policy to a device fails, EasyQoS automatically attempts to restore the original policy configurations onto the devices.