Troubleshooting Netflow

I received an email the other day regarding how to troubleshoot Netflow events with MARS.

How can i tell that my MARS box is actually receiving the Netflow events?

Remember by default Netflow is not stored, so i cannot run a query on the GUI against the MARS database.

First thing i would check is that your Netflow device is actually sending the data out..

RTR1#sh ip flow export
Flow export v5 is enabled for main cache
Export source and destination details :
VRF ID : Default
Source(1) 192.168.7.22 (FastEthernet0)
Destination(1) 192.168.7.250 (2055)
Version 5 flow records
1010 flows exported in 139 udp datagrams

On the MARS box itself, the solution to this is very easy. Remember MARS is built upon a hardened Linux Distribution, so we have access some of the TCP/IP diagonistic tools via the CLI.

On version 4.2.2 of MARS, we can use TCPDUMP...

tcpdump version 3.6
libpcap version 0.6
Usage: tcpdump [-adeflnNOpqRStuvxX] [-c count] [ -F file ]
[ -i interface ] [ -r file ] [ -s snaplen ]
[ -T type ] [ -U user ] [ -w file ] [ expression ]

Tcpdump prints out the headers of packets on a network interface that match the boolean expression

http://www.tcpdump.org/tcpdump_man.html

So if we want to just listen for a certain host device...

[pnadmin]$ tcpdump host 192.168.2.22
tcpdump: listening on eth0
13:27:25.172964 rtr1.52852 > pnmars.2055: udp 264
13:27:45.180450 rtr1.52852 > pnmars.2055: udp 792

or even just a destination port...

[pnadmin]$ tcpdump dst port 2055
tcpdump: listening on eth0
13:32:40.285968 rtr1.52852 > pnmars.2055: udp 168
13:32:56.292348 rtr1.52852 > pnmars.2055: udp 936

or if we have a busy network, we can use logic and put the two together...

[pnadmin]$ tcpdump src host 192.168.2.22 and dst port 2055
tcpdump: listening on eth0
13:34:37.328057 rtr1.52852 > pnmars.2055: udp 264

Hope that helps.