NetFlow, Cisco and traffic monitoring. Time to figure it out

Good day to all! Understanding NetFlow, such a simple, convenient and frequently used protocol, I realized that it is not so simple, and there are enough pitfalls in its operation.
Under the cut, I collected everything I needed to know about NetFlow and its settings on Cisco, paid tribute to eucariot, writing excellent articles about networks, and ... Pictures, some funny pictures.

We define the basic concepts

NetFlow is a proprietary open protocol developed by Cisco for monitoring network traffic. Netflow provides the ability to analyze network traffic at the session level, recording every TCP / IP transaction.
The system architecture is based on the sensor, collector and analyzer:
- The sensor collects statistics on the traffic passing through it. Sensors it makes sense to put in the "nodal points" of the network, for example, on the border routers of network segments.
- The collector collects information from the sensors. It dumps the received data to a file for further processing. Different collectors store data in different formats.
- The analyzer, or processing system, reads these files and generates reports in a form that is more convenient for the person. This system must be compatible with the data format provided by the collector [1] . In modern systems, the collector and analyzer are often combined into one system.



Typically, the collector and analyzer are parts of a single software package running on a server. Versions of the collector / analyzer software set, paid and free, under Windows and Unix-system.
In the article I will not touch on this area, I will consider only the principles of NetFlow and the configuration of the sensor on Cisco.
It is necessary to immediately understand - the collector and the analyzer behind it are “passive” elements of the system. The sensor sends traffic reports to the collector, receives the collector, the analyzer analyzes and fills its database on the server. In fact, with the server raised, we do not need to manually connect devices that are monitored on the server. While the sensor sends reports, the collector receives them, the analyzer registers. If the sensor is turned off, it "disappears" from the current "online" statistics.
')

Protocol Description

NetFlow uses UDP or SCTP to transfer traffic data to a collector. Typically, the collector listens on port 2055, 9555, or 9995 (or the one you specify when you configure the collector and sensor).
The sensor extracts from the passing traffic flows characterized by the following parameters:

• Source address;
• Destination address;
• Source port for UDP and TCP;
• Destination port for UDP and TCP;
• Message Type and Code for ICMP;
• IP number;
• Network interface (ifindex SNMP parameter);
• IP Type of Service.

A stream is a set of packets passing in one direction. When the sensor determines that the stream has ended (by changing packet parameters, or by resetting a TCP session), it sends information to the collector. Depending on the settings, it can also periodically send information to the collector about still flowing streams [2] .
This is a very important point - when setting up the sensor, we decide for ourselves what parameters the information sent to the collector will be combined in the reports.

Actually, setting

Let us analyze the sensor configuration when setting up on Cisco:

Router_NF # conf t
Router_NF (config) # ip flow-export destination 192.168.0.1 9996
Router_NF (config) # ip flow-export destination 10.10.0.1 9996
Router_NF (config) # ip flow-export version 9

In the configuration mode, we specify the collector addresses and ports, where to send the statistics, we specify the version of the NetFlow protocol. In a complex network, you can have two collector interfaces if there are any routing restrictions between segments

Router_NF (config) # ip flow-cache timeout active 1

We specify how often to refresh the NetFlow cache with data about the traffic of the still active session.

Router_NF (config) # ip flow-cache timeout inactive 15

We specify the time during which if no data is transmitted in the existing stream, it is closed, and information about it is recorded in the cache, and then transmitted to the collector

Router_NF (config) FastEthernet 0/0 ip flow-export source
Router_NF (config) # ip flow-export source vlan4
Router_NF (config) # ip flow-export source Port-channel1.2

Sources of traffic reports, statistics will be collected from them. On the analyzer side, there will be separate promonitory and interface, and VLAN, and Port-channel

!
ip access-list standard iacl-snmp
remark ACL for SNMP access to device
permit 192.168.0.1
permit 10.10.0.1
deny any log
!

Add ACL for more harmonious feng shui

!
snmp-server group snmp v1 access iacl-snmp
snmp-server group snmp v2c access iacl-snmp
snmp-server community ******** **** iacl-snmp
snmp-server ifindex persist
snmp-server trap-source Loopback0
snmp-server enable traps tty
!

Configuring snmp for proper recognition of interface names
Finally it came to the interface:

Router_NF (config) # interface FastEthernet 0/0
Router_NF (config-if) # ip flow egress
Router_NF (config-if) # ip flow ingress

Specify what traffic will be taken into account, entering into the interface or outgoing from it? If outgoing, then ip flow egress, if incoming, then ip flow ingress
Or

Router_NF (config-if) # ip route-cache flow

“Ip route-cache flow” can be used only for the main interface, and “ip flow ingress” is an extension for use for subinterfaces. NetFlow functionality Subinterface Support allows you to enable NetFlow for each subinterface. In a scenario where your network contains many subinterfaces, and you only need to collect records from some, you can fine-tune the collection of information from certain subinterfaces [3]

What you can see on the sensor:

Router_NF # show ip cache flow

Traffic information waiting to be sent to the collector

Router_NF # show ip cache verbose flow

Detailed traffic information waiting to be sent to the collector

Router_NF # show ip flow interface

Interfaces that are NetFlow sensors

Router_NF # show ip flow export

NetFlow source and destination reports, how many datagrams are sent, how many errors

Router_NF # show ip flow top-talkers

Information about the champions, presented categorically, up to the most visited Internet resources
On the basic setup, all useful links for more complete enlightenment [4] , [5] and [6].

A spoon of tar

"Other" traffic. As you know, many common applications have their own ports, consider

Figure taken from [7] .
However, over time, the proportion of traffic falling into the “Other” section is growing, due to the growing number of applications using dynamic, randomly generated ports.
Document [8] , which reviews NetFlow, casually mentions the problem, well illustrated in the figure.


Of course, it would be desirable for a very different traffic to be clearly described in the reports, for example:

Link to it [10] .

Progress does not stand still, technologies go forward, and the chief will receive a full report on the problem of unrecognized traffic being solved in various interesting ways, for example, using NBAR technology.
During the search, a discussion [11] and an interesting presentation [12] were found . I will not go further into the jungle, for youn is hot and inexperienced.

It is believed that the author of the post has a mess in his head, and he is missing something!