Using Wireshark to view netflow data

Normally I don't use wireshark unless my only option is a windows machine to view traffic.

TCPdump has done everything I've ever needed until now. TCPdump does not have a built-in netflow decoder. If you turn on all the verbose logging of tcpdump (-vvv) the best you get is:

netflow# tcpdump -n -s 0 -vvv port 2055

12:17:37.254419 IP (tos 0x0, ttl 254, id 25465, offset 0, flags [none], proto UDP (17), length 1060)
    10.202.70.151.56627 > 10.48.2.156.2055: [udp sum ok] UDP, length 1032

Capture this traffic to a file using the -w option and open this using wireshark. When you click on the first flow you will generally see the output below: "no template found".






This means that wireshark has not "seen" a template with which it can decode the netflow packet. Keep clicking through each packet till eventually you trip over a template:




After this, any packet you open (before or after the template) will always be correctly decoded. Here is the wireshark dump of the first packet which had the "no template found" error.




Cisco devices by default send the a template after every 20 netflow packets. You can change this by using the command below. In this case send a template after every 5 packets.

ip flow-export template options refresh-rate 5
ip flow-export template refresh-rate 5

Increasing the frequency of template means that you can find one really close to the packets you are interested in capturing. You could even choose to drop this to 1 which means send a template with every packet.

The Cisco Netflow 7-Tuple

A flow is identified as a unidirectional stream of packets which all have the same combination of seven fields (or 7 tuple)

 

•Source IP address

•Destination IP address

•Source port number

•Destination port number

•Layer 3 protocol type

•ToS byte

•Input logical interface (ifIndex) 

Even if there is only one different field in the tuple then it is considered as a new flow. A flow record can contains other accounting/data fields (such as the AS number). The which that depend on the version record format that you configure for export. 

One easy way to see this in action is to use SSH. SSH sets the type of services bits based on the type of traffic being sent. IE

For the IP Type of Service field [RFC0791], it is recommended that interactive sessions (those having a user terminal or forwarding X11 connections) use the IPTOS_LOWDELAY, and non-interactive connections use IPTOS_THROUGHPUT. [See here]

From ip.h we can see that

IPTOS_LOWDELAY             0x10 is used for interactive sessions
IPTOS_THROUGHPUT        0x08 is used for file transfers

If you do a tcpdump of a ssh interactive session or a file transfer you quickly notice that the SSH sets TOS values as follows:

SSH Authentication / Negotiation packets  = TOS 0x0
SSH Interactive packets = TOS 0x10
SSH File transfer packets = TOS 0x08


Consider the network diagram below where a single router connects two hosts. This network (and the setup details) can be found in my post about understanding netflow and nfsen.



If you start up a SCP session (it file transfer) between ZZZ and ABC you can see that four flows are recorded on the router:

rtr01#show ip cache flow | i 10.48.254.73
Fa0/1         10.48.254.73    Fa0/0         10.48.0.220     06 0016 94FC    19K
Fa0/1         10.48.254.73    Fa0/0         10.48.0.220     06 0016 94FC    17
Fa0/0         10.48.0.220     Fa0/1         10.48.254.73    06 94FC 0016    13K
Fa0/0         10.48.0.220     Fa0/1         10.48.254.73    06 94FC 0016    12

The two flows with low packet counts (17 & 12) are the authentication flows and the other two are data transfer.