Is it possible to implement multiple test targets instead of just one?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Apr 4 2023
Bug: unable to rename a failover route:
@Viacheslav Ok!
@Harliff It is better to write to this task if you find bugs or propose new features.
So anyone could claim/fix it.
Thanks.
@Viacheslav, where is best place to discuss the feature (ask a question or report a bug)?
Nice feature. I'm testing it now.
@neilmckee Thanks.
If output looks good we can close the task
Apr 3 2023
I think one of the problems is that all tables are generated even if there are no rules in it.
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/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:~$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
Apr 2 2023
We actually need the same for BGP...
Apr 1 2023
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?
Apologies. I believe it is corrected now.
PR for VyOS 1.3 https://github.com/vyos/vyos-1x/pull/1928
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/5b01779abf21a7553e07188ff2f54850c568f786But 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.
Mar 31 2023
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.
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:~$10.0.0.0/24 is a connected network.
Mar 30 2023
Yet about the before comment, when I make a flush in the NFT without maintain the empty structure this error occurs:
Bellow, there are some procedures that I used to unload the conntrack module in my environment.