Skip to content
May 7 / Greg

Cacti Video Tutorial Netflow / Flowviewer

I wasn’t initially clear enough, so here is meat and potatoes explanation of netflow, then it will get into the history:

Imagine a user in your network is downloading a huge file from somewhere on the internet. Now imagine you are exporting netflow information from your internet router and collecting it on your cacti box. You will be able to run a query and see that Bob is using a lot of bandwidth. You then run a query looking for just Bob’s traffic. You will see that Bob was pulling X amount of data from a specific server whose IP address is X.X.X.X. You will be able to tell that Bob was using FTP to pull the files because the source port from X.X.X.X was port 20.

Where did netflow come from? Back in the long long ago, in the before time, Cisco used fast switching. As traffic would enter a router, it would do a lookup in the processor to see which direction to send the traffic. This would create a “flow”. All subsequent traffic associated with this flow would simply be switched through at high speed. “Route once, switch many.” This was eventually depreciated for more efficient techniques, namely CEF.

Cisco Express Forwarding takes the route table and compiles it into a special set of tables, the adjacency and FIB (forward information base). These tables sit in ASICs (application specific integrated circuits). Since these guys sit in hardware and don’t require the processor to get involved, everything moves faster. Sooooo, getting back to the point of this article 😉

Netflow is now used to monitor traffic moving through a network. When netflow is enabled on a router, it will export the following information per flow:

  • Source IP
  • Destination IP
  • Source Port
  • Destination Port
  • Amount of Information Sent

On our Cisco routers, when you enable netflow on an interface, it only takes effect in an incoming direction. What this means is that you really need to enable it on any interface that passes traffic. You then configure the router to export this information to your collector; in this case, our cacti box.

To see configurations click the link below for full article!!!

Configuring your router to export neflow:
You need to enter the following commands per interface that passes traffic:

1
2
3
4
5
6
7
8
!this takes you into interface configuration mode
router(config)#interface FastEthernet 0/1
!this is what actually starts the collection of information
router(config-if)#ip route-cache flow
!Newer versions of IOS may require the following instead
!You can now choose which direction per interface you want to
!collect.
router(config-if)#ip flow {ingress | egress}

Then, you need to tell your router to export the information:

1
2
3
4
5
6
7
8
9
10
11
12
13
!this is the IP address of our cacti server & port number to dump to
!the port number should be different for every router you are dumping from
router(config)#ip flow-export destination 192.168.9.101 2055
!this is not necessary, but suggested.
!it sets the source IP address that the netflow info will come from
router(config)#ip flow-export source Loopback 0
router(config)#ip flow-export version 5
!This will timeout active flows every 5 mins.  This makes sure
!you are exporting at a regular rate
router(config)#ip flow-cache timeout active 5
!This is the timeout in seconds that it takes a flow to be 
!considered inactive
router(config)#ip flow-cache timeout inactive 15

Cisco’s documentation on Netflow.

Configure your cacti box to collect:

*****You need to make sure you have a firewall allowance for the UDP port that your routers will be dumping netflow from.*****

You then need to configure your export host in cacti. If you are only dumping from a single router, and you are dumping to port 2055, then you are golden. The default host is already configured for it. All you have to do is start the netflow service.

Starting the netflow service.
All you have to do, if you are using cactiEZ is to issue the service start command.

1
service flow-capture start

You will also want the service to start when the machine reboots:

1
chkconfig --level 3 flow-capture on

You should now be able to start running queries on your netflow info. If you don’t seem to be getting any info, check first to see if you are receiving netflow. Lets use tcpdump:

1
tcpdump udp port 2055

You should see a large amount of packets hitting your server. If you don’t check your iptables firewall and make sure you have an allowance. If you have the allowance there, then check your router by issuing the following:

1
2
show ip flow export
show ip cache flow

You can always just watch the video, though hehe :








31 Comments

leave a comment
  1. anu / May 7 2009

    This is a new method i had seen. Normally i just visit a site that gives the Source IP,Destination IP, Source Port, lattitude & longitude but this is the new way iam seeing thanks for your information

  2. Greg / May 7 2009

    Anu,

    I must not have been clear enough. Imagine a user in your network is downloading a huge file from somewhere on the internet. Now imagine you are exporting netflow information from your internet router and collecting it on your cacti box. You will be able to run a query and see that Bob is using a lot of bandwidth. You then run a query looking for just Bob’s traffic. You will see that Bob was pulling X amount of data from a specific server whose IP address is X.X.X.X. You will be able to tell that Bob was using FTP to pull the files because the source port from X.X.X.X was port 20.

    Thanks for the comment Anu,
    Greg

  3. Paulo ROque / May 9 2009

    Congratulations for your job.

    I have a problem here.

    I configure both router and catci. I can see data in the /var/netflow/flows. The time between both box are synchonized. Everything else seems right, but the “viewer” does not provide any data. Am I missing anything here?

    Paulo Roque

  4. Paulo ROque / May 9 2009

    Thank you Greg for your attention.
    I finally found out what was going on.

    So I will post my 2 cents …

    To see if I was receiving data I used tcpdump as you suggested. Everything was ok. I also check the dir /var/netflow/flows and a new files were created every 2 or 3 minutes. But I didn’t figure out quickly was that all files were empty. Here, I understood that ‘flow-capture’ was rotating the files, although they were empty.

    But, silly of me, there was a iptables configured on the machine.

    In conclusion…
    Although the tcpdump was indicating the reception of packets, they were being dropped by iptables and empty files were being rotated.
    My suggestion is also to use the flow-receive tool to further verify the reception.

    ‘flow-receive 0/0/2055 | flow-print’

    And also indicate the use of “devices” tab to create new routers.

    Thx
    Paulo Roque

  5. Greg / May 9 2009

    Paulo,

    I’m glad you got it worked out!

    Thanks for the additional tip Paulo, I’m sure it’s going to help someone else out too.

    Greg

  6. Xin CHEN / May 10 2009

    Thans Greg – great tutorial!

    I am not sure it is because my router IOS version 12.4, the following command doesn’t work for me:
    ip flow-export source Loopback 0
    flow-cache timeout inactive 5
    I think these don’t matter, the router should have default value.
    flow-cache timeout inactive default value is 15 seconds.

    One question: I can see a lot of files have been created in /var/netflow/flows/ , however, I still see nothing in flowviewer (click view button and no information displayed). any clue?

    Thanks

  7. Xin CHEN / May 10 2009

    Forget to mention that: I am using 2055 port and version 5. The default router has been config in Device tab. I didn’t change that. Not sure why Cacti doesn’t pick the data…

  8. Xin CHEN / May 10 2009

    OK, Please ignore above posts. It is coming now. Apparently I have to wait around 15 mins to see the reports. Thanks.

  9. Greg / May 10 2009

    Xin,

    You are ok without the
    flow-cache timeout inactive 5
    command. I would be more concerned with the active command failing. The active is what specifies how often to timeout active flows and ensures timely delivery.

    Greg

  10. Rob / May 11 2009

    Thought about trying this with MikroTik’s traffic-flow? It’s supposed to be compatible with Cisco’s netflow.

    http://www.mikrotik.com/testdocs/ros/2.9/ip/traffic-flow_content.php

  11. Greg / May 11 2009

    Rob,

    I’ve yet to try it with MTK, but I believe it should work…I’m trying to remember if Jimmy has tried it, yet. I’ll test and get back to you. Thanks dude!

    Greg

  12. Irek / May 14 2010

    Great explain, but I want to do few routers in cacti by Add Device and monitor them. Default works ok – all routers configured sends packet to one directory – /var/netflow/flows/Router and I see report. But if I create new device, type directory to log packet to (example 331000), create the directory in system files (/var/netflow/flows/331010) and new packets don’t put in. This directory is still empty but net-flow packets are incoming. Tcpdump shows them. What do i do to make solution ? I tried to use another port like 2056 to next device but nothing happends.

  13. Greg / May 19 2010

    Do a “service flow-capture stop” and then “service flow-capture start”. service flow-capture restart doesn’t work.

  14. Robert / Oct 2 2010

    For those googling for mikrotik, yes – it does work.

    Tested with RouterOS v4.5 – flow version 5.

    The flow viewer data seems somewhat terse, though I’m comparing it to my memory of other flow viewers used and discarded some time ago.

  15. aergios / Oct 10 2010

    Hi, Thank for the guide.
    However, I’m facing same issue the “viewer” does not provide any data.
    I can see files have been created in /var/netflow/flows/, but there is still nothing in flowviewer (click view button and no information displayed).
    ————————————————————————————-
    /var/netflow/flows/Router/2010-10-11
    -rw-r–r– 1 root root 96 Oct 11 09:53 ft-v05.2010-10-11.095201-0500
    -rw-r–r– 1 root root 105888 Oct 11 09:54 ft-v05.2010-10-11.095301-0500
    -rw-r–r– 1 root root 140640 Oct 11 09:55 ft-v05.2010-10-11.095400-0500
    ……
    ————————————————————————————-
    Here’s the output from ‘flow-receive 0/0/2055 | flow-print’
    flow-receive: setsockopt(size=4194304)
    flow-receive: bind(): Address already in use
    flow-print: ftiheader_read(): Warning, short read while loading header top.
    flow-print: ftiheader_read(): failed
    flow-print: ftio_init(): failed

    ————————————————————————————–
    Sorry I’m dummies on this, any clue?

  16. Greg / Oct 11 2010

    @aergios

    Make sure you have the
    time

    on your server AND on your router synchronized. If these aren’t the same your queries won’t return results properly.

  17. aergios / Oct 12 2010

    Thank Greg… the time settings solved the problem..
    arigato… =)

  18. Greg / Oct 13 2010

    NP 🙂

  19. Maltyx / Nov 3 2010

    Well, it seems to me I have a similar issue the “viewer” does not provide any data for second Router I have added (first Router – works fine).
    I can see files have been created in /var/netflow/flows/Router2 folder
    —————————-
    -rw-r–r– 1 root root 96 Nov 3 17:11 ft-v05.2010-11-03.171001+0200
    -rw-r–r– 1 root root 96 Nov 3 17:12 ft-v05.2010-11-03.171101+0200
    -rw-r–r– 1 root root 96 Nov 3 17:13 ft-v05.2010-11-03.171201+0200
    -rw-r–r– 1 root root 96 Nov 3 17:14 ft-v05.2010-11-03.171301+0200
    -rw-r–r– 1 root root 96 Nov 3 17:15 ft-v05.2010-11-03.171401+0200
    -rw-r–r– 1 root root 96 Nov 3 17:16 ft-v05.2010-11-03.171501+0200
    -rw-r–r– 1 root root 96 Nov 3 17:17 ft-v05.2010-11-03.171601+0200
    -rw-r–r– 1 root root 96 Nov 3 17:18 ft-v05.2010-11-03.171701+0200
    -rw-r–r– 1 root root 96 Nov 3 17:19 ft-v05.2010-11-03.171801+0200
    -rw-r–r– 1 root root 96 Nov 3 17:20 ft-v05.2010-11-03.171901+0200
    -rw-r–r– 1 root root 96 Nov 3 17:21 ft-v05.2010-11-03.172001+0200
    -rw-r–r– 1 root root 96 Nov 3 17:22 ft-v05.2010-11-03.172101+0200
    -rw-r–r– 1 root root 96 Nov 3 17:23 ft-v05.2010-11-03.172201+0200
    -rwxrwxrwx 1 root root 96 Nov 3 15:52 tmp-v05.2010-11-03.155201+0200
    -rw-r–r– 1 root root 96 Nov 3 17:23 tmp-v05.2010-11-03.172301+0200
    [root@localhost 2010-11-03]#
    ———————————————–

    but there is still nothing in flowviewer (click view button and no information displayed). The time is synched … so waht should I check? Please advise!
    Thanx.

  20. Greg / Nov 3 2010

    If I recall correctly, the service X restart doesn’t work on the flow collector. You have to do service X stop, then service X start. Try that.

  21. Maltyx / Nov 3 2010

    Well I restarted the whole box .. but no success .. the flow file seems to be too small – 96 bytes – may be they are empty?

  22. Maltyx / Nov 3 2010

    I figured the problem – after disabling IPTABLES on CactiEZ box it started to write flow files with data .. now I just need to find out how to enable IPtables to accept UDP traffic of the custom UDP port ..
    Thanx!

  23. Greg / Nov 3 2010

    @maltyx

    use webmin:
    http://cactiBoxIP:10000
    Go to networking => linux firewall

  24. ciphercore / Mar 30 2011

    Great tutorial. I was having trouble until I read this. Some of the comments were also very helpful.

  25. Greg / Mar 30 2011

    Great!

  26. Jakub / Aug 16 2011

    Hello, does it support netflow v9? I need to run it on network supporting IPv6. Thank you

  27. Greg / Aug 16 2011

    V5 only, sorry.

  28. Fabian / Nov 2 2012

    Thanks for the tutorial is very well explained!!
    I have a problem, the colector creates files empty. The packets arrive to the colector, I checked with TCPDump.
    As I can synchronize the time of the router and the collector? NTP server is required?
    Thank you.

  29. Fabian / Nov 2 2012

    “Tcpdump” information and “flow-receive” error:

    [root@localhost ~]# tcpdump port 2055
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    11:01:43.305158 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1452
    11:01:43.494836 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1448
    11:01:43.594822 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1448
    11:01:43.692725 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1468
    11:01:43.876450 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1444
    11:01:43.949071 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1420
    11:01:44.095139 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1456
    11:01:44.319846 IP 10.77.145.1.14215 > 10.77.145.200.iop: UDP, length 1460
    ^C
    8 packets captured
    8 packets received by filter
    0 packets dropped by kernel

    [root@localhost ~]# flow-receive 0/0/2055 | flow-print
    flow-receive: setsockopt(size=4194304)
    flow-receive: bind(): Address already in use
    flow-print: ftiheader_read(): Warning, short read while loading header top.
    flow-print: ftiheader_read(): failed
    flow-print: ftio_init(): failed
    [root@localhost ~]#

  30. Greg / Nov 2 2012

    @Fabian
    If the time on the router and the collector are different, then you will have issues.
    NTP really is the best solution.

  31. Fabian / Nov 5 2012

    Thank Greg!!
    I hope have lucky.

Leave a Comment

 

*