Reopen it you are working on it.
Closes it as wontfix because there are no opensource codes that I found which was provided
On the main page only some prices and " All plans come with a free 14-day trial. "
It is not clear what is required and which CLI is proposed

@shthead add an example of "set| commands to reproduce

@aalmenar Explain the required feature in more detail

@bbabich Are you working on it?

Can you create a PR?

@Apachez Could you recheck if it works as you expected?

vyos@r4# set high-availability vrrp group FOO garp 
Possible completions:
   interval             Interval between Gratuitous ARP (default: 0)
   master-delay         Delay for second set of gratuitous ARPs after transition to
                        master (default: 5)
   master-refresh       Minimum time interval for refreshing gratuitous ARPs while
                        beeing master (default: 5)
   master-refresh-repeat
                        Number of gratuitous ARP messages to send at a time while beeing
                        master (default: 1)
   master-repeat        Number of gratuitous ARP messages to send at a time after
                        transition to master (default: 5)

Fixed:

vyos@r4:~$ show interfaces wireless info 
No Wireless interfaces configured
vyos@r4:~$ 
vyos@r4:~$ 
vyos@r4:~$ show version 
Version:          VyOS 1.5-rolling-202401190024
Release train:    current

Still bug for 1.3.5

set protocols bgp 4200010000 address-family ipv6-unicast redistribute connected
set protocols bgp 4200010000 address-family ipv6-unicast redistribute static
set protocols bgp 4200010000 neighbor 2001:db8::2 address-family ipv6-unicast
set protocols bgp 4200010000 neighbor 2001:db8::2 peer-group 'CUST_CR_IPV6'
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 address-family ipv6-unicast
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 remote-as '65500'

@I-n-d-y Try to get it working without VyOS CLI.
Provide the required contrack config. As I'm not sure that it will work correctly at all.

Fixed

vyos@r1# set interfaces ethernet eth1 description test
[edit]
vyos@r1# time commit

IGMP was migrated to PIM https://github.com/vyos/vyos-1x/commit/383231dae8c01ea58d0c956688ecd87f739be97e

Impossible with FRR

r1# conf t
r1(config)# no ipv6 prefix-list PUB seq 10 permit 2001:db8::/32 le
% Command incomplete: no ipv6 prefix-list PUB seq 10 permit 2001:db8::/32 le
r1(config)#

@carl.byington Could you re-check? is it fixed?

If the problem exists, it should be fixed on accel-ppp site.
I am not sure that I can help here as it is written on C

1.3.5 fixed

vyos@r1:~$ reset vpn remote-access user 
Possible completions:
  <text>        Terminate specified users current remote access VPN session(s)

Create a new task and provide links and examples for the KEA-DHCP-server implementation if it is supported.
ISC-DHCP-server is deprecated.

ISC-DHCP is deprecated, and we do not expect new updates.
The 1.5 is migrated to KEA-DHCP
Close it as wontfix

Use the persist option as after each interface, recreation indexes are created dynamically.

Since it didn't function properly in either Quagga or FRR...
I suggest addressing this issue to the upstream codebase, as we currently do not maintain SNMP MIBs. Your attention to this matter would be greatly appreciated.

Since it didn't function properly in either Quagga or FRR...
I suggest addressing this issue to the upstream codebase, as we currently do not maintain SNMP MIBs. Your attention to this matter would be greatly appreciated.

@olofl Open the task with a new actual description and examples for nftables.
Both links are unreachable

Tested in latest 1.5-rolling-202401190024 release, the commit fails when duplicate static-mapping is configured as expected.

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

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

@sdev Quick question on this issue.

I've traced the issue back to a USB device that creates an Ethernet interface on the OS. I suspect that the issue was caused by the USB device not being ready by the time ddclient tried to start and bind to configured interfaces, causing the boot time configuration to fail. Given that this is an edge case that would rarely occur, and now that I have replaced the USB device with an actual Ethernet device, I'm happy to close this bug report.