It's not a bug, it's simply a weird syntax. That command could never be used without the delete option, so your config example wouldn't work in 1.2 or 1.1.8 either.

You COULD have a peer-group without remote-as, as you could apply that peer group to multiple remotes, and override the remote-as. But that is an edge case. The BETTER way to handle it is to enforce having a remote-as -- especially if you enable route-reflector-client

Thanks! This is definitely a non-issue then, closing.

Since we cannot update the kernel in 1.3 due to the QAT issues, we likely need to backport netmap support. It seems to have been introduced by this commit: https://github.com/torvalds/linux/commit/3ff7ddb1353da

@maznu
Add these lines:

I've tested it on 1.3 with kernel 5.4.138, and for me the persistent option works as expected. I think it's a non-issue for equuleus already and the task can be closed, though I'd like other people to test that first.

Not having much luck with the build environment — and it doesn't seem to be something I've caused, because I get the same error building vyos-1x from mainline:

I think all that is required is in: https://github.com/maznu/vyos-1x/commit/68d7897622ddaa4b2e5a98d79154500b33959567

Hello, @Dmitry, I agree. I'll prepare patches for 1.3 and 1.4.

Hello @maznu , I also prefer the first variant set vpn l2tp remote-access lns host-name example.com I'm sure that we no need to overload l2tp remote-access root noded

Made the change to "do" and I noticed that.....DF is used even if there is no DF bit explicitly set...:

It seems the man page that I looked at I either didn't read carefully enough, or I completely messed it up. You're right @Viacheslav.

Did a quick test...

Already rewritten in 1.4 and 1.3 T3535
https://phabricator.vyos.net/rVYOSONEX21527ef4551613fe9b7eed9e4b2ce33ad46fe540

Hmmmm....it worked last time. I'll give it another run.

Reopen
It doesn't work properly

PR https://github.com/vyos/vyatta-cfg-quagga/pull/87
PR https://github.com/vyos/vyos-1x/pull/954
PR https://github.com/vyos/vyos-1x/pull/955

ipsec start error ..

It is not critical, please test without this package "libstrongswan-standard-plugins"
All necessary data is already installed.

1. Upload package to the router
2. Unarchiv it

sudo tar -xvf strongswan.tar

3. Install packages

sudo dpkg -i *.deb

4. Reboot router or reconfigure IPSec

As I understand there are 2 bugs:

1. It expected --iroute-ipv6, i.e

iroute-ipv6 2001:470:1f14:af1:: ffff:ffff:ffff:ffff::

2. Something wrong with such format (ipv6 address/ ipv4 mask)

ifconfig-push 2001:470:1f14:af1::2 255.255.240.0

@SrividyaA does this configuration work or not?

I don't see this bug in 1.3.0-rc5,

OK , Thank you!

In T2851#99364, @lawrencepan wrote:

As a workaround it can help in such cases:

I get the same issue in 1.2.8.

@xrobau You have to set remote-as for peer-group or for neighbor

[email protected]# set protocols bgp 65001 peer-group FOO 
[edit]
[email protected]# set protocols bgp 65001 neighbor 203.0.113.2 peer-group FOO
[edit]
[email protected]# set protocols bgp 65001 neighbor 203.0.113.2 remote-as 65002
[edit]
[email protected]# commit
[edit]
[email protected]#

@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

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:

[email protected]# commit
[edit]
[email protected]# 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]
[email protected]#

@trae32566 Can you re-check it?

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

By default:

[email protected]:~$ 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          
[email protected]:~$

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 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 already backported it, but forgot to push. Will be part of the next 1.3 ISO/RC

@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: