on-demand dialing and VRFs are now mutually exlcusive. As VRF is a new feature of 1.3 this won't break existing 1.2 LTS devices.

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

Moved to vif-c

just that the interface can be added to the VRF

What you mean by "bindable"?

It would appear this commit is the source of the problem - client-config-dir was removed but I don't see anywhere it's re-added.

Thank you @c-po - I can confirm removal of connect-on-demand fixes the problem.
I was under the, obviously mistaken, impression that I needed that command for PPPoE to self-establish on reboot. But I obviously don't as I've just rebooted with the latest 1.3-rolling-202004090909 and it's connected straight away and is working.

Vrfs are for now not supported in dynamic routing protocols, only static routing is for now possible. Se also comment in T2257

For now only static routing supports vrf, bgp, ospf and rip does not support vrf for time beeing. Support for this is being workes on, but its quite a large rewrite required to add support for this in bgp.

Thanks for the responsiveness to this request!
would it be possible to make both vif-s and vif-c interfaces bindable? or should I make a new feature request?

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

It let you know ufo could not be changed, but your interface will work :-)

Yes, it is as you have as file in /tmp/vyos.interface.debug' which turns on this debugging :-)

the Problem comes with the connect-on-demand option. As the default route setup was changed some days ago by me to support PPPoE for VRFs this introduced a regression (T2219).

@c-po Shure, config attached to task https://phabricator.vyos.net/T1315 (left-r1, left-r2, right-r1, right-r2)
Section "Autostart commands"

The time-out issue is resolved in T2252; other issues as summarized above.

Is this normal?

vyos@rt-home# set interfaces ethernet eth4 vif 20
[edit]
vyos@rt-home# commit
[ interfaces ethernet eth4 ]
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gro off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 sg off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 tso off'
DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 ufo off'
DEBUG/ifconfig returned:
Cannot change udp-fragmentation-offload

T2199 for the firewall rewrite - free for the taking. I wouldn't stray much from the old code logic, as some things have hidden meanings. Especially leaving checks out could introduce bugs unless you're absolutely sure they can be bypassed.

There was a new upstream release 1.4.6 7 days ago, but that shouldn't make it to debian stable (buster). Only the patch done by elbandi via PR could get released as 1.4.5-3, but it hasn't been yet. We could make a backport of 1.4.6 into buster-backports and add a custom apt pin for the package. (I'd rather not go the backport route, as that means the backporter needs to always update the upload for security fixes, rather I'd add all patches for bugs into 1.4.5 for buster and ask for a new buster release).

https://github.com/vyos/vyos-build/pull/99