vergoh / vnstat

vnStat - a network traffic monitor for Linux and BSD
GNU General Public License v2.0
1.45k stars 123 forks source link

Vnstat virtual interface not appearing #245

Closed meetme2meat closed 1 year ago

meetme2meat commented 1 year ago

On our premises, we are using the wg0 interface. to route our traffic. but as per what I have observed. Vnstat does not display wg0 interface I have seen this happening myself on our edges.

I was of the opinion that this only work for virtual interface but my colleague just brought it to my notice at the time even for the physical interface vnstat does not show interfaces.

The issue is not consistent and has seen it happening randomly on a different server for 1.18 version but the issue is consistent for 2.x version at least for the virtual interface.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 18:31:bf:b1:cf:e4 brd ff:ff:ff:ff:ff:ff
    inet 10.26.0.1/24 brd 10.26.0.255 scope global enp3s0
       valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 18:31:bf:b1:cf:e3 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 172.28.252.58/24 brd 172.28.252.255 scope global dynamic enp2s0
       valid_lft 3102sec preferred_lft 3102sec
4: enp3s0.700@enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 18:31:bf:b1:cf:e4 brd ff:ff:ff:ff:ff:ff
    inet 100.64.0.1/21 brd 100.64.7.255 scope global enp3s0.700
       valid_lft forever preferred_lft forever
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.29.4.10/32 scope global wg0
       valid_lft forever preferred_lft forever
vnstat

                      rx      /      tx      /     total    /   estimated
 enp2s0:
       2023-04      1.66 GiB  /   59.93 MiB  /    1.71 GiB  /    9.42 GiB
         today      1.66 GiB  /   59.93 MiB  /    1.71 GiB  /    3.74 GiB

 enp3s0:
       2023-04      9.73 MiB  /  102.22 MiB  /  111.95 MiB  /  613.04 MiB
         today      9.73 MiB  /  102.22 MiB  /  111.95 MiB  /  244.24 MiB

FYI:

sudo vnstat --iflist
Available interfaces: enp3s0 (100 Mbit) enp2s0 (1000 Mbit) enp3s0.700 (100 Mbit) wg0

FYI I have added it manually but we were expecting on vnstat to take this up during its bootup

vnstat --debug --add -i wg0
vnStat 2.6 by Teemu Toivola <tst at iki dot fi>
vergoh commented 1 year ago

Once you add wg0 manually, is vnStat able to monitor it in the same way as other interfaces in the system or does the traffic stay at zero?

With the default configuration, vnStat should automatically include all available interfaces when the daemon is started for the first time. If wg0 is available at that point then it should get included too. However, any interfaces that get created later don't get automatically added unless you are starting vnstatd with the --alwaysadd parameter or have the feature enabled using the AlwaysAddNewInterfaces configuration option.

For example, if your setup is such that vnstatd gets started the first time during the system boot (say you are deploying from some pre-built image) then that randomness could be explained by the startup order. That virtual interface may take some time to setup and vnstatd may get started around the same time. If vnstatd is faster then wg0 isn't visible yet and therefore doesn't automatically get added while sometimes the order may be different. Depending on your operating system, adjusting the dependencies of services may also help to solve this.

meetme2meat commented 1 year ago

I added wg0 on one of our server yesterday and till today it shows this

                      rx      /      tx      /     total    /   estimated
 enp2s0:
       2023-04      1.71 GiB  /   93.83 MiB  /    1.81 GiB  /    8.24 GiB
     yesterday      1.69 GiB  /   77.79 MiB  /    1.76 GiB
         today     27.59 MiB  /   16.04 MiB  /   43.63 MiB  /   76.63 MiB

 enp3s0:
       2023-04     31.64 MiB  /  122.29 MiB  /  153.93 MiB  /  699.55 MiB
     yesterday     23.67 MiB  /  121.31 MiB  /  144.98 MiB
         today      7.97 MiB  /    0.98 MiB  /    8.96 MiB  /   15.73 MiB

 wg0: Not enough data available yet.

One other server displays the wg0 interface correctly (I don't remember adding it myself there)

FYI just move the database that was originally created by vnstat and restart vnstat this time around it picked up the virtual interface enp3s0.700 which was missing from the earlier entry

Also, I don't see the --alwaysadd option in the --longhelp, neither I see any comment config reflecting the AlwaysAddNewInterfaces flag in the config.

vergoh commented 1 year ago

AlwaysAddNewInterfaces configuration option was introduced in version 2.8 so if you are using 2.6 then that would explain why it's not there. --alwaysadd is included starting from version 1.15 but the catch is that it's a parameter for the daemon, vnstatd, so it's not going to be visible in the vnstat --longhelp output.

You'll most likely want to try the live monitoring mode for that virtual interface: vnstat -l -i wg0 If that doesn't show any traffic (= the values stay zero) even when you are expecting the interface to have at least some traffic then that interface can't be monitored by vnStat since the kernel driver / module responsible for the implementation doesn't expose traffic data.

meetme2meat commented 1 year ago

@vergoh I'm certain that wg0 does transmit data and for that matter to make it clear I just ran vnstat in monitoring mode and it does not

vnstat -l -i wg0
Monitoring wg0...    (press CTRL-C to stop)

   rx:     3.46 kbit/s     3 p/s          tx:    16.62 kbit/s     5 p/s
   rx:     2.43 kbit/s     2 p/s          tx:    11.50 kbit/s     3 p/s
meetme2meat commented 1 year ago

I found that vnstat was started before the wg0 interface was started is there a way to ensure that vnstat obey networking order and starts only when vnstat is after the full networks have been started.

Apr 11 12:00:10 edge systemd[1]: Started vnStat network traffic monitor.
Apr 11 12:00:22 edge systemd[1]: Starting WireGuard via wg-quick(8) for wg0...

I guess this more of a problem with how the wg0 is started let me see what can be done here.

@vergoh, Help me understand if I add the interface manually and restart would that work as a viabale solution.

vergoh commented 1 year ago

You are using systemd and the default configuration in vnstat.service is that vnStat is started after network setup is complete:

After=network.target

If you'd want systemd to ensure that WireGuard is started before vnStat then you'd need to define that in vnstat.service, but don't ask me how exactly as that will likely depend on the systemd version you have and if WireGuard defines any targets etc.

Obviously you could just also write a simple script which checks if wg0 is already being monitored and if not then add it. There's no need to restart since the daemon will automatically detect possible new interfaces from the database on every SaveInterval.

meetme2meat commented 1 year ago

@vergoh Understood and yes the sample script is what we are working with for now. Thanks a lot for help.