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:

Propose to add names for the interfaces:

set interfaces ethernet eth2 vif-s 100 vif-c 300 name if9999

An additional found old dhcp-client issue, does not properly support interface names with length > 13
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858580
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704072

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

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

You can use the next type of configuration

set protocols bgp 4200010000 neighbor 2001:db8::2 address-family ipv6-unicast peer-group 'CUST_CR_IPV6'
set protocols bgp 4200010000 parameters default no-ipv4-unicast
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'

But we recommend to check the result in FRR configuration.

Trying to fix it is too risky because it may stop other not-quite-valid configuration from loading and we don't know how big the impact is going to be. 1.4 doesn't have the issue, and 1.3 is in the maintenance phase.

Backport to 1.3 is not worth the trouble since the issue is low-impact.

I thought the fix was merged post-2.2.8 and that we were waiting for next upstream release, or is my understanding of the build process wrong?
https://github.com/vyos/vyos-build/blob/a9cc581827e9a0ba1646b16ed07170e4ec2ca34e/packages/keepalived/Jenkinsfile#L27

PR https://github.com/vyos/vyos-build/pull/556

@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

Can someone re-check it in 1.5/1.3.6?

It can be working with set service dhcp-relay disable

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

Recheck and close it iff it was solved

In T6221#182954, @fetzerms wrote:

I only created a vrf (but did not assign it to anything else). Is that intend to break connectivity?

The minimal configuration to reproduce:

set interfaces ethernet eth0 address '192.168.122.14/24'

Starting from the config above:

I am trying to narrow down how that happens, as my other experiments with vrf look fine.

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