1.5 should not have such issues.
1.4: op-mode should be working as expected. Backport for https://github.com/vyos/vyos-1x/pull/2344 failed. I'll submit PR for 1.4 for such feature.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Oct 23 2023
Oct 22 2023
Hi all, looks like that thanks to: https://github.com/acassen/keepalived/issues/2296, keepalived upstream repository fixed this issue with commit: https://github.com/acassen/keepalived/commit/81eb41fb12afe6ef56a6fd79cd4cb3cb5362c34b
I think we can do something similar to it : https://alestic.com/2018/12/aws-ssm-parameter-store-git-key/
various tracking (interface etc)
Hi all, sorry for joining an old conversation, but I think it is a bit confused here and looks like you are trying to work-around the VRRP protocol specification with the argument rfc3768_compatibility - but I'm note sure to understand such behavior and if it is the best way.
In T5673#162681, @Apachez wrote:Should debug code really be part of production releases?
Wouldnt it be sufficient that you can enable this on your own if you want a debug build being made?
Should debug code really be part of production releases?
Oct 21 2023
@rayzilt Could you re-check and close it if solved?
Could you try it locally and see what happens?
@Apachez I suppose it is.
- biosdevname is called by scripts in the initrd, so we can't remove it just yet.
- it's not completely abandoned and had quite a few releases since the point when Vyatta forked it.
- I sent a PR to allow biosdevname to run in VMs (that's the only thing that vyatta-biosdevname has and that's used in scripts): https://github.com/dell/biosdevname/pull/12
I could not find any uses of "slave" in current VyOS versions. If anyone finds any, feel free to start a discussion. VRRP "master" terminology cannot be changed because it's a part of the protocol spec itself, and, as said above, its counterpart is "backup".
Closing due to Crux EOL.
Crux is EOL now, but if similar issues appear in newer versions, feel free to report them!
The new-style op mode is well-established now, it's time to close the task.
The problem was resolved in the forum. Whether the underlying cause in FRR was resolves is another question...
vni100 should be the bridge slave here.
So those options could be in the same level of "allowed-vlan" and "native-vlan"