@ordex Could you check the latest rolling release? Fancontrol should be there.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 28 2022
Issue with FRR https://github.com/FRRouting/frr/issues/12406
Nov 27 2022
I've been testing this for a few weeks now at home and haven't noticed any issues. That said, while I have 6 network zones and a few public services running, my home network isn't very complicated and doesn't have any "exotic" firewall rules. Since the changes are fairly minor and the smoketests pass, I don't think there should be any issues, though.
OSPF and ISIS segment routing should now have been successfully refactored...at least for now.
Nov 26 2022
Adding PR to fix OSPF opaque LSA and rfc 1583 compatibility to the OSPF FRR Jinja2 template.
It will be enough next config to reproduce:
set protocols mpls interface 'eth1' commit set protocols bgp system-as 65001 commit
Nov 25 2022
Verify check, PR https://github.com/vyos/vyos-1x/pull/1678
It must be RaiseConfigError if we delete one of the peers which related on the other veth interface
set interfaces virtual-ethernet veth0 peer-name 'veth1' set interfaces virtual-ethernet veth1 peer-name 'veth0'
I've made some tested, it seems works as we expected :
@marc_s Would you be able to open a PR against 1.3 ?
The behaviour is quite different depending on what is done. In my case another API key (not the one my application uses) should be deleted and fails, the service restarts afterwards and the config is still the same. Is there something like a hot reload missing? Also, if the API-server dies without restart (had that case several times, would have to find out, which command does that) even a change using cli did not recover the service.
Nov 24 2022
Fixed in T4660
I have the same problem. This is a kernel configuration issue. The following settings must be made:
Nov 23 2022
Issue not present in 1.3.2 image! Thanks
This task can be closed since the PR is merged.
Nov 22 2022
Thanks sir,
In T4823#138040, @chesskuo wrote:Hello sir,
In vyos-1.4-rolling-202211220318-amd64.iso, the broken syntax was fixed, but I notice a wired behavior on connection.<conn>.remote.id.
The default value on swanctl.conf will be <name> when I don't set site-to-site -> peer <name> -> authentication -> remote-id.
Hello sir,
@trae32566 My apologies for the inconveniences. You are right. The criteria for triggering this action shall be narrowed down further.
It would be necessary to issue the warning if and only if such colliding peers also specify the exact same remote endpoint addresses (with empty endpoints also being accounted as to be the same).
In other words, we need to identify incoming peers and apply the rule only to them, not the outgoing ones which already have specific remote endpoint addresses statically defined.
This breaks a perfectly valid use case which I utilize regularly: using IPv4 + IPv6 peers with the same public key. Why would I want to create multiple keys for the exact same devices going over IPv4 and IPv6? If you want to include a warning, fine, but don't limit functionality based on someone's interpretation of how something will be used. I understand where this came from, but any time you limit functionality, you limit your users. As Donald Knuth once said:
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
@Viacheslav Thank you sir!!!
Nov 21 2022
This is a nice addition but it requires also implementation of RFC 8781 for it to work. It has been merged in latest radvd https://github.com/radvd-project/radvd/commit/a6460662c6ac2b13307a8977ef068825b66fbce0 but it still hasnt been released
I think the issue is realated to this: https://blog.ipspace.net/2014/09/ipv6-neighbor-discovery-nd-and.html
I add here what I just found and I can reproduce the issue everytime.
You can test with 3-5 servers, the config is basic for each server: