Starting from the config above:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 10 2024
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.
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.
Apr 9 2024
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?
@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.
@trae32566 Can you provide the next output?
sudo conntrackd -C /run/conntrackd/conntrackd.conf -s && echo "conntrack_count: " && sudo conntrack -C sudo conntrackd -C /run/conntrackd/conntrackd.conf -s network sudo conntrackd -C /run/conntrackd/conntrackd.conf -s cache sudo conntrackd -C /run/conntrackd/conntrackd.conf -s runtime sudo conntrackd -C /run/conntrackd/conntrackd.conf -s link sudo conntrackd -C /run/conntrackd/conntrackd.conf -s queue