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.

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

@vfreex Can you re-check to see if everything works as you expected?

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

https://vyos.dev/T3771 was resolved should this one be closed as well given your comment @sever ?

I don't have any issues with your config, but my addresses (of course, I don't have all BGP VPN connections, etc.)

vyos@r4# set vrf name foo table 10101
[edit]
vyos@r4# commit
[edit]
vyos@r4# 
[edit]
vyos@r4# run show ver
Version:          VyOS 1.5-rolling-202404090019
Release train:    current

Log output when starting keepalived:

Yup... it does not even come back after commit-confirm - so I assume something more severe crashes.

Unfortunately this also breaks after the commit (even tho the "commit" command finalizes). If I recall correctly, a commit-confirm won't reboot the box either - but I'll double check that.

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

r4# show run bgpd
Building configuration...

Yes, let me try.

Could you try the latest rolling?

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

Ok. Just to clarify, as T6097 talks about ipv6: This seems to break both ipv6 and ipv4 connectivity for me

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"
+ }

Probably the same task https://vyos.dev/T6097

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

Thats common with other vendors aswell.

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

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

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

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

Confirmed this is now fixed.

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

i think yes, now we will show frr logs for unhandled exceptions and normal short messages for others e.g. route-reflector-client only supported for iBGP peers

I gave it a go due to similarities between this and https://vyos.dev/T6123.

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.

Was it fixed?

@MattK Could you re-check and close it?