Application Monitoring
The next question is how to identify the different application types in the network. The first option is to enable NetFlow (or IPFIX in the future) at strategic locations in the network and export the flow records to a NetFlow Collector. If just application monitoring is required, a router-based aggregation such as protocol-port would be sufficient. Refer to Tables 7-4 and 7-5 in Chapter 7, "NetFlow," for a complete list of the different router-based aggregations. A report from the Cisco NetFlow Collector, shown in Figure 13-7, can classify the traffic according to the source and destination application port, protocol, and volume in bytes or packets. However, if additional details are required in the report, exporting more information is interesting.
Figure 13-7. Cisco NetFlow Collector
In this case, selecting a router-based aggregation that contains additional parameters is the option of choice. For example, the protocol-port-tos or prefix-port aggregation drills deeper into the packets to discover more flow parameters.
A higher level of flow granularity is obtained when the devices export the full flow records, where the Cisco NetFlow Collector allows monitoring of individual flows classified by IP addresses.
Note that Flexible NetFlow offers some flexibility in the flow record definition required for a specific application.
The collection of NetFlow records is not limited to the Cisco NetFlow Collector. Numerous Cisco partners developed their own NetFlow Collector and monitoring applications. Figure 13-8 shows the NetFlow Tracker from Crannog (acquired by Fluke Networks), which displays the application types and conversations. By clicking a time and an application type, you can see a drilldown, as shown in the popup windows.
Figure 13-8. Crannog NetFlow Tracker
Application type reports typically account for a large amount of HTTP traffic.
However, NetFlow does not support the classification per payload information. For example, NetFlow cannot classify peer-to-peer traffic such as BitTorrent, Kazaa, Morpheus, Gnutella, and others. Instead of NetFlow, NBAR is the selection of choice for detecting application ports and distinguishing and categorizing traffic per payload information. Figure 13-9 shows an NBAR snapshot from the CiscoWorks QoS Policy Manager (QPM).
Figure 13-9. QoS Policy Manager: Per-Class Traffic Monitoring
