Page MenuHomeVyOS Platform

VRF support for flow-accounting
Closed, ResolvedPublicFEATURE REQUEST

Description

Currently Vyos 1.4 encounters an issue when netflow/sflow are configured to sample VRF interfaces. no data returned if the VRF is a normal internal, and flow-accounting cannot start when the VRF interface is a VIF:

bad scenario config:
admin@vyos# show system flow-accounting
interface eth1.509
sflow {
sampling-rate 1
server 10.49.1.109 {
}
}
admin@vyos# show interface ethernet eth1
hw-id 00:0c:29:97:9e:ba
vif 101 {
}
vif 509 {
address 192.168.59.1/24
vrf ddos-client
}

results in sflow not starting:
admin@vyos# run show flow-accounting
flow-accounting is not active

errors from show log:
Nov 09 18:29:26 commit[4881]: Successful change to active configuration by user admin on /dev/pts/0
Nov 09 18:30:10 sudo[5109]: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/sh -c /usr/sbin/vyshim /usr/libexec/vyos/conf_mode/flow_accounting_conf.py
Nov 09 18:30:10 sudo[5109]: pam_unix(sudo:session): session opened for user root(uid=0) by admin(uid=1003)
Nov 09 18:30:10 vyos-configd[669]: Received message: {“type”: “init”}
Nov 09 18:30:11 vyos-configd[669]: config session pid is 2613
Nov 09 18:30:11 vyos-configd[669]: Received message: {“type”: “node”, “data”: “/usr/libexec/vyos/conf_mode/flow_accounting_conf.py”}
Nov 09 18:30:11 vyos-configd[669]: Sending response 8
Nov 09 18:30:14 systemd[1]: Stopping ulog accounting daemon…
Nov 09 18:31:03 systemd[1]: Starting Cleanup of Temporary Directories…
Nov 09 18:31:03 systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Nov 09 18:31:03 systemd[1]: Finished Cleanup of Temporary Directories.
Nov 09 18:31:44 systemd[1]: uacctd.service: State ‘stop-sigterm’ timed out. Killing.
Nov 09 18:31:44 systemd[1]: uacctd.service: Killing process 4839 (uacctd) with signal SIGKILL.
Nov 09 18:31:44 systemd[1]: uacctd.service: Main process exited, code=killed, status=9/KILL
Nov 09 18:31:44 systemd[1]: uacctd.service: Failed with result ‘timeout’.
Nov 09 18:31:44 systemd[1]: Stopped ulog accounting daemon.
Nov 09 18:31:44 systemd[1]: Starting ulog accounting daemon…
Nov 09 18:31:44 systemd[1]: Started ulog accounting daemon.
Nov 09 18:31:44 sudo[5109]: pam_unix(sudo:session): session closed for user root
Nov 09 18:31:44 systemd[2403]: opt-vyatta-config-tmp-new_config_2613.mount: Succeeded.
Nov 09 18:31:44 systemd[1]: opt-vyatta-config-tmp-new_config_2613.mount: Succeeded.
Nov 09 18:31:45 kernel: uacctd[5132]: segfault at 6 ip 00007ff49e63877e sp 00007ffd4bf33e98 error 4 in libc-2.31.so[7ff49e5b6000+14b000]
Nov 09 18:31:45 kernel: Code: 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1 f3 a4 c3 80 fa 08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6 0e 88 0f c3 <48> 8b 4c 16 f8 48 8b 36 48 89 4c 17 f8 48 89 37 c3 8b 4c 16 fc 8b

restarting but using a subinterface not associated to a VRF:
admin@vyos# del system flow-accounting interface eth1.509
[edit]
admin@vyos# set system flow-accounting interface eth1.101
[edit]
admin@vyos# commit
[edit]
admin@vyos# run show flow-accounting
IN_IFACE SRC_MAC DST_MAC SRC_IP DST_IP SRC_PORT DST_PORT PROTOCOL TOS PACKETS FLOWS BYTES

[edit]

regular ethernet 1:

admin@vyos# del system flow-accounting interface eth1.101
[edit]
admin@vyos# set system flow-accounting interface eth1
[edit]
admin@vyos# commit
[edit]
admin@vyos# run show flow-accounting
IN_IFACE SRC_MAC DST_MAC SRC_IP DST_IP SRC_PORT DST_PORT PROTOCOL TOS PACKETS FLOWS BYTES

[edit]

returning to VRF subinterface:

admin@vyos# del system flow-accounting interface eth1
[edit]
admin@vyos# set system flow-accounting interface eth1.509
[edit]
admin@vyos# commit
[edit]
admin@vyos# run show flow-accounting
flow-accounting is not active

