Thanks Apachez, I’ve seen that. Unfortunately the NIC is OEM (part of a networking appliance) so no firmware available.

Wouldn’t your suggested fix to https://vyos.dev/T6223 also apply here? If the plan is to validate interface name lengths and allow custom names this would be a non-issue.

According to https://community.intel.com/t5/Ethernet-Products/XXV710-V2-NIC-doesn-t-support-quot-ethtool-m-quot-Is-this-a-bug/m-p/730841 you need to:

Editing config.boot.default has addressed this. Pull request opened for comments/integration here: https://github.com/vyos/vyos-build/pull/559

Editing config.boot.default has addressed this. Pull request opened for comments/integration here: https://github.com/vyos/vyos-build/pull/559

@dex can you re-check?
It should execute the stop script if disable in config https://github.com/vyos/vyos-1x/blob/5d890037b177ce6971ac00f52e4cce2cac898f46/src/conf_mode/high-availability.py#L204-L206

It can be working with set service dhcp-relay disable

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

@greywolfe, let us know if you have tested it.

Reopen if you still have the issue.
Close the task as there is no response from the author. And we don't have reports like this.

The feature is present in 1.4 and 1.5:

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

It is another bug, it should be a separate bug report https://vyos.dev/T6223

related to T6141

After a bit more digging it looks like the 15 character limit is a kernel limitation, so the issue is more with how the interfaces are named when creating VRRP groups and no real handling of a scenario where the length is over 15 characters.

Yes, initial not applied. I corrected config and received other error

Log output when starting keepalived:

@d.shleg As I mentioned the config is not applied by FRR

r4# show run bgpd
Building configuration...

Message at 6 March

Initial not confirmed by FRR, but I provided configuration is accepted by FRR but not applied by vyos. Please look messages

Your initial configuration and adding a new peer is not acceptable by FRR

vyos@r4# run show ver
Version:          VyOS 1.5-rolling-202404090019
Release train:    current

vyos@r4# compare 
[protocols bgp neighbor]
+ 10.177.75.2 {
+     peer-group "OVERLAY"
+     remote-as "64542"
+ }

Removed assignee for now in case somebody else wants to fix this?

Removed assignee for now in case somebody else wants to fix this?

Sorry guys - I'm on 1.4-epa2 these days but aren't doing VRRP/Conntrack sync anymore.

Started on a PR: https://github.com/vyos/vyos-1x/pull/3288

My specific use case is a container that requires --sysctl=net.ipv4.conf.all.forwarding=1

Mark it as resolved, reopen the task if required.

@tjh Any updates?
By the way there is a new option

vyos@r4# set service conntrack-sync disable-syslog 
[edit]
vyos@r4#

https://conntrack-tools.netfilter.org/manual.html#sync-aa

conntrackd allows you to deploy an symmetric Active-Active setup based on a static approach. For example, assume that you have two virtual IPs, vIP1 and vIP2, and two firewall replicas, FW1 and FW2. You can give the virtual vIP1 to the firewall FW1 and the vIP2 to the FW2.

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

In T6099#182627, @Viacheslav wrote:

@Giggum Can you check it in 1.5?

Yeah sure thing I can do that. Will I be able to roll back from the latest 1.5 to the version of 1.4 rolling I’m on after testing is complete or will the config mess up?

@Daya @trae32566 Any updates?

@indrajitr Can we close it?

@indrajitr Can we close it?

@Giggum Can you check it on 1.5?

It is easy to add
In FRR it looks like:

r4(config-rpki)# rpki cache 192.0.2.1 8888 
  SSH_UNAME   SSH user name
  preference  Preference of the cache server
  source      Configure source IP address of RPKI connection

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

set nat cgnat pool external ext1 external-port-range '1024-65535'
set nat cgnat pool external ext1 per-user-limit port '1000'
set nat cgnat pool external ext1 range 192.0.2.222/32
set nat cgnat pool internal int1 range '100.64.0.0/28'
set nat cgnat rule 10 source pool 'int1'
set nat cgnat rule 10 translation pool 'ext1'

For me personally this change makes sense: a router has multiple interfaces, the Source IP is selected in different ways, and especially for RPKI servers outside the network (public ones), this could even break connectivity. Vendors like Juniper had this issue and eventually added the option, which means probably VyOS will benefit too, especially since "it's just setting a value in FRR's config"™ (famous last words ;).

Yes and no. Even before I created this ticket, I tried a small test locally. Unfortunately, I was not able to get the tests to run (even without my changes).

@Loremo I think this contribution would be valuable. Have you made any progress with your PR?

Great 😃

Hi -- this works. The VTI interface is just another interface so you can add it to a firewall zone just as you would an Ethernet interface. This can be done with existing site-to-site ipsec VTIs today. I also do it with OpenVPN interfaces for remote access on some of my installations.

This would be really useful. As per: https://forum.vyos.io/t/other-than-console-how-to-pass-grub-parameter-pcie-aspm-off/14203