https://github.com/FRRouting/frr/pull/14887

A fix that changes the behavior back to it was https://github.com/vyos/vyos-1x/pull/2527

Tested in VyOS 1.4-rolling-202311100309
The configuration:
VyOS:

In VyOS 1.3.4
Configs:

I tested in VyOS 1.4-rolling-202311100309

Tested VyOS 1.4-rolling-202311100309

It seems to be a bug in the FRR that delete isisd configuration completely

router isis VyOS
 net 49.0001.1920.0200.0011.00
 lsp-mtu 1460
 redistribute ipv4 connected level-2
!
!
interface eth1
 ip router isis VyOS
 ipv6 router isis VyOS
!
interface tun0
 ip router isis VyOS
 ipv6 router isis VyOS
!

check

r1# conf t
r1(config)# router isis VyOS
r1(config-router)#  net 49.0001.1920.0200.0011.00
r1(config-router)#  lsp-mtu 1460
r1(config-router)#  redistribute ipv4 connected level-2
r1(config-router)# !
r1(config-router)# !
r1(config-router)# interface eth1
r1(config-if)#  ip router isis VyOS
r1(config-if)#  ipv6 router isis VyOS
r1(config-if)# !
r1(config-if)# interface tun0
r1(config-if)#  ip router isis VyOS
vtysh: error reading from isisd: Success (0)Warning: closing connection to isisd because of an I/O error!
r1(config-if)#  ipv6 router isis VyOS
Warning: connecting to isisd...failed!
isisd is not running
r1(config-if)# !
r1(config-if)# end
Warning: connecting to isisd...failed!
r1# 
r1#

submitted PR: https://github.com/vyos/vyatta-op-vpn/pull/37

It looks like maybe there’s just some op mode command changes.

Tested in 1.3. Everything works

Tested in 1.5

I’m also seeing this error after the update to 1.3.4

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

There is a bug when we use lowercase "cisco"

set service pppoe-server authentication radius rate-limit vendor 'cisco'

It doesn't work as vendor is Cisco not cisco

vyos@vyos-lns# sudo cat  /usr/share/accel-ppp/radius/dictionary.cisco | grep -i vendor
VENDOR		Cisco

This has been implemented in 1.5 and 1.4.

It was fixed in a keepalived project.
https://github.com/acassen/keepalived/commit/9ca8688c7fe591e1face259f19ee6169e20a3438

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2402

Hi all, looks like that thanks to: https://github.com/acassen/keepalived/issues/2296, keepalived upstream repository fixed this issue with commit: https://github.com/acassen/keepalived/commit/81eb41fb12afe6ef56a6fd79cd4cb3cb5362c34b

Hi all, sorry for joining an old conversation, but I think it is a bit confused here and looks like you are trying to work-around the VRRP protocol specification with the argument rfc3768_compatibility - but I'm note sure to understand such behavior and if it is the best way.

The new-style op mode is well-established now, it's time to close the task.

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2381

Furher to this, manually setting "mru 1500" gives me my 1500 MTU back again.

The new MRU config in 1.3.4 seems to have caused my MTU to be lower.

RNDIS is once more on the "removal" list of the Linux Kernel.
https://www.phoronix.com/news/Linux-Disabling-RNDIS-Drivers

Fixed in
1.4/1.5: https://github.com/vyos/vyos-cloud-init/commit/5d3e4e79746772d80a6289f352e3606382f73eaa
1.3: https://github.com/vyos/vyos-cloud-init/commit/f627bf85746c5785836086538879e1101b6c4af3

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

Final testing before PR, the following corrects behavior when configuring the http-api using the http-api, for example:

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2348

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2347

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

Yes, I will add that as a first step ...

Added for 1.4, 1.5; as mentioned above, a backport to Equuleus will require a different implementation.

The similar bug with load if we change something in service https api

curl -k --location 192.168.122.11 --request POST 'https://192.168.122.11/config-file' --form data='{"op": "load", "file": "config.boot"}' --form key='foo'
{"success": false, "error": "", "data": null}

Based on the requirements, it is natural to add this to the commit_revision post-commit hook of the config_mgmt module: this is low overhead as we use the existing configtree representation of the current config to save with ConfigTree().to_json().