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 ?

sorry , but it seems files doesn't share .

PR https://github.com/vyos/vyos-1x/pull/1927
Formatted output:

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

Raw output:

vyos@r14:~$ sudo /usr/libexec/vyos/op_mode/sflow.py show --raw
{
    "agent_address": "192.168.122.14",
    "sflow_interfaces": [
        "eth0",
        "eth1"
    ],
    "sflow_servers": [
        "192.168.122.1",
        "192.168.122.11"
    ],
    "counter_samples_sent": 1077,
    "datagrams_sent": 359,
    "packet_samples_dropped": 0,
    "packet_samples_sent": 19,
    "rtmetric_samples": 0,
    "flow_samples_suppressed": 0,
    "counter_samples_suppressed": 0,
    "hsflowd_version": "2.0.50"
}
vyos@r14:~$

PR for VyOS 1.3 https://github.com/vyos/vyos-build/pull/330

https://dev.packages.vyos.net/repositories/current/pool/main/a/amazon-cloudwatch-agent/amazon-cloudwatch-agent_1.247358.0b252413-1_amd64.deb
https://dev.packages.vyos.net/repositories/equuleus/pool/main/a/amazon-cloudwatch-agent/amazon-cloudwatch-agent_1.247358.0b252413-1_amd64.deb

PR https://github.com/vyos/vyos-build/pull/329

Building from source always results in:

10.0.0.0/24 is a connected network.

Yet about the before comment, when I make a flush in the NFT without maintain the empty structure this error occurs:

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

Bellow, there are some procedures that I used to unload the conntrack module in my environment.

PR's:
https://github.com/vyos/vyatta-op/pull/60
https://github.com/vyos/vyos-1x/pull/1923

confirm, it's working :

VyOS 1.4 now runs FRR 8.5 - closing this as fixed upstream

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

I would like to make some question. this prefix 10.0.0.0/24 on PE2 is a connected network or learned from another routing protocol (static or BGP)

We can use patches dir https://github.com/vyos/vyos-build/blob/c3f11ba39c50a3bd1c69e61c38f1c82960a15ee7/packages/frr/build-frr.sh#L18

There also additional bugs relates iptables-nft as chain WANLOADBALANCE_OUT is not exist
https://github.com/vyos/vyatta-wanloadbalance/blob/70ee1319c20e083ab407d8a11faa44c74d05f084/src/lbdecision.cc#L312

vyos@r14# sudo nft list table ip mangle
# Warning: table ip mangle is managed by iptables-nft, do not touch!
table ip mangle {
	chain PREROUTING {
		type filter hook prerouting priority mangle; policy accept;
		counter packets 851 bytes 179376 jump WANLOADBALANCE_PRE
	}

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

In T5123#145898, @fernando wrote:

cool , it could be useful.

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

Starting in hsflowd version 2.0.50-3, the mod_dbus module can be asked for the current sFlow agent-address along with other stats, and the example "telemetry" and "telemetry.py" scripts in the repo under src/Linux/scripts/ have both been updated. So if you wanted to offer a "show sflow" CLI command then you might adapt one or other of those scripts to extract the information from the running hsflowd process. The steps would be:

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

PRl https://github.com/vyos/vyatta-wanloadbalance/pull/15

cool , it could be useful.

In T5123#145870, @fernando wrote:

I don't see it as bug , this information can be obtained from OSPF database using LSA or summary:

vyos@cust-pe2:~$ show ip ospf database

       OSPF Router with ID (1.1.1.1)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
1.1.1.1        1.1.1.1          696 0x80000007 0xd2d4 2
10.255.254.2   10.255.254.2     630 0x80000008 0x682a 3

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
10.180.3.2     10.255.254.2     640 0x80000004 0x6f0a

vyos@cust-pe2:~$
vyos@cust-pe2:~$
vyos@cust-pe2:~$ show ip ospf database router

       OSPF Router with ID (1.1.1.1)

                Router Link States (Area 0.0.0.0)

  LS age: 703
  Options: 0x2  : *|-|-|-|-|-|E|-
  LS Flags: 0x3
  Flags: 0x0
  LS Type: router-LSA
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0xd2d4
  Length: 48

   Number of Links: 2

    Link connected to: Stub Network
     (Link ID) Net: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.180.3.2
     (Link Data) Router Interface address: 10.180.3.3
      Number of TOS metrics: 0
       TOS 0 Metric: 1

  LS age: 637
  Options: 0x2  : *|-|-|-|-|-|E|-
  LS Flags: 0x6
  Flags: 0x0
  LS Type: router-LSA
  Link State ID: 10.255.254.2
  Advertising Router: 10.255.254.2
  LS Seq Number: 80000008
  Checksum: 0x682a
  Length: 60

   Number of Links: 3

    Link connected to: Stub Network
     (Link ID) Net: 10.255.254.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.180.3.2
     (Link Data) Router Interface address: 10.180.3.2
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: Stub Network
     (Link ID) Net: 172.16.50.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metric: 1

also FRR doesn't show the information on that way , so you should use those commands or enable the log .