A B D E H I M O Q R S T

app-id

/in /by

Related entries

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 http://www.rfc-editor.org/rfc/rfc6759.txt 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: http://tools.ietf.org/html/rfc6759
  • 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!