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.
Protocol Name id type app-id
active-directory 473 L7 STANDARD L7/473
an 107 L3 IANA L3/107
http 80 L4 IANA L4/80
my-server 247 Custom CU/247
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:
- Generate a classifier for NBAR build in applications
- 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!