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

In T5376#176807, @svd135 wrote:

The data channels are not established.
As I understand it, the problem is that the required related ports are not forwarded dynamically to translated address

Yes please - just to rule this out

Simple fix here; PR pending following tests.
https://github.com/jestabro/vyos-1x/tree/pxe-boot

Compat names were dropped in https://github.com/vyos/vyos-1x/commit/c8ef5e8bdce01bbf05297df39e6c6223d0b2a2ea

Fixed for 1.4

set interfaces bonding bond0 member interface 'eth1'
set interfaces bonding bond0 member interface 'eth2'
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 vif 667 address '10.6.67.11/24'
set interfaces bonding bond0 vif 668 address '172.29.0.11/24'
set interfaces bonding bond0 vif 668 redirect 'ifb0'
set interfaces input ifb0 
commit

enable-local-traffic just writes several old iptables rules https://github.com/vyos/vyatta-wanloadbalance/blob/961a2e8862280d2ce5500626cdee8a1adaa67ab2/src/lbdecision.cc#L124-L130
Propose to close task as "wontfix" due to the old backend and C implementation.
The correct behavior should be implemented for the protocols failover route feature.
I also propose to close all load-balancing wan tasks as wontfix for the same reason.
The task for dynamic interface T5647

Update from the PR

The changes from this pull request has already been incorporated and will be in the next major release of open-vm-tools.

https://github.com/vmware/open-vm-tools/pull/689#issuecomment-1948466725

Including v4?

Still bug for VyOS 1.5-rolling-202402131735

I'd delete the whole firewall configuration, at least for test.

@c-po As it relates to v6, no, i have no nothing

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

@FileGo Could you re-check? As you have the full configuration to reproduce.

@hexes Could you recheck/update if it is still the bug?

@n.fort Which migration are you expecting here?

Fixed

vyos@r11# run show conf com | match "flow|ppp"
set interfaces pppoe pppoe1 authentication password 'user1'
set interfaces pppoe pppoe1 authentication username 'user1'
set interfaces pppoe pppoe1 source-interface 'eth1'

interesting, it may have been broken sometime between 1.3.1 and 1.3.6 then. I used automations like these all the time. let me verify the behavior generally on ubuntu

client6_send: transmit failed: Operation not permitted

Works as expected:

Fixed by upstream frr 9.1 release. There was a missing exit when entering frr-reload contexts.

It is still a bug VyOS 1.4-rolling-202402160309. After deleting the tunnel key from both sites there are no pings

Works in this version 1.5-rolling-202402160022

Do not see the difference with 1.3.6

$ ./automation.sh te123
++ dirname ./automation.sh
+ SCRIPT_DIR=.
+ HOST=te123
+ echo 'local arg of host: te123'
local arg of host: te123
+ ssh [email protected] '/bin/vbash -s' te123
remote hostname: 1

Not a bug for 1.5/1.4 anymore.

vyos@r11# set service pppoe-server client-ip-pool POOL range 100.64.24.1/24
[edit]
vyos@r11# run show ver
Version:          VyOS 1.4.0-rc3
Release train:    sagitta

It is not a bug for 1.5/1.4

set policy route-map FOO rule 10 action 'permit'
set policy route-map FOOv6 rule 10 action 'permit'

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

@SrividyaA Could you re-check and close the task?

Try to check if the routes exist in the FRR config.

vtsyh -c "show run staticd"

Needs re-check as FRR was updated. Also, update GNS3 to the latest version.
It is not clear how to reproduce it without GNS3 on the some VM