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

In T6162#180826, @Apachez wrote:

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

That is that this commit goes into upstream to both Linux kernel and Intel out-of-tree driver (in case the later is missing this support)?

Wouldnt it be better if the same commit goes to Intel to be included with the out-of-tree driver which generally have better featuresupport than the in-tree driver which seems to be somewhat crippled?

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

Thanks for your reply.
But I have some questions about this situation.
Because it is something different with I knew "version meaning".

Output for a standard check with section ['nat'] and for the test case above, with debug logging on; changes are correctly mirrored on secondary node:

Tags show the code base at the step where the tag was added.
But binary can be changed since this time. For the same reason, you will not be able to build 1.1.8 or 1.2.1, etc. exactly with those binary that were on the step of tagging.
Close it as wonfix.

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

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.