Can highly recommend: http://repo.saltstack.com/2019.2.html#debian (includes Jessie)

@jjakob thank you for the detail. I will work on it.

Currently none of the offloading (gro, gso, sg, tso, ufo) settings are checked either at src/conf_mode/interfaces-ethernet.py verify() or in the module python/vyos/ifconfig/ethernet.py. Setting one of these when the driver doesn't support it will result in an unhandled exception. This may not be so disastrous when setting the options in config mode, as the commit will fail due to the exception, but will have more disastrous results when a config which has these options set is loaded into a system with NICs that don't support it - this will cause boot time commit to fail. As per T2158 and PR#272 none of these calls should result in an exception, but rather just print a warning and continue.

To track similar https://github.com/FRRouting/frr/issues/4471

My main question is why is this message displayed and do we need to worry.

I have had the maximum-paths setting for years since Vyos 1.1.x and I have a lot of routes ipv4 and ipv6 installed in the routing table with 2 or 3 routes even if they are not the same. I am not specifically using ecmp I just have multiple routes for fast failover.

For the ECMP it's necessary that as-path length, weight, localpref, med, etc were the same.
Only, in that case, more than one eq route will be installed in the routing table.

Fix in https://github.com/vyos/vyos-documentation/pull/234

I have the following:
set protocols bgp as maximum-paths ebgp '3'
set protocols bgp as maximum-paths ibgp '3'

@Merijn If you don't use ECMP, only one best route will be installed in routing table.
In your case, the best path via 20562 6830 198611 with localpref 140.
In the bgp table, all prefixes will be present.
It's a general BGP Best Path Selection Algorithm.
The same is true for ipv4.

After receiving
zebra[1507]: 0:2804:fa0:8000::/33: Route install failed

Is there a patch to include configuration for this out there somewhere yet? I'd be interested in testing it out; can possibly help with the patch if it's started too.

I agree: the logs should reflect the actions performed to update the router following the configuration change. As this should be the same each time, we should be able to check a change with a saved replay, as a way to check that all is as should (part of the smoketest testing).

Closed due to inactivity.

How about parallel loops?
https://metacpan.org/pod/Parallel::Loops

Both Routers running VyOS 1.2.3

This PR still needs to be merged: https://github.com/vyos/vyatta-cfg/pull/23

The above patch breaks sorting for other nodes that contain text, not a number. We'd need some way to distinguish different node types (text, IP, number,...) and chose different sorts depending on that.

This is only for interfaces, T2175 is for all frr related daemons .. other features need a ticket

In the current 1.3 branch the original issue was resolved and added STOP script support. It is necessary to test this and review the possibility to backport the solution into 1.2.

Is this only for interfaces or for other rewrites (NAT, Firewall, BGP) too? If so, I'll add all the related tasks.