See T6131 for a report of the VTUN/OSPF issue with a simple lab config, which occurs separately from a migration.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 17 2024
Mar 16 2024
We'll update the key and make a post about it soon, sorry for the lengthy mix-up.
comments above are for https://vyos.net/get/nightly-builds/
Bumped into another instance of this issue:
curl -k --location --request POST "https://$VYOS_HOST/configure" --form key="$VYOS_KEY" --form data='[{"op":"set","path":["policy", "access-list", "2", "rule", "5", "description", "2024-03-16T14:52:44Z"]}]' {"success": false, "error": "[[policy]] failed\nCommit failed\n", "data": null}
@jestabro I have tested my usecase now and it seems the problem is fixed and the API no longer segfaults. Thank you so much for the fix and the fantastic turn around on this.
Mar 15 2024
Should add the ability to view the default action log would be nice as well.
PR for 1.5: https://github.com/vyos/vyos-1x/pull/3137
I can download the image and add it from path just fine, e.g this works fine:
Proper would be to throw out chrony and use ntpsec instead which supports proper filtering.
Given that Chrony only allows one bind address, versus ntpd which allows multiple, a "wontfix" sounds like the correct answer! :-)
@m.serdienis Add set of configuration commands to reproduce.
The issue is which to choose if there are multiple, thus removing all, chrony will listen on all interfaces.
Most likely won't fix
https://chrony-project.org/doc/3.4/chrony.conf.html
I don't think it is expected to get speed to the node itself.
A router is generally used for forwarding traffic. It is better to use iperf to check the speed between 2 hosts.
There do already exists tasks regarding commit and boot times such as: https://vyos.dev/T5388
@Apachez the original issue was related nft
If use nftables natively as:
Mar 14 2024
I wouldnt call 1m37s of commit time for a single line of configchange as "resolved"...
Also probably related: https://forum.vyos.io/t/long-commit-time-for-multiple-vrfs/14053
PR https://github.com/vyos/vyos-1x/pull/3132
set service config-sync mode 'load' set service config-sync secondary address '192.0.2.1' set service config-sync secondary key 'xxx' set service config-sync section firewall set service config-sync section interfaces pseudo-ethernet set service config-sync section interfaces virtual-ethernet set service config-sync section nat set service config-sync section nat66 set service config-sync section protocols static set service config-sync section pki set service config-sync section vrf
Change some section:
vyos@r4# set nat source rule 100 outbound-interface name 'eth0' [edit] vyos@r4# set nat source rule 100 source address '10.0.0.0/24' [edit] vyos@r4# set nat source rule 100 translation address 'masquerade' [edit] vyos@r4# commit INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=192.0.2.1 [edit] vyos@r4#
Is this related to the long commit and boot times when one have more than a handful routes or firewall rules as described in https://vyos.dev/T5388 ?
PR for 1.3: https://github.com/vyos/vyos-1x/pull/3130
Mar 13 2024
I have tested FRR NHRP with IPv6 as an overlay and I found some issues.
In T6116#179637, @sarthurdev wrote:Interfaces aren't added on boot because mac address is locally administered: https://github.com/vyos/vyos-1x/blob/current/src/helpers/vyos-interface-rescan.py#L60
Raised this issue before with @jestabro as also seen with VyOS as VM.
Can we let local-route support group options both in destination and source ?
set policy local-route rule 10 destination Possible completions: + address IPv4 address or prefix port Port number used by connection
Mar 12 2024
PR for 1.4 https://github.com/vyos/vyos-build/pull/528
Interfaces aren't added on boot because mac address is locally administered: https://github.com/vyos/vyos-1x/blob/current/src/helpers/vyos-interface-rescan.py#L60
Did this test again, and I got the same result.
Close the task due to the reporter not responding.
Reopen if you still have this bug.
Seems fixed, checked on VyOS 1.5-rolling-202403110024
vyos@r4# rollback Possible completions: <N> Rollback to revision N (currently requires reboot)
The similar task T5956
There are no old-style CLI definitions anymore, and thus no default: tags either, so this shouldn't be an issue anymore.
VyOS 1.5 will use Kea, while ISC DHCP is completely abandoned now and there's no hope this will be fixed.
The most frequently-used validators are already in OCaml now, for the rest we'll need to create separate tasks.