about vyos-1x:
current and sagitta don't use distutils, I found this only for equuleus
https://github.com/vyos/vyos-1x/blob/ae96118ec38c4064552889aea5e50023a66aac1e/src/conf_mode/nat.py#L21
https://github.com/vyos/vyos-1x/blob/ae96118ec38c4064552889aea5e50023a66aac1e/smoketest/scripts/cli/test_system_login.py#L23

We are currently using FRR segment routing set protocols segment-routing srv6
For now, it could be closed

fix for vyos-build: https://github.com/vyos/vyos-build/pull/549

They are signed with minisign now.

This will be handled by the redesigned flavor system soon (T3664).

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

Just wondering - is it possible to add a vti interface to a zone in the firewall?
How would one go about using this with the zone based firewall? 🙂

Does anyone have any thoughts on the best place to start adding this functionality / design ideas for this feature?

PR for Sagitta: https://github.com/vyos/vyos-1x/pull/3239

Try with:

Related to https://vyos.dev/T6080

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

this new command was merge in order to solved this problem :

vyos@vrf-test:~$ show configuration commands | match disable
set protocols bgp parameters disable-ebgp-connected-route-check

Always exclude this address from any defined range. This address will never be assigned by the DHCP server.

Ok, it will exclude in any range.
Forget about it

@ServerForge It is question for hsflowd
You can open the issue on their git repo

Its no longer failing to start, but it seems to be only capturing inbound traffic on the tunnel, no outbound. I'm also observing this behavior on vlan interfaces, IE bond0.10.

Proposed CLI:

set nat cgnat pool external <external> range 192.0.2.0/30 seq 1
set nat cgnat pool external <external> range 192.0.2.128-192.0.2.132 seq 2
set nat cgnat pool external <external> per-user-limit port 1024
set nat cgnat pool external <external> global-port-range 1024-65535
set nat cgnat pool internal <internal> range 100.64.1.0/24

@kevinrausch Thank you for the report, next time it is better to use set of the commands to reproduce

vyos@r4:~$ generate tech-support archive /tmp/foo
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/generate_tech-support_archive.py", line 123, in <module>
    tmp_dir.mkdir()
  File "/usr/lib/python3.11/pathlib.py", line 1117, in mkdir
    os.mkdir(self, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/foo/drops-debug_2024-03-31T12-07-09'
vyos@r4:~$

It seems hardcoded here https://github.com/vyos/vyos-1x/blob/252d03d6e419aae14ae75caed38d1b1001c916a2/src/op_mode/generate_tech-support_archive.py#L96

line 107: available_images: list[str] = annotated_list(grub.version_list())
Should be: available_images: list[str] = grub.version_list()

Not sure if it is meaningful to create a new operational vyos command "initiate" or re-write the reset to be consistent with older VyOS.

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

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

@ServerForge, it seems to be working with the v2.0.55-1 version. Could you build a package and re-check?

git clone -b v2.0.55-1 --single-branch  https://github.com/sflow/host-sflow.git
sudo apt-get install -y libpcap0.8-dev
make deb FEATURES="PCAP DROPMON DBUS"

Only ethernet interfaces or bridges are allowed; from their docs https://sflow.net/host-sflow-linux-config.php

PCAP Packet Sampling

It seems a broken local build; close the task.
Reopen if necessary.

"reset vpn ipsec " command and does not reset SAs that are dow

Updated PR to use multi nodes: https://github.com/vyos/vyos-1x/pull/3202

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

current - https://github.com/vyos/vyos-1x/pull/3195
sagitta - https://github.com/vyos/vyos-1x/pull/3196

Have installed 1.5-rolling-202403200018 in a VM as a clean install (no prior configs) to dig at this but have hit a block.

Sure but if the function "port auto-power-down" is mapped to the ethtool function of disabling EEE then it should be safe?

@jestabro Thanks, a solution definitely seems close.

@L0crian thanks for the details: c-po's PR is part of the solution, but there is more to the story, as you point out.

In T5991#181120, @Viacheslav wrote:

It is not an actual ethernet interface, but you name it as an ethernet interface.
You can check the output sudo ip link show type wireguard or sudo ip link show type tun

It is not an actual ethernet interface, but you name it as an ethernet interface.
You can check the output sudo ip link show type wireguard or sudo ip link show type tun

I tested https://github.com/vyos/vyos-1x/pull/3173 today, and it definitely helps the original use-case of this task. Configuration calling interfaces that come up post-boot, like those installed from a container, persist. The one problem is the interface level config is still deleted on-boot from some check that is performed.