@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 vyos@192.168.122.15 '/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

The UPNP Implemented but not fully working, related task T5835