Please retest on 1.2.1

@yun thanks
@dmbaturin Any idea how we can address this?
@hagbard closed request

In T1250#35137, @UnicronNL wrote:

@yun What is the exact frr command you tried?
the command you tried manually.

ok. @UnicronNL please reject my PR then. thx.

@yun What is the exact frr command you tried?
the command you tried manually.

@hagbard This commit adds a route to the kernel routingtable and bypassing FRR, this is no good and this would break. Please make the script add the appropiate commands to frr instead. This way frr will be in charge of populating the kernel table. Also note that this route needs to be removed on dhcp release

@hagbard that commit sets a kernel route. that is not good.

@yun it's only that single line.

Any news about this ?

I would to see this committed. But do we also know what causes the issue? Is it with FRR or was this script just missing the ip command to set the default gw?

With apologies (not having used Phabricator before), I think I may not have filed this bug report correctly. I also did not intend to "triage" it when filing it, as this should be done by a responsible adult! :-)

Assuming this works - please reopen if not

https://github.com/vyos/vyos-replace/pull/1 awaiting review, I have no commit privs.

Not sure if the l2tp/vti modification merits inclusion - that depends on personal configuration of which tunnel is inside the other. I think the original config is correct for the more common use case of having l2tp secured by ipsec.

Could you tell us the exact modifications? Or even better - send a Pull Request via GutHub so we could include it into VyOS.

That worked, thanks. Had to set it to 901, the vpn node was 900. Added a sed to the preconfig script so it survives updates.

@c-po accel-ppp is a server, the pppoe client in vyos is rp-pppoe, which causes the issue.
ppp works and Acks the IPv6 address:

@c-po, Accel-ppp support next option in [pppoe] section

You can try playing around with the priority in the l2tpv3 node.def files. Higher priority means its executer later. DHCP for instance uses 900-something.

I can confirm that as soon as IPv6 is enabled on pppoe0 the interface is no longer renamed from ppp0 to pppoe0.

I switched to a L2TPv3 tunnel for better performance than OpenVPN, still will not come up at boot if it depends on the vti interface.

@tomjepp please test

Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.

Curiously, I can't reproduce it in the latest rolling, even though the code hasn't changed. We need to test in latest crux builds.

The packages were out of sync with reality for some time. Should be fine now.

@tomjepp Could you share the patch or tell us what and where you had to modify?

Code is now merged, please test in the next rolling release tomorrow

i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged

Lets test it first :)

In T1309#34455, @runar wrote:

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

+1 on having this in 1.3 and not 1.2

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

seems so but:

Is this related to T20 ?

Hi runar,

Hi rherold!

Hello, I'm interested in that feature request as well.
And additionally, we want to monitor VRRP status via SNMP, assuming it can be done by pretty much the same way.
Thanks!

From the man page:

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server.

@varesa You are mixing VirtIO which needs offloading, ESXi doesn't need that, nor it's driver. It's related to native KVM mostly.

In T1276#33655, @syncer wrote:

Wondering if we should disable all offload stuff in virtualized environments (which not make sense anyway)

Same goes for DHCPv6 server

In T1276#33738, @ddiguru wrote:

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.

When i launch it as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 192.168.4.40 -i eth0

I no longer get the extra DHCPREQUEST with the local giaddr (which gets DHCPNAKed)

So, it's as if the last -i <interface> is treated as the upstream interface. The man page on dhclient does not detail that!

NOTE: I have not tested adding additional interfaces i.e. /usr/sbin/dhclient -q -4 -a -m discard -i eth1 -i eth2 -i eth3 -i eth4 192.168.4.40 -i eth0 to see if that works as well.

An aside - ISC is actively developing KEA DHCP as the next generation DHCPv4 and DHCPv6 server. Currently, there is no DHCP Relay Agent in the KEA code as of version 1.5.0. The ISC has also stated that ISC dhcpd version 4.4.x is the last code train.

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.

I'd like to weigh in on this, as I have seen a couple of issues. I'm running the following:

Version:          VyOS 1.2.0-rolling+201903072319
Built by:         autobuild@vyos.net
Built on:         Thu 07 Mar 2019 23:19 UTC
Build ID:         4861161f-4f33-4b22-900e-524f241625ca

@syncer you need it on Hypervisor tap level not in the VM itself.

Alpine Linux and OPNsense make it without "cheat mode" (ethtool).
I used the virt-install / bash script above for all.