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
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 11 2024
@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
Recheck and close it iff it was solved
Apr 10 2024
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:
set policy local-route rule 101 destination '0.0.0.0/0' set policy local-route rule 101 set table 'local' set policy local-route rule 102 destination '0.0.0.0/0' set policy local-route rule 102 set table 'main' set policy local-route rule 104 destination '0.0.0.0/0' set policy local-route rule 104 set table '170'
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:
@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.