Test case above produces:

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

Merged T5178 into this one; cf. the description there for background of the issue.

PR for equuleus:
https://github.com/vyos/vyos-1x/pull/1969

PR for equuleus:
https://github.com/vyos/vyos-http-api-tools/pull/5

According to nft changelog, this feature is available in 1.0.7 in a much better way:

@Harliff Could you check it? Available in the latest rolling release

vyos@r14# set  protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 
Possible completions:
   all-available        All targets must be alive
   any-available        Any target must be alive (default)

Hi guys,

This has a simple fix: starlette commit c568b55d set the attribute

Request._form = None

to support use of Request.form() as a context manager. Since we override the Request class for backwards-compatibility support (translation) of form-data requests, we need to check for value, not existence, of the attribute. Adding this fix allows updating FastAPI past 0.91.0.

bfd is able to monitoring static routes , using profiles and multi-hop to reached a peer :

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

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

set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 'any-available'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.1'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.11'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check timeout '3'
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 interface 'eth0'

Don't have any idea how to integrate this logic to XML https://github.com/vyos/vyatta-wanloadbalance/blob/973421035568810e2583187c48d14054970b9806/templates/load-balancing/wan/node.def#L2-L5

Just in case someone wants to implement this: debugging must not be enabled by default, only on demand or via config.

Bug report https://forum.vyos.io/t/unable-to-update-to-1-4-rolling-release-past-netavark-changes/

Per VyOS maintainers, this operation isn't necessary.

In T5144#147124, @indrajitr wrote:

PR for the fix: https://github.com/vyos/vyos-1x/pull/1962

Tested on latest "current" source tree build. Works fine and solves the "old syntax" cache file issue. Thank you for the quick and responsive fix.

That would be great!

In T1237#147125, @Harliff wrote:

Sorry, missed some messages.

In T1237#146586, @Viacheslav wrote:

We have targets-checks 203.0.113.1, 192.0.2.1, and if any of these targets are unreachable, we delete this route.
Is it correct?

It is not correct. I think it would be better to remove the route if ALL of corresponding targets are unreachable.

A target may become unreachable due to a problem of its own rather than an uplink failure. This is the reason why I asked to add multiple targets per uplink.

In T1237#146839, @Viacheslav wrote:

@Harliff Could you re-check?

Sorry, missed some messages.

In T5144#147087, @Viacheslav wrote:

An issue https://forum.vyos.io/t/ddns-setup-issue/

PR for the fix: https://github.com/vyos/vyos-1x/pull/1962