Have some bugs:

set vrf name blue ip protocol bgp route-map 'foo-map-in'
set vrf name blue table '1012'
set vrf name green ip protocol bgp route-map 'foo-map-in'
set vrf name green table '1011'
set vrf name red ip protocol bgp route-map 'foo-map-in'
set vrf name red table '1010'

Merged

Both tasks were solved
Reopen it if necessary

PR closed

The PR was rejected https://github.com/vyos/vyos-1x/pull/422

No actual bug or feature

There are no responses from the author.
Reopen it if it sill bug

The file is not actual and does not exists
Reopen if necessary with more details

Not planned
Reopen if necessary

We have not planed for the near future.
Reopen if necessary.

We are not going to do it these days.
There are no reasons to use claster after migration to VRRP.
The cluster was deprecated and deleted. Reopen if it is still relevant.

Can we close it?

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