There's something weird happening with this. If you change simply persistent-keepalive from 25 to 30 or 30 to 25 will reactivate the peer. At least thats my experience. Doing anything else didnt work for me including:

Best suggestion seems to be introducing a script to call podman stop -t N on shutdown/reboot to reduce the timeout before SIGKILL is sent.

Backported in https://github.com/vyos/vyatta-cfg-quagga/pull/97

Is there some progress? VPP is available for AArch64 in meantime.
Here some news about VPP performance:

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

Fixed in https://github.com/vyos/vyatta-cfg-system/pull/188

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

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

A simple work around could be to trigger a podman start command when a restart container $CONTAINER_NAME is entered. If the pod isnt already running or in a stopped state, it will look at the config and start it up.

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

Any update on this, since it's been more than 2 years since the initial request? This would indeed be very useful for hairpin NAT. It it complicated to implement?

I think this should be re-opened. The solution that is documented does not follow the spirit of hairpin NAT, which is that traffic on port N not actually destined to the inside target should not be redirected.

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

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

@Nova_Logic As a workaround can you try the following configuration, this should ensure the behaviour you're after:

policy {
    local-route {
        rule 1 {
            fwmark 201
            inbound-interface eth0
            set {
                table 201
            }
        }
        rule 2 {
            fwmark 202
            inbound-interface eth0
            set {
                table 202
            }
        }
        rule 3 {
            fwmark 203
            inbound-interface eth0
            set {
                table 203
            }
        }
    }
}

I had a closer look at this, the commits here and here should have brought this back from the dead but there is a small issue where the table "ip nat" is used when at the same time all of the nat related chains were refactored into the vyos_nat table. The normal functionality of WLB isn't affected because the mangle table isn't changed.

@thetooth but according to current docs that exactly what is documented in docs: https://docs.vyos.io/en/equuleus/configuration/loadbalancing/index.html