@Viacheslav I believe it is still actual for 1.3 https://github.com/vyos/vyos-1x/blob/equuleus/src/conf_mode/vpn_sstp.py#L60-L78
I saw we changed the PKI model only for 1.4. Implement PKI model for 1.3-epa1 a risky

I figured out the order we need to remove things in:

https://github.com/vyos/vyos-cloud-init/commit/9dd5fa374ccfd74d46551641fb68428e4860b820
https://github.com/vyos/vyos-cloud-init/commit/e979e3d269ce8cbdb3933a141853bb35b9ed7b74

Fixed, tested in 1.3.0-rc5

set firewall ipv6-name WAN6_IN6
set firewall ipv6-name WAN6_LOCAL6
set interfaces ethernet eth1 address '192.0.2.1/24'
set interfaces ethernet eth1 description 'FOO'
set interfaces tunnel tun1 6rd-prefix '2607:FA48:6ED8::/45'
set interfaces tunnel tun1 6rd-relay-prefix '24.225.128.0/17'
set interfaces tunnel tun1 address '2607:FA48:6ED8:8A50::1/60'
set interfaces tunnel tun1 description 'Videotron 6rd Tunnel'
set interfaces tunnel tun1 encapsulation 'sit'
set interfaces tunnel tun1 firewall in ipv6-name 'WAN6_IN6'
set interfaces tunnel tun1 firewall local ipv6-name 'WAN6_LOCAL6'
set interfaces tunnel tun1 mtu '1480'
set interfaces tunnel tun1 multicast 'disable'
set interfaces tunnel tun1 parameters ip ttl '255'
set interfaces tunnel tun1 remote '192.0.2.2'
set interfaces tunnel tun1 source-address '192.0.2.1'

Commit:

vyos@r4-1.3# commit
[edit]
vyos@r4-1.3# sudo ip tunnel show
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
tun1: ipv6/ip remote 192.0.2.2 local 192.0.2.1 ttl 255 tos inherit 6rd-prefix 2002::/16
[edit]
vyos@r4-1.3#

@trae32566 Can you re-check it?

There are different outputs from "iptables" between 1.2 and 1.3:

By default:

vyos@r4-1.3:~$ sudo netstat -tulpn | grep 161
udp        0      0 0.0.0.0:161             0.0.0.0:*                           1405/snmpd          
udp6       0      0 :::161                  :::*                                1405/snmpd          
vyos@r4-1.3:~$

After rebooting router starts with a clean routing configuration.
After that, it loads/commits configuration from /config/config.boot file.
It can be a cause, needs more tests.
It will be must impossible to get another behavior.

PR for current version https://github.com/vyos/vyos-1x/pull/952

I've cleaned the build space and rebuilt the Docker container - no dice locally or in the CI stack, still fails the same way.
It looks like they're using an AWS CA in the cert chain:

Certificate chain
 0 s:CN = repo.saltstack.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

i do recall the starfield certs being a problem back in the day as well, but guessing its quite unlikely for the base build environment to have an AWS root CA in its trusted list.

I agree it would be nice to have the Cisco Auth functionality, however, the original author of opennhrp themselves recommend using FRR nhrpd instead where possible. It appears that most effort going forward will be put into FRR's nhrpd, and not the original opennhrp.

I have added a test which does not let you delete the default BGP instance when VRF bound instances exist.

This is causing a configtest failure on 1.4-rolling-202107301807 stemming from not cleaning up after bgp-evpn-l3vpn-pe-router ("Cannot delete default BGP instance. Dependent VRF instances exist"):

I already backported it, but forgot to push. Will be part of the next 1.3 ISO/RC

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

@Viacheslav Hi, I saw it was fixed in current branch. Is there a plan to backport the fix to 1.3?

@kroy Can you re-check it with your environment? I can't reproduce it in 1.3.0-rc5.

@ciprian.craciun

On VyOS 1.2-rolling-201910180117, setting ip source-validation loose seems to have the same outcome as setting it to disable, i.e. results in rp_filter = 0.

What do you expect to see here?

Fixed in T2745

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

Using timeouts is a pretty bad idea as they vary on the host CPU or utilisation of a hypervisor.

it should be timeout ~1.8 sec between adding ipv6 address and create l2tp interface

Closing as invalid as the error was towards aarch64 which is yet not supported by VyOS.

I think NHRP Cisco Auth is still missing: https://github.com/FRRouting/frr/blob/master/nhrpd/nhrp_peer.c#L1212

@c-po @Viacheslav
Further news on this topic - FRR 8.0 released yesterday (7/29) which includes the aforementioned nhrpd multicast improvements, among a lot of other nice things:

By default, FRR uses all neighbors in afi ipv4.
This behavior can be disabled with:

Drivers for RTL8111 and RTL8168 are build into the kernel.

Large community format:

"1:2:3"
"1:2:3 5:6:7"
"4123456789:4123456780:4123456788"
"^5:.*:7$"

As I see it's already fixed:

vyos@r4-1.3# set protocols bgp 64512 neighbor 192.168.5.5 local-as 64513
[edit]
vyos@r4-1.3# set protocols bgp 64512 neighbor 192.168.5.5 remote-as 64513
[edit]
vyos@r4-1.3# commit
[ protocols bgp 64512 neighbor 192.168.5.5 local-as 64513 ]
local-as: 64513 and remote-as: 64513 can't be the same

The original issue with the name ( type "u32") was solved.
I'll create a separate task for comm-list bug that can't be used without the "delete" option. (T3712)