Yes. Packet drops are classed as "event_samples" internally. Definitions for telemetry counters are here:
https://github.com/sflow/host-sflow/blob/v2.0.50-4/src/Linux/hsflowd.h#L460-L486

@marc_s Will be fixed in the next rolling release, could you check?

Will be available in the next rolling release.

PR https://github.com/vyos/vyos-1x/pull/1934
PR https://github.com/vyos/vyatta-wanloadbalance/pull/16

PR https://github.com/vyos/vyos-1x/pull/1933

set vpn ipsec authentication psk MY-PEER id '192.0.2.1'
set vpn ipsec authentication psk MY-PEER id '192.0.2.10'
set vpn ipsec authentication psk MY-PEER secret 'SeCrEt'
set vpn ipsec esp-group ESP proposal 1
set vpn ipsec ike-group IKE key-exchange 'ikev2'
set vpn ipsec ike-group IKE lifetime '0'
set vpn ipsec ike-group IKE proposal 1 dh-group '14'
set vpn ipsec ike-group IKE proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE proposal 1 hash 'sha256'
set vpn ipsec interface 'eth1'
set vpn ipsec site-to-site peer MY-PEER authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer MY-PEER ike-group 'IKE'
set vpn ipsec site-to-site peer MY-PEER local-address '192.0.2.1'
set vpn ipsec site-to-site peer MY-PEER remote-address '192.0.2.10'
set vpn ipsec site-to-site peer MY-PEER tunnel 1 esp-group 'ESP'
set vpn ipsec site-to-site peer MY-PEER tunnel 1 local prefix '10.0.2.0/25'
set vpn ipsec site-to-site peer MY-PEER tunnel 1 remote prefix '10.5.5.0/25'

Expected `no rekeying

vyos@r14:~$ sudo swanctl -L
MY-PEER: IKEv2, no reauthentication, no rekeying, dpd delay 30s
  local:  192.0.2.1
  remote: 192.0.2.10
  local pre-shared key authentication:
  remote pre-shared key authentication:
    id: %any
  MY-PEER-tunnel-1: TUNNEL, rekeying every 3272s, dpd action is none
    local:  10.0.2.0/25
    remote: 10.5.5.0/25
vyos@r14:~$

The similar task/bug with address-group T3390 T469 and port-group

PR https://github.com/vyos/vyos-1x/pull/1932

vyos@r14:~$ show sflow 
--------------------------  -----------------------------------
Agent address               192.168.122.14
sFlow interfaces            ['eth0', 'eth1']
sFlow servers               ['192.168.122.1', '192.168.122.11']
Counter samples sent        159
Datagrams sent              949
Packet samples sent         124
Packet samples dropped      0
Packet drops sent           815
Packet drops suppressed     0
Flow samples suppressed     0
Counter samples suppressed  0
--------------------------  -----------------------------------
vyos@r14:~$

@lcrockett Add please a new bug report.

It actually already exists: https://vyos.dev/T1981

@PSDev Add please a separate bug report

PR for VyOS 1.3 https://github.com/vyos/vyatta-cfg-system/pull/199

As mentioned on slack, there are quite a few contenders:

I can confirm this bug in rolling 1.3-2023-03-30.

I created a PR based on the changes from the OSPF PR: https://github.com/vyos/vyos-1x/pull/1931

https://vyos.dev/T5085 did the changes for OSPF, but we need this for BGP too

We actually need the same for BGP...

https://github.com/vyos/vyos-1x/pull/1930

The packet-drop events are not really samples in the same way as the packets are random-samples and the counters are time-samples. Even if there is only 1 dropped packet it will be sent. So it might be better to change the wording from “Samples drop events sent” to something like “Packet drop events sent” or just “Packet drops sent”. Make sense?

PR https://github.com/vyos/vyos-1x/pull/1929

Apologies. I believe it is corrected now.

PR for VyOS 1.3 https://github.com/vyos/vyos-1x/pull/1928

https://github.com/TimothyYe/godns

In T5125#146162, @neilmckee wrote:

I think there should be one more metric - the number of packet-drop-events sent. I just checked in a change that adds to the example telemetry.py script:
https://github.com/sflow/host-sflow/commit/5b01779abf21a7553e07188ff2f54850c568f786

But we should also expose the number of drops that were suppressed by the mod_dropmon rate limit. I'll check in 2.0.50-4 later today to add that option too.

when I enter 'show dns dynamic status' it gives me 'no connect' result for the hosts

In T2819#145957, @indrajitr wrote:

Should we revive this consideration again? See https://github.com/ddclient/ddclient/issues/528.

They did have a recent release, but things continue to be unpredictable. So we'll either have to have a different tool (and rewrite the configs) or have to maintain a fork. I see that there used to be a VyOS-maintained fork in the past.

I think there should be one more metric - the number of packet-drop-events sent. I just checked in a change that adds to the example telemetry.py script:
https://github.com/sflow/host-sflow/commit/5b01779abf21a7553e07188ff2f54850c568f786

@fernando Can you see them now? I attached them to the main post.

merge done, it fixed the issues :

Running '1.4-rolling-202303270317' i'm experiencing the opposite behaviour. A VRRP health-check script in a VRRP group that is a member of a VRRP sync group stops working (VRRP group immediately transitions to 'FAULT' state upon start of keepalived). If i take out the 'track_script' block in the produced '/run/keepalived/keepalived.conf' and restart keepalived (sudo systemctl restart keepalived) the health-check script functions as expected again. Any pointers ? Or shall I create a new issue containing the appropriate details ?