You may be familiar with NetFlow, IPFIX and other similar protocols like J-Flow and sFlow. These protocols provide useful insight into traffic mix and communities of interest. However, these protocols do not contain the application-layer details that some administrators desire. IT administrators need more application-level visibility to be able to perform Application Performance Management (APM) and troubleshoot application-layer issues. Current flow-based protocols lack application-layer details that are needed to perform deeper analysis and troubleshooting.
NetFlow History Lesson:
In the 1990s, NetFlow version 5 started out as a Cisco Systems proprietary protocol for capturing and sending information about network traffic flows to a collection point. NetFlow can be enabled on network devices that are using Cisco Press Forwarding (CEF). The NetFlow-enabled device captures information about IP network streams traversing the interface and sends the data about the flows in UDP packets to a collector system. The NetFlow collector is typically a computer that is running the collection and analysis software. NetFlow has become very popular in the last decade and now there are a multitude of companies that support NetFlow on their devices and many companies that make NetFlow collection and analysis utilities.
Due to the added processing overhead required to support NetFlow, it wasn’t suitable for use on many network devices. Cisco developed Sampled NetFlow, Deterministic Netflow and Random Sampled NetFlow to reduce the overhead of running NetFlow on busy devices but still yield some traffic visibility. Later, Cisco developed Flexible NetFlow which allows for layer 2, IPv6, and other types of data to be sent to a collector.
NetFlow and IPFIX:
As NetFlow started to gain popularity, NetFlow version 9 added flow details for MPLS networks and IPv6 data flows. NetFlow started off as a Cisco proprietary protocol, but was documented in an IETF informational RFC 3954 in 2004. The IETF began working on Internet Protocol Flow Information eXport (IPFIX) in 2004. IPFIX requirements were first documented in RFC 3917. In fact, NetFlow v9 was the basis for the IETF IPFIX standard. The fact is that IPFIX and NetFlow v9 share many field types. NetFlow and IPFIX have come together into NetFlow v10 and standardized with RFC 5101, RFC 5102, RFC 5103 and RFC 5655. IPFIX’s Information Model was updated with RFC 6313. IPFIX has been updated now in the following IETF RFCs 7011, 7012, 7013, 7014, and 7015. Many vendor’s products now support IPFIX.
Other Flow Export Protocols:
Because NetFlow was initially viewed as a Cisco-proprietary flow method, other vendors wanted to develop their own protocols or collaborate on more “open” flow protocols to work on their own hardware. There are many other flow-based network traffic analysis protocols and some are used only by a single vendor.
J-Flow v5/v8/v9 is a flow-based monitoring protocol that was developed by Juniper Networks. It runs on their JUNOS devices and J-Flow is interoperable with NetFlow capable collectors.
sFlow is yet another packet sampling protocol that sends information about flows to a collector. sFlow is supported by an industry organization that helps drive adoption of the protocol. The difference between sFlow and other flow export protocols is that is can perform packet sampling instead of just flow-based export. Packet sampling can improve the performance of the technique by reducing the overhead burden on the network device. sFlow version 5 has broad vendor support.
NetStream is another flow-based export protocol used by 3Com/HP/Huawei.
Ericsson also has their own RFlow protocol.
OpenBSD systems can use pflow (pseudo-device flow) as their method of exporting flow data. pFlow is compatible with NetFlow v5/v9 and v10 (IPFIX).
Limitations of Network Flow Protocols:
The limitation with all flow-based network analysis protocols is that they lack granularity into the traffic. Nothing provides more details into the traffic than actual protocol decode with a protocol analyzer. However, capturing raw packets can be a performance burden on a network device and storing all of that information could be expensive. Packet captures may be a viable option for short-duration troubleshooting and testing, but it is not a sustainable solution for capacity planning, trending, and long-term analysis.
Furthermore, the ability to perform packet captures at many points through the network topology is not usually an option. Setting up a larger number of taps of SPAN/port-mirroring connections could be impossible. You don’t always have a packet monitoring switch at-the-ready or a Cisco eXtensible Network Controller (XNC) running the Monitor Manager application with Nexus 3000 switches already setup.
Today we are also experiencing a changing face of the IT topology. Systems that used to be located within an enterprise’s own facilities now have moved to cloud-based infrastructure. Not every application is nestled safely away in the corporate data center and accessed over the internal corporate WAN. This makes performing protocol analysis of cloud-based applications more difficult to perform. We also lack the ability to perform packet captures on cloud-based services or in virtualization platforms. As a result, many applications lack the visibility they need to be able to perform detailed application analysis or troubleshoot problems.
Summary:
Enterprises need better ways to be able to understand the application traffic traversing their on-premise and cloud-bases systems. NetFlow and IPFIX are useful, but lack the granularity of a full protocol capture. However, capturing raw traffic may not be an option depending on the topology. More and more application-related performance issues required more visibility to be able to troubleshoot. There are other protocols that may be available that give us the visibility that we desire.
In the second part of this article we will cover a new flow analysis protocol that provides this useful information.
Scott