In 1996 Cisco created a method where routing decisions were based on flows, that is, the router would not need to query its routing table to perform a packet forwarding, packets belonging to the same flow were routed to the same route, the main goal was to speed up the lookups in the routing tables.
A flow is a set of packets that have the same values in the key identification fields, we can cite as an example the fields: source and destination IP, Source and destination port, IP protocol, ToS, and Input Interface (ifindex). These fields may vary depending on the flow protocols and versions used.
Subsequently, the value of a stream’s information was recognized and became more accessible to network managers, and the protocol was called Netflow. Throughout its history, another advantage of using Netflow has been perceived: in addition to making routing faster, as well as the protocol’s ability to store network traffic data and thus enable traffic monitoring. Another important observation is that placing a passive meter on each link in the network was unfeasible, so it was defined that the passive meters would be the network edges that export the flows.
For quantitative network monitoring, Netflow is critical for detailed traffic analysis. Having visibility into where your traffic is coming from, where it is going, its content, and several other items are critical for observability of network behavior in totality.
Functional architecture of flows
The generic flow operating architecture can be understood by three main components: sensors, collectors, and reporting systems:
A sensor, also known as probe, is a device configured to “listen” to the network and capture traffic data. It can be a switch, a router, or a firewall configured to export flow. The sensor tracks network connections and after a certain time of inactivity (Inactive Timeout) is identified or the connection reaches a time limit (Active timeout), the data is transmitted over the network.
A collector is a software that receives the data exported by the sensors and writes it to disk. It is a critical component in managing the network infrastructure, and besides this fact, there is no universal collector, there is no universal collector, that is, there is no standardization.
A reporting system reads files recorded by collectors and generates reports, charts, alarms, and the like.
Netflow and IPFIX versions
Netflow version 1
Netflow has undergone several revisions and updates throughout its history, version 1 is the oldest developed by Cisco, is obsolete, but some vendors still support this version, it offers as little information as possible in a flow record, it is limited to IPV4, and does not have fields such as ASN and subnet masks for example.
Netflow version 5
Netflow v5 flow record is the oldest with wide implementation on the market and is still well-used today. This version includes 7 key fields: source IP, destination IP, source port (TCP and UDP only), destination port, IP Protocol, input interface, and Type of Service (ToS). It also includes BGP information, the Flow exporter IP (IP of the interface that was configured to send the cache flow), and some other traffic characteristics. Over the years there has been a need to obtain more information in the flow record, such as IPV6, for example. However, Netflow v5 can meet the need for various network environments.
Netflow version 9
This is the final version of Cisco, the most complete. It is template-based and flexible, this flexibility refers to the fact that information from other manufacturers can be arbitrarily added to the flow record of netflow v9, templates provide flexibility to the flow record. This is the first version that supports IPV6.
It is worth highlighting some benefits offered by this version:
- Support is provided so that regardless of the company developing a netflow collector, it does not need to reinvent (recompile) its software whenever a new Netflow feature is implemented.
- New features can be added much faster without obstructing current implementations and with compatibility with previous implementations.
- NetFlow version 9 is the IETF’s standard mechanism for exporting information. (IPFIX IETF [v10])
IPFIX and other flow export protocols
As the versions of Netflow implemented in the market by Cisco evolved, other companies realized the benefit of data exported by flows. The implementation of Netflow in the market was a customization by Cisco itself, which initially was not a necessity in the computer network market. However, with the analysis potential that Netflow provided and its implementation versions on the market, other manufacturers developed similar flow-based solutions according to their customization needs. Other flow export protocols similar to Netflow were created, such as HP’s sFlow , Huawei’s Netstream , Juniper’s jFlow , among others.
As the number of competitors grew, the network community saw advantages regarding the implementation and market introduction of a standard flow export protocol, then IPFIX emerged.
In the early 2000s, the Internet Engineering Task Force (IETF) created a working group to determine the flow format standards. This group chose to use Netflow v9 as a base with few modifications, Cisco was still involved to some extent in the project, only as a member rather than a controlling institution. The latest version of the network flow standard is called IP Flow Information eXport (IPFIX).
Some benefits provided by Netflow
For a quantitative network monitoring, Netflow is fundamental for a stratified traffic analysis. We have separated some important benefits provided by Netflow and their respective implementation justifications.
Application Traffic Monitoring
Typically, source and destination ports are key fields in a flow, with this port identification it is possible to translate it to the application and with that, identify the traffic of each application within a network. This visibility is extremely relevant for implementation justifications and also costs.
Furthermore, from a more technical perspective, the possibility of identifying traffic by application greatly increases the technical team’s troubleshooting capacity. For example, if the network “is slow” due to some non-approved application, netflow will provide visibility into which communication (flow/flows) is generating this traffic and, in the flow, identify the ports and consequently correlate with the application. From there, the IT team can block these communication ports, creating an ACL for example.
Validation of QoS Policies
Type of Service (ToS) is one of the fields that is normally used as a key, in this sense, it is possible to classify the traffic of each tag and inspect if the traffic content of any specific tag corresponds to the QoS policies that were established.
Capacity planning is a systematic organization that aims to address a balance of the use of network resources so that they are not being underutilized, or that the demand generated by the use of these resources is close to the capacity of the network infrastructure, in addition, balancing these aspects of the finances of the business is also part of the scope of this plan.
In this sense, to be successful in this whole process, it is necessary to have a complete understanding of the current capacity of the technological park, and then, after this analysis, seek through predictive analysis, to understand what the essential capacity requirements will be for future demand.
With the traffic information collected by the export of flows, it is possible to identify the traffic of each one of the flows, compare it with the bandwidth of the existing links, check the traffic of subnets due to the IP ranges, among many other items on the network.
Source and destination IP information in Flow is very valuable for conducting a forensic analysis on the network, identifying network offending IPs and suspicious addresses. In addition, if the network is segmented, it is possible to perform identification through IP ranges, and thus monitor traffic from network locations, departments, among other information.
This planning is linked to the company’s corporate governance policies, and in this sense, IT becomes a fundamental ally in the company’s business decisions, besides guiding the institution to the right paths, bringing much more assertive decisions.
In the world of Internet Service Providers (ISP) it is very important to check traffic by ASN, traffic destined for a BGP peering, traffic destined to transit links, traffic destined to CDNs, traffic destined to your traffic exchange points (PTT) and others.
Netflow provides this visibility, in fact, one of the main goals of a provider that is starting a business and growing the number of its customers is the acquisition of a CDN. However, for this acquisition it is important to justify traffic, and Netflow can enable different types of traffic analysis for this proof, besides some other requirements that need to be met.
Therefore, the importance of a robust and flexible traffic analysis tool based on the export of IP flows is undeniable. In this sense, Telcomanager has developed TRAFip, a powerful and robust traffic analysis tool that operates in the most diverse categories of different networks and helping thousands of IT managers in the points mentioned in this article and many others.
With this in mind, Telcomanager, Latin America’s leader in the network management software industry, since 2002 in the market with a unique and innovative methodology, provides intelligent solutions for monitoring data in order to provide complete visibility to the customer’s infrastructure, allowing your company to follow the main aspects of its network.