here is the documenation on frr about mpls enable/disable : https://docs.frrouting.org/en/latest/zebra.html#clicmd-mpls-enable-disable

we need to expose as well the following command to interfaces level :mpls enable

it could be fixed on it : https://github.com/FRRouting/frr/pull/17298

some information added which is related to SH filters as well :

I like the idea. Maybe we can extend this logic to other things, like WireGuard or VPNs. @a.apostoliuk @dmbaturin

FRR case where there is a long explanation: https://github.com/FRRouting/frr/issues/15400

It appears that when we redistribute connected in ISIS using route-map, it continues to add these routes or continuously learns them. I believe this may be the root cause of the problem.

I did a configuration, basic in this case, I'm not able replicate this bug:
example:

@Viacheslav yes, you are rigth... it's a feature request.

other task related to integrate this new feature: https://vyos.dev/T7766

more bug related to this task :

https://vyos.dev/T6750

basically with our test, it's missing a command which enable on the interfaces that can talk lfa with other isis routers, we should add this feature to solve this problmes

bug case in frr: https://github.com/FRRouting/frr/issues/19431

test and working:

patch : https://github.com/FRRouting/frr/pull/16159/commits/f153b9a9b636e7ca16ef066e934d355ba922df2b

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

I've found a bug when we want to load the configuration using frr-reload.py , task on frr:

another case : https://forum.vyos.io/t/delete-vrf-commit-failure/16786

@talmakion I think it good idea is removed , this attribute was added by cisco in the early day of internet, as you mentioned , it can be solved using 0:0 in a RM.

It looks like the problem is in this `key_mangling', it's probably that function where these kind of errors are given:

I've extend the test in the enviorment , it looks like there is a problem with names in our policies : eg , where it brokes the configuration :

frr task related to this incident : https://github.com/FRRouting/frr/issues/16095 and forum case: https://forum.vyos.io/t/issues-with-mp-bgp-and-ipv6-link-local-peers-using-extended-next-hop/15781

here is C code where is Fixed for Versions: 10.0.3, 10.1.2, 10.2.1, 10.3 : https://github.com/FRRouting/frr/pull/17586/commits/b0800bfdf04b4fcf48504737ebfe4ba7f05268d3 , but I think it shouldn't affect to frr- 9.1.2 which is used in the 1.4 sagitta, it was refactored in the newest version :

@sarthurdev i think it can be good idea to those case , what do you think ? @dmbaturin @jestabro

tested with the fixed done by @natali-rs1985 : , works with ports as well :

we've added this new feature called Server bridge , it's available in 1.5 and backported 1.4:

merge and tested in both version .

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

I think it has a interesting option `ethtool -K ethX ntuple [on|offwhich is interesting has the knowledge , we can keep it as a part the main task .

this task is already created, it involved many offload/NIC tunning which are described on this :

Documentation :
https://github.com/vyos/vyos-documentation/pull/1521

new structure was added :

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

tested and resolved : VyOS 1.5-rolling-202407251105

tested and resolved, we've added this change in our cli to fix this deprecate option in opnvpn :

[edit]
vyos@vyos-ser-win# set interfaces openvpn vtun10 server topology
Possible completions:
   subnet               Subnet topology (recommended) (default)
   point-to-point       Point-to-point topology
   net30                net30 topology (deprecated)

I've tested in the new version , the problem with default net30 , it is already there .however , when the new version started show a warning message that migrating from net30 to subnet because is going to be deprecated :

In T6211#194799, @stephenmcmahon wrote:

In T6211#189615, @Viacheslav wrote:

Probably the best way will be moving the config to the vrf section (not implemented)
For example:

set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'

task related : https://vyos.dev/T4025

I've checked this bug , it's still present the vesion 1.4./1.5 and the 1.3.x , this problem is related to the update of the new version (openvpn) where the syntax to create a tunnel tap (layer2) is changed , this command allow to transport frame and it's needed when you want to bridge a vtun :