@jack9603301 I tried building jool into the VyOS image but because their deb packages uses DKMS which is not compatible with VyOS so somebody has to create a VyOS specific deb package.

Also, while setting up test for T2906:

No problem

I can see why the smoketests pass. They only check if the interface has been removed from the config - not the system.

Possible bug with "admin_state"

@tjh can you edit one file?

Did this work earlier in previous releases? is this a regression in 1.2.6-S1 ?

@c-po What do you propose?

It has passed the GNS test, and the test cases are as follows:

@banditos13 can you send a link to the file, which you suggest to fix, or create PR?

Do we need it for "crux"?
This does not affect the work of VPN service.

@Magnum Can you test it?

@Cheeze_It thank you for testing.

Here is the test for the LDP session time change.

Here is the test for Explicit Null.

Everything seems to be good. Closing case.

Simple R1&R2
R2 will have low priority in HA and other ip-adresses in the same subnet

Thanks @Viacheslav; I'm running other tests with vyos-load-config at the moment, and will check and add.

Can you provide a simple config of R1 R3 and R4?
I want to reproduce it in the test lab.

I cannot check rolling release, but on latest 1.2.6 problem is solved.

What content of "conf-path" ?

Which files in /config/tinc0/hosts ?

Hello everyone, I am integrating tinc. At present, I have passed the basic test in a simple virtual machine. The command line is simplified. Examples are as follows:

Thank you.
Reopen the task or create a new one if you find some problems.

I have investigated it now a bit deeper and found out that this router got migrated to VRF automatically (Our deployment stack automatically migrates upgraded/new deployed routers to VRF usage for OOB/VxLAN communication).

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

I think it some code like

Submitted second PR

Many thanks!

I can see a case where people deliberately do NOT want to use ISP provided DNS servers (to avoid DNS NX hijacking) (and/or lock to a major internet DNS server like google 8.8.8.8 or Quad9 9.9.9.9 or Cloudflare 1.1.1.1 for example)

This is an example scenario in which this comes handy:
You have three ethernet interfaces
Two are connected to different LANs
The third is connected to WAN (another router)
All networks offer DHCP and def gw
The LANs offer it for internet access
The WAN offers it for branch access
We want to keep def gw received for WAN and ignore internet access offered by those LANs

@Merijn Can you check the latest rolling?
Or write please which commands do you use?

@lbv2rus Can you try the latest rolling release?

Unfortunately I can not reproduce this issue on my test system and also our smoketests (https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_interfaces_openvpn.py) do not trigger the bug when run locally on the VyOS device by calling:

@Gunni can you check the latest rolling?

@Dmitry

set interfaces ethernet eth1 address 2001:db8::2/64
set interfaces l2tpv3 l2tpeth1010 address '192.168.37.2/27'
set interfaces l2tpv3 l2tpeth1010 encapsulation 'ip'
set interfaces l2tpv3 l2tpeth1010 local-ip '2001:db8::2'
set interfaces l2tpv3 l2tpeth1010 peer-session-id '100'
set interfaces l2tpv3 l2tpeth1010 peer-tunnel-id '200'
set interfaces l2tpv3 l2tpeth1010 remote-ip '2001:db8::1'
set interfaces l2tpv3 l2tpeth1010 session-id '100'
set interfaces l2tpv3 l2tpeth1010 tunnel-id '200'

Do other vendors suppert highjacking/altering of DHCP options? I feel this kills the whole concept of DHCP.

@jjcordon can you test the latest rolling?

Just tested with:
https://github.com/vyos/vyos-1x/commit/85cc735b05be109e6daa5403efa4122b8b6e79d2

It looks like this works, but when we don't have any connected user, it listed the current directory file

vyos@RTR1:~$ touch 1.txt
vyos@RTR1:~$ reset vpn remote-access user <tab>
Possible completions:
  1.txt         Terminate specified user's current remote access VPN session(s)

After a user connected, all works properly

vyos@RTR1:~$ reset vpn remote-access user <tab>
Possible completions:
  test1         Terminate specified user's current remote access VPN session(s)

@D0peX Can you check the latest rolling?

Works as expected.

No, I'm running this commit:
https://github.com/vyos/vyos-1x/commit/029f9839c21317ec5959b331eee25da472d08dc1

There have been some deletion errors yesterday - are you running the latest rolling release? They should have been fixed in there. If noe please provide me some CLI samples to reproduce the issue.

Check out the October versions on both sides.

I spoke to soon.
The interfaces are very persistant now - when you delete the vtun interface it doesn't get taken down!

Tested in my lab and it works both during creation and reboot.

Submitted PR

Works for me!

trae@cr01b-vyos:~$ show protocols bfd peers
Session count: 11
SessionId  LocalAddress                             PeerAddress                             Status         
=========  ============                             ===========                             ======         
3776760774 192.168.253.3                            192.168.253.7                           up             
1851352402 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:6       up             
3344115206 192.168.253.3                            192.168.253.2                           down           
1252680903 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:2       down           
3664188082 192.168.253.3                            192.168.253.6                           up             
2809207409 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:1       up             
2086113021 192.168.253.3                            192.168.253.12                          up             
1362288442 unknown                                  fd52:d62e:8011:fffe:192:168:253:12      down           
3846665654 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:7       up             
276439511  fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:12      down           
1342044518 192.168.253.3                            192.168.253.1                           up

Well spotted - i hadn't seen that option before.
I'll give it a go and see how it runs.