Using NetFlow on VyOS


I’m trying to use NetFlow with a VyOS router, but I encountered a few problems when setting up the tool.

I’m using an Ubuntu VM which allows me to replay a pcap using the tcpreplay tool, replaying this on an interface communicating with the router. The command is as follows:

sudo tcpreplay -i ens3 my_pcap.pcap

ens3 is an interface on my virtual machine that communicates with the VyOS router.

However, once my pcap has been fully replayed, it doesn’t seem to be processed by NetFlow. The show flow-accounting command returns nothing. This is strange, since a tcpdump on the VyOS router when replaying the packet shows me that packets are indeed being received at the router.

What’s more, when I send a ping from the virtual machine to the VyOS router, the packets are received and the flow-accounting command shows me that NetFlow has analyzed the ICMP packets. It returns :

Src Addr        Dst Addr          Sport     Dport   Proto       Packets  Bytes   Flows   68        67      udp         13       4212    12     0         0       icmp        13       1092    1
                                  0         0       ipv6-icmp   5        280     4

PS : is my Ubuntu VM ip address and is my VyOS ip address

For more information, the NetFlow configuration I use is as follows:

flow-accounting {
        interface eth2
        netflow {
            engine-id 1
            sampling-rate 1
            server *my_ip_addr* {
                port 2055
            timeout {
                expiry-interval 1
                flow-generic 3600
                icmp 300
                max-active-life 604800
                tcp-fin 300
                tcp-generic 3600
                tcp-rst 120
                udp 300
            version 9
        syslog-facility daemon

Do you have any idea what the problem is?


Are you sure the router isn’t dropping the packets because of connection tracking? i.e. you’re replaying packets for which it has no state for, so they’re dropped?

Im also not that sure that using “sampling-rate 1” is a healthy thing to do in long term.


First of all, thank you for your two replies and I’m sorry to be so late in getting back to you.

Following your recommendations, I tested the following command: show system conntrack which returns: Configuration under specified path is empty. At first sight, conntrack doesn’t seem to be activated on the router, so I guess that’s not the source of the problem. To make sure that conntrack is deactivated, even though it seems to be the case already, I used:

set system sysctl custom conntrack.disable=1

I also thought it might be related to the router’s firewall, so I tested the following commands:

set firewall name MYFIREWALL rule 10 action 'accept'
set interfaces ethernet eth2 firewall local name MYFIREWALL

This doesn’t change the fact that NetFlow still doesn’t seem to be receiving packets.

Finally, the sampling rate of 1 is not desirable, and is even counter-productive since it goes back to do packet-by-packet analysis, as I understand it.