and requires enhancement via https://github.com/pmacct/pmacct/blob/73121100b7970d183a3fbf0b4796542e7042d80a/QUICKSTART#L603-L621

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

I have a related feature request. It is similar enough to this existing request that I don't feel it's worth creating a separate task for it (although, please tell me if that's wrong and I should make a new one!)

I have a management vrf, and my flow collector is reachable over that network. It's currently not possible to send flow data out in a non-default vrf. It would need uacctd.service to start inside that vrf - and then the rest of this task would need to be completed to let it sample from interfaces which are still in the default vrf.

Local flow statistics at least seem to work:

set interfaces ethernet eth1 address '172.16.33.201/24'
set interfaces ethernet eth1 vrf 'MGMT'
set system flow-accounting enable-egress
set system flow-accounting interface 'eth1'
set system flow-accounting netflow server 172.16.33.166
set system flow-accounting netflow version '10'
set vrf name MGMT table '1000'
cpo@LR1.wue3:~$ show flow-accounting
IN_IFACE    SRC_MAC            DST_MAC            SRC_IP         DST_IP           SRC_PORT    DST_PORT  PROTOCOL      TOS    PACKETS    FLOWS       BYTES
----------  -----------------  -----------------  -------------  -------------  ----------  ----------  ----------  -----  ---------  -------  ----------
eth1        xx:xx:xx:51:fc:3c  xx:xx:xx:b3:38:c5  172.16.100.10  172.16.33.201         123         123  udp             0          1        1          76
eth1        xx:xx:xx:bf:ce:05  ff:ff:ff:ff:ff:ff  172.16.33.40   172.16.33.255         138         138  udp             0          1        1         229
eth1        xx:xx:xx:bf:6d:c0  xx:xx:xx:b3:38:c5  172.16.33.30   172.16.33.201       51898        5201  tcp             0      50062        1  2187704536
eth1        xx:xx:xx:51:fc:3c  xx:xx:xx:b3:38:c5  172.16.100.20  172.16.33.201         123         123  udp             0          1        1          76

So does elastiFlow ... can you please retest using the latest 1.4 image?

image.png (1×2 px, 134 KB)

c-po changed the task status from Open to Needs testing.Mar 1 2022, 7:28 PM
c-po claimed this task.
c-po triaged this task as Normal priority.

system seems to be able to process flow data now and im seeing the flow data (netflow and sflow) reach my destination pathed via flow location, appears to work now!

admin@vyos:~$ show version

Version: VyOS 1.4-rolling-202203080319
Release train: sagitta

Built by: autobuild@vyos.net
Built on: Tue 08 Mar 2022 03:19 UTC
Build UUID: 01c39384-2c6e-4e45-9436-33b26290bf68
Build commit ID: b2ca3389494c35

Architecture: x86_64
Boot via: installed image
System type: VMware guest

Hardware vendor: VMware, Inc.
Hardware model: VMware Virtual Platform
Hardware S/N: VMware-56 4d 07 09 f9 6e 66 88-d6 08 f9 d4 32 97 9e b0
Hardware UUID: 564d0709-f96e-6688-d608-f9d432979eb0

Copyright: VyOS maintainers and contributors

admin@vyos# show interface

ethernet eth1 {

hw-id 00:0c:29:97:9e:ba
vif 509 {
    address 192.168.59.1/24
    vrf ddos-client
}

admin@vyos# show system flow-accounting
buffer-size 500
interface eth1.509
netflow {

engine-id 500
max-flows 50
sampling-rate 1
server 192.168.54.3 {
    port 9996
}
source-address 192.168.54.1
timeout {
    icmp 2
    tcp-generic 300
}
version 9

}
sflow {

agent-address 192.168.54.1
sampling-rate 1
server 10.49.1.102 {
}
server 192.168.54.3 {
}

}

vrf ddos-client

admin@vyos# run show flow-accounting
IN_IFACE SRC_MAC DST_MAC SRC_IP DST_IP SRC_PORT DST_PORT PROTOCOL TOS PACKETS FLOWS BYTES


eth1.509 00:0c:29:57:09:25 00:0c:29:97:9e:ba 192.168.59.2 192.168.64.2 48462 80 tcp 0 6 1 396
eth1.509 00:0c:29:57:09:25 00:0c:29:97:9e:ba 192.168.59.2 192.168.64.2 48366 80 tcp 0 6 1 396
eth1.509 00:0c:29:57:09:25 00:0c:29:97:9e:ba 192.168.59.2 192.168.64.2 48634 80 tcp 0 6 1 396