And remove set protocols static route xxx.xxx.0.0/0 interface pppoe0 unless you use set interfaces pppoe pppoe0 no-default-route.

Note that the subtask T6146 is useful in itself, as a modernization of the legacy tool priority.pl, but manual ordering of config-sync sections to address this issue is fragile, given the subtleties (== design constraints) of the legacy commit algorithm (cf. T5492). It is preferable to hand the full commit proposal of the primary node to the secondary node, and allow the underlying configsession to manage priority ordering --- this may be easy to do with a simple refactor in the post-commit hook and (if needed) adjustment in the http-api request handler.

set interfaces pppoe pppoe0 default-route-distance '255'

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

Wouldnt PPPoE always assign IP dynamically?

In T6140#180604, @Apachez wrote:

Also since dynamic and not static IP is being used it would be handy if the DHCP exchange can be captured using tcpdump and do this both on the 1.3 where this works and on 1.4/1.5 where this doesnt work.

This way we can find out what the difference is in the request flow (from the client) but also in the response flow (from the server) - in case DHCP would be to be blamed on this behaviour.

Comparing to other vendors setting the password either in cleartext or as a salted hash (where when saved in config file its always saved as a salted hash - but it will accept a cleartext edition too if you wish that for whatever reason) through the CLI is the standard in NOS.

Also since dynamic and not static IP is being used it would be handy if the DHCP exchange can be captured using tcpdump and do this both on the 1.3 where this works and on 1.4/1.5 where this doesnt work.

In T6140#180242, @pepe wrote:

Show this commands output if that happens:

show interfaces pppoe pppoe0
show ip route
show log pppoe

Show performance test results from versions 1.3 and 1.4

Comparison with legacy priority.pl can be seen with priority.py --legacy-format, below; note that priority of 0 is default for interface-definitions lacking a priority element, as is assigned in legacy commit algorithm.

I have checked in with @sharpd, he mentioned that it might not be supported to use v4 nexthop for v6 route.
From local testing:

vova | ip r
default via 192.168.0.1 dev wlp4s0 proto dhcp metric 600 
192.168.0.0/24 dev wlp4s0 proto kernel scope link src 192.168.0.102 metric 600

PR for subtask bug merged:
https://github.com/vyos/vyos1x-config/pull/24
PR for this task will follow the update/rebuild of libvyosconfig.

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

In T6140#180451, @dongjunbo wrote:

The Root Cause is this 'Static routes not working with PPPoE and VyOS 1.4'
https://forum.vyos.io/t/static-routes-not-working-with-pppoe-and-vyos-1-4/14102

I

Does the problem only appear after your 5am reboot every day?

The Root Cause is this 'Static routes not working with PPPoE and VyOS 1.4'
https://forum.vyos.io/t/static-routes-not-working-with-pppoe-and-vyos-1-4/14102

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

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

This likely because the global state policy being reintroduced was not accounted for in the firewall check in conf script. I'll check this week.

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

We have something like this already for !in! interfaces: