Traffic Class app-class:<class>

SRND is a 12-Class QoS classification model based on RFC 4594, which is very commonly used among enterprises and is well supported in NBAR and in other network elements and services from Cisco. Therefore, the most important and useful attributes are the ones used by the SRND QOS feature by default – traffic-class and business-relevance. Using these values should be as simple as possible, therefore short notations for these values are proposed.

This also aligns with the classification done by APIC-EM Easy QoS app or other SRND 4.0 based QoS provisioning solutions.

Below are the supported values for Traffic Class and Business Relevance, along with the shortcuts and the Business Relevance defaults per class.


(RFC 4594) DNS-AS-RR (LONG) DNS-AS-RR(SHORT) DNS-AS-RR(SHORT)     802.11e    
VoIP Telephony app-class:VOIP-TELEPHONY app-class:VO business:yes EF Priority Queue (PQ) Cisco IP Phones (G.711, G.729)
Broadcast Video app-class:BROADCAST-VIDEO app-class:BV business:yes CS5 (Optional) PQ Cisco IP Video Surveillance / Cisco Enterprise TV
Real-Time Interactive app-class:REALTIME-INTERACTIVE app-class:RTI business:yes CS4 (Optional) PQ Cisco TelePresence
Multimedia Conferencing app-class:MULTIMEDIA-CONFERENCING app-class:MMC business:yes AF4 BW Queue + DSCP WRED Cisco Jabber, Cisco WebEx
Multimedia Streaming app-class:MULTIMEDIA-STREAMING app-class:MMS business:yes AF3 BW Queue + DSCP WRED Cisco Digital Media System (VoDs)
Network Control app-class:NETWORK-CONTROL app-class:NC business:yes CS6 BW Queue EIGRP, OSPF, BGP, ISIS, HSRP, IKE
Signaling app-class:SIGNALING app-class:CS business:yes CS3 BW Queue SCCP, SIP, H.323
Ops / Admin / Mgmt app-class:OPS-ADMIN-MGMT app-class:OAM business:yes CS2 BW Queue SNMP, SSH, Syslog
Transactional Data app-class:TRANSACTIONAL-DATA app-class:TD business:yes AF2 BW Queue + DSCP WRED ERP Apps, CRM Apps, Database Apps
Bulk Data app-class:BULK-DATA app-class:BD business:yes AF1 BW Queue + DSCP WRED E-mail, FTP, Backup Apps, Content Distribution
Best Effort app-class:BEST-EFFORD app-class:BE business:default DF 0 Default Queue + RED Default Class
Scavenger app-class:SCAVENGER app-class:SCV business:no CS1 0 Min BW Queue (Deferential) YouTube, Netflix, iTunes, BitTorrent, Xbox Live


The idea here is to use the same traffic-class name like being used inside the C3PL policy map to move applications seamlessly into the right traffic-class.


Application ID app-id:<engine-id>/<selector-id>

Application ID is an ID exported by AVC which explains to what  application a particular flow belongs to.

The numeric application ID is specified using format. This RFC specifies the application ID model used in Cisco AVC. In this model the application ID is divided into an Engine ID and a Selector ID.

  • Application-ID is divided into a Selector ID and Engine ID separated by a slash
  • Selector-ID is encoded as a simple numeric value between <1-65535>
  • Engine-ID is encoded as either a textual representation or a number

The Application ID is divided into two parts:

  • Engine ID— A unique identifier for the engine that determined the Selector ID. The Classification Engine ID defines the context for the Selector ID. The Engine ID is the first eight bits that provide information about the engine that classifies the flow. IANA-L4, CANA-L3, and so on, are some of the engines that can be classified using an engine ID. Note that the Engine ID does not represent the NBAR2 mechanism used to classify the application. For more information about the engine IDs, see the information available here:
  • Selector ID—The remaining 24 bits that provide information about the application. 495(MS office) is one of the applications that can be classified using the classification ID.

In the case of DNS-AS the  TXT/AVC record the term selector ID is replaced by app-id. Usually the textual representation of app-id is using a colon but since we use colons to separate the option from the value, we’re using a slash.

Any other engine ID should be encoded numerically. e.g. CANA-L4 is engine ID of 4 so a selector ID of 4739 on CANA-L4 should be encoded as: app-id:4/4739
For the full list of Engine IDs see: EDCS-816617

In the case of DNS-AS there are two ways to classify applications:

  1. Generate a classifier for  NBAR build in applications
  2. Generate a classifier for  NBAR custom applications

In case the combination of (app-id|app-name) does not match the NBAR taxonomy, apps are treated as custom apps, therefore we use the Engine ID CU (custom) with the prefix cu/

Application ID for Flexible Netflow Export

  • For a single network device the significance of the app-id is low as MQC is confined by nature to a single device.
  • On the other hand, FNF is used to export records from multiple devices to a centralized netflow collector. The collector use both app-name and app-id
  • If we have 2 applications with the same app-name but with a different app-id it will be treated by the collector as 2 different applications thus leading to a inconsistent report.

Consistent FNF reporting

We achieve consistent reporting between NBAR build in, NBAR custom and non NBAR enabled devices in the following way:

if dns-as(app-id|app-name) eq nbar-pp(app-id|app-name)

  • NBAR-enabled (routers): we’re fine, as there is no NBAR and we just export (app-id|app-name)
  • NBAR-disabled (switches): also fine, as we match NBAR so no custom app gets created and the export of (app-id|app-name) is inline

if dns-as(app-id|app-name) !eq nbar-pp(app-id|app-name)

  • NBAR-enabled (routers):we’re fine, as there is no NBAR and we just export (app-id|app-name)
  • NBAR-disabled (switches):we don’t match NBAR so a custom app gets created but the (app-id|app-name) form DNS-AS is being exported

Point is that all the times we report (app-id|app-name) in a consistent way!


Application Name app-name:<name>

Application Name indicates a name of an application to be used to classify the entity being described. By default, it describes the HOST for which the record belongs.
Please be aware that an Application Name does not equals the protocol! While NBAR classifies applications based on the protocol they’re communication over the Application Name outlines the “spoken name” of that application.

Application names comprise of:

  • Application name with a length of min 3 and max 24 characters
  • No whitespace
  • ASCII Alphanumeric characters
  • The following characters are allowed in addition: ‘-‘ (hyphen)
  • On switches without NBAR the app-name can match the NBAR local taxonomy
  • Custom names for applications are possible

There are two classes of Application Names:

  1. Predefined: if you want to use for matching predefined applications you need to match the NAME being used inside the NBAR taxonomy
  2. Custom: if you want to create a NBAR2 custom application or if the Network Device itself has no NBAR capabilities.