Starting with NFA 9.2, NFA supports reporting on NBAR2 Application Data to give you greater visibility into Applications that cannot be identified simply by looking the destination port of the traffic.
Application mapping supports rules for the applications that are identified by the standard Cisco NBAR2 engine (NBAR2 engine 13), but not for applications that are identified by custom NBAR2 engines.
We also require that the NBAR2 ApplicationID be imported into NFA, see Tech Tip: How to import the NBAR2 Application Definitions into NFA for how to import the default list of NBAR2 Applications.
The steps below will show you how to verify that you are receiving the correct NBAR2 Engine ID of 13 and how to verify the ApplicationID within the NetFlow data using WireShark.
1) Open WireShark on the Harvester server and go to the “Capture” top menu and then “Options”
2) Double click the Interface which is receiving the NetFlow
3) In the “Capture Filter” field enter “host x.x.x.x and udp port 9995” where x.x.x.x is the IP address of the device you wish to monitor, and click OK
4)Click “Capture->Start” to begin capturing data.
5) Once you have captured enough data click Stop and then “Analyze->Decode As”
6) Change the drop down menu to “Destination (->9995)” and select “CFLOW” on the right and click OK
7) Once Decoded as CFLOW you will be able to expand where it says “Cisco NetFlow/IPFIX”
When looking at the flows, you will need to look for a field called:
“ApplicationID: NBAR Application ID: x:y (type:id)”
The ‘type’ or ‘x’ needs to be 13, which represents the Cisco NBAR2 EngineID, as we currently only support EngineID 13.
The ‘id’ or ‘y’ will be a unique number, that will need to match up with one of the ApplicationID’s in the NBAR2.csv file you imported into NFA. If it is an ID that does not exist you can create a new NBAR2 application definition. See the NFA Admin guide for details.
-The first example below shows an NBAR2 application which we would not display data from because the EngineID/Type is not 13:
-This second example shows an NBAR2 Application which we would be able to display data from, because as you can see below the EngineID/Type is 13. Also in this case the application ID, 26, matches up with an ID in the NBAR2.csv file, for the ‘netbios’ application:
8)You will also need to see NBAR2 data in the same Flowset ID/Template ID as the rest of the required NetFlow fields.
Below are the required fields for NetFlow data to be displayed in RA/NFA:
1 - IN_BYTES or 85 – IN_PERMANENT_BYTES (NFA Only)
4 - PROTOCOL
7 - L4_SRC_PORT
8 - IPV4_SRC_ADDR
10 - INPUT_SNMP
11 - L4_DST_PORT
12 - IPV4_DST_ADDR
14 - OUTPUT_SNMP
**Note in 9.2.1 and later we support ASA devices which adds two new supported fields.
In place of 1 - IN_BYTES or 85 - IN_PERMANENT_BYTES, ASA devices use both 231 - FW_INITIATOR_OCTETS and 232 - FW_RESPONDER_OCTETS which we now support.
Below is an example of a working NBAR2 pcap, where you can see highlighted in green are the required minimum fields.
Highlighted in Blue you can see the NBAR Application ID is in the same Flowset as the required fields and has an Engine ID of 13.
Also it the Netflow/IPFIX version shows up as 10, which indicates it is using IPFIX format, which seems like it it required in order to get the NBAR Application ID's to show up in the same Flowset as the rest of the Netflow required fields.
9)You should be able to see the data in your Interface Reports like below if they are the Top N applications on that interface. In this example you can see Skype and Exchange being reported:
10)You will also be able to run Flow Forensics reports against this NBAR2 data using the 'Conversation Sessions (NBAR2)' FF report which will show the NBAR2 Application ID and Engine ID.
