You can’t decide; what is the difference between NetFlow v5 Vs. NetFlow v9? This post explains what you get with NetFlow v5 and the enhancements brought about with NetFlow v9 which is the basis for the proposed standard called IPFIX. For several reasons explained below, NetFlow v9 is the export of choice. The biggest reason is templates and the ability to work with them makes for the best NetFlow solutions.
Experienced users with a history of working with NetFlow and IPFIX sometimes make reference to “traditional NetFlow.” This is essentially NetFlow v5 where the format of what can be exported was hard coded. I say hard coded because definable templates were not introduced to NetFlow until a later version. Definable templates give hardware vendors and sometimes the end users the ability to decide what they want to export. With NetFlow v5, we have no choice. In other words, you get what you get.
Limitations of NetFlow v5
Reporting on NetFlow v5 was limited to the fields supported in the v5 record. In the table below, the 7 element tuple is colored red. The tuple is what the router/switch matches packets on. Packets with the same tuple are part of the same NetFlow Cache entry where the bytes and packets are totaled. The other field values are exported as determined by the router/switch and often end up being decided by the first packet in the flow. Some elements are logically grouped together (E.g. TCP flags).
NetFlow v5 record format
|
Bytes |
Contents |
Description |
| 0-3 | srcaddr | Source IP address |
| 4-7 | dstaddr | Destination IP address |
| 8-11 | nexthop | IP address of next hop router |
| 12-13 | input | SNMP index of input interface |
| 14-15 | output | SNMP index of output interface |
| 16-19 | dPkts | Packets in the flow |
| 20-23 | dOctets | Total number of Layer 3 bytes in the packets of the flow |
| 24-27 | first | SysUptime at start of flow |
| 28-31 | last | SysUptime at the time the last packet of the flow was received |
| 32-33 | srcport | TCP/UDP source port number or equivalent |
| 34-35 | dstport | TCP/UDP destination port number or equivalent |
| 36 | pad1 | Unused (zero) bytes |
| 37 | tcp_flags | Cumulative OR of TCP flags |
| 38 | prot | IP protocol type (for example, TCP = 6; UDP = 17) |
| 39 | tos | IP type of service (ToS) |
| 40-41 | src_as | Autonomous system number of the source, either origin or peer |
| 42-43 | dst_as | Autonomous system number of the destination, either origin or peer |
| 44 | src_mask | Source address prefix mask bits |
| 45 | dst_mask | Destination address prefix mask bits |
| 46-47 | pad2 | Unused (zero) bytes |
Given the table above, flow reporting vendors generate canned reports using combinations of these fields. Typically, traditional NetFlow reports include:
- Top hosts, protocols, autonomous systems (AS), subnets and interfaces
- Top countries and top domains determined by looking at the IP address and DNS records respectively.
- Top applications determined via the common source or destination port
- Top host-to-host connections
- Top host-to-host connections with application
- Top host-to-host connections with protocol
- Top AS to AS
Although the list above has been cut short, it is easy to appreciate that the reporting options are certainly not infinite due to the limited detail exported in NetFlow v5. With today’s network professionals needing deeper forensic details such as mac address, VLAN, etc., it is even easier to understand that the NetFlow protocol needed to evolve.
NetFlow v9 Introduces Templates
As NetFlow matured, the need for a dynamic flow technology capable of exporting anything began to become more evident. The Internet community also realized that in order for the technology to gain wider vendor acceptance a standard needed to surface. Consequently, a near copy of NetFlow v9 called IPFIX is available for all vendors. It is sometimes referenced as NetFlow v10 although; IP Flow Information eXport or IPFIX is the preferred nomenclature.
To broaden the horizons of NetFlow and IPFIX, the standards committee introduced the concept of a template whereby; the router or switch periodically (e.g. every 1-5 minutes) exports a template with details on what is being exported in the flows. The template tells the NetFlow collector how to decode what is being sent.
Because of the additional overhead involved with exporting the new version, the volume of flows exported in a single datagram dropped from 30 in NetFlow v5 to 24 in NetFlow v9. However, since v9 allows us to define what we want to send in a record, it is possible to send less details and ultimately squeeze more flows into a v9 datagram. We’ve seen 31+ records with NetFlow v9 in a single packet.
Never-the-less, this has dramatically opened up the possibilities when leveraging flow technologies. Hundreds of new standard elements have been declared such as MAC address, VLAN, MPLS tags, etc. and where the IANA list falls short for what a vendor would like to export, IPFIX can be utilized to export additional information such as authenticated username.
NetFlow Reporting has made huge strides in the past 2 years and we can expect much more in 2013 and 2014. Keep a close ear for exports which enhance network security and SDN technologies.
The post NetFlow v5 Vs. NetFlow v9 appeared first on Enterasys Networks.
