What is a Flexible NetFlow Key Field Vs. non-key field and how do they relate to collect and match?  To understand these terms, you first need to understand that traditionally, an IP flow is based on a set of seven IP packet attributes. This set of key fields is tracked and if any one of the packet values for these fields are unique, a new Flow Record is created in the NetFlow cache. This methodology of flow characterization or determining a flow is scalable because a large amount of network information is condensed into a database (i.e. cache) on the router or switch.

Match and Collect
All packets with the same ‘matching’ attributes (i.e. the same source/destination IP address, source/destination ports, protocol, interface and class of service) are grouped into a flow and then packets and bytes are tallied.  The default 7 attributes are the IP packet identity or “key fields” for the flow and determine if the packet information is unique or similar to other packets. Items such as TCP flags, subnet masks, packets, bytes, etc. are “non key fields”, but are often still ‘collected’ and exported in NetFlow or IPFIX.  In short, Match = Key and Collect = non-key.

Below shows the basic components of NetFlow including the flow key fields, NetFlow cache and reporting server.

Flexible NetFlow diagram

What is a Flexible NetFlow Key Field?
A Flexible NetFlow (FnF) key field is a field that you want to match on.  If one of the incoming packets doesn’t match a key field in the flow cache, a new entry is made.  Here is how we match on the 7 key fields mentioned above when setting up a Flexible Netflow record:

  • match transport tcp destination-port
  • match transport tcp source-port
  • match ipv4 destination address
  • match ipv4 source address
  • match ipv4 protocol
  • match ipv4 tos
  • match interface input

Lets consider a large service provider that wants to setup billing based on source IP address. If we use the flow record above, the match statements may end up causing an enormous amount of flows to be exported, possibly even more than the high volume NetFlow collector can handle.  Since where the traffic is going isn’t a concern, the service provider may only want to match the source IP address and collect the bytes.  We can dramatically simplify the configuration by using only one match statement:

  • match ipv4 source address

If the service provider wants to bill individuals differently based on the priority marked in the datagrams, we can add a second field:

  • match ipv4 source address
  • match ipv4 tos

The volume of flow cache entries on the router is now dramatically less which means less overhead on the router and less exports to the FnF collector. You might be asking “What about the bytes?” Now we have to discuss the Collect statements.

What is a Flexible NetFlow Non-Key Field?
Additional information can be added to the Flow Record and this information is named non-key fields. Non-key fields are added to the flow entry in the NetFlow cache and exported. The non-key fields are not used to create or characterize the flows but are exported and just added to the flow. In FnF, non-key fields are also configurable by the user. If a field is non-key, normally only the first packet of the flow is used for the value in this field. Non-key fields” are introduced in the CLI via the “collect” keyword.

  • match transport tcp destination-port
  • match transport tcp source-port
  • match ipv4 destination address
  • match ipv4 source address
  • match ipv4 protocol
  • match ipv4 tos
  • match interface input
  • collect counter bytes
  • collect counter packets

Tip: Match statements are inherently collect statements.  In other words, everything matched is also collected.

Typical non-key NetFlow fields that are often added to the above include:

  • collect routing source as
  • collect routing destination as
  • collect routing next-hop address ipv4
  • collect ipv4 dscp
  • collect transport tcp flags
  • collect interface output ;notice that the input interface was a match statement!!!
  • collect counter bytes
  • collect counter packets
  • collect timestamp sys-uptime first
  • collect timestamp sys-uptime last

I’m sure you are as impressed as I am with how Flexible FnF truly is.  You have a great deal more control over what can be exported.  J-Flow and NetStream support are missing this Flexibility that is inherent in NetFlow v9. IPFIX on the other hand can support this however, it is up to the vendor to decide how flexible they want to make the metering process. Few vendors other than SonicWALL have made it this flexible.

Answers: Flexible NetFlow involves 4 steps and creating the flow record with the above match and collect statements is only step 1.  When finished setting up FnF, consider step 5 as pointed out by NetFlow Ninja Adam Powers at Lancope (now he works at Plixer) and verify that steps 1-4 are complete:
rtr1#sh flow monitor

There is a great video on youtube on how to configure flexible netflow.  FnF works on many of the older Cisco routers as long as they have enough memory.  We have set it up on a lot of refurbished Cisco hardware that we have purchased.  Give us a call if you need any help.

 

 

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related

Leave a Reply