- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 5 2025
The immediate cause of the errors above is a missing check, to be corrected in the first commit here:
https://github.com/vyos/vyos-1x/pull/4493
This exposes a second possible migration error from migration script vrf/2-to-3, corrected in the second commit of the PR.
My use case is testing the newish rfc9463 which is DHCP option 162 for IPv4.
In Kea, the config looks like this
May 4 2025
I've noticed this as well. It doesn't appear to be related to IPv4 vs. IPv6; it appears to return whichever entry is first in /etc/hosts.
May 2 2025
PR https://github.com/vyos/vyos-1x/pull/4491
set system option kernel cpu disable-nmi-watchdog set system option kernel cpu isolate-cpus '1,2,4-5' set system option kernel cpu nohz-full '1,2,4-5' set system option kernel cpu rcu-no-cbs '1,2,4-5' set system option kernel disable-hpet set system option kernel disable-mce set system option kernel disable-softlockup set system option kernel memory default-hugepage-size '2M' set system option kernel memory disable-numa-balancing set system option kernel memory hugepage-count '256' set system option kernel memory hugepage-size '2M'
May 1 2025
@Viacheslav hello!
@Viacheslav Can you assign me to this task?
Has anyone been able to pick this up yet to take a look as to what might be possibly causing this? Or if there is something I'm missing or I could try?
All FRR daemons started even if not configured. You can check it with:
vyos@r1# ps ax | grep frr 1383 ? S<s 0:01 /usr/lib/frr/watchfrr -d -F traditional zebra mgmtd bgpd ripd ripngd ospfd ospf6d isisd babeld pim6d ldpd nhrpd staticd bfdd fabricd 1404 ? S<sl 0:00 /usr/lib/frr/zebra -d -F traditional --daemon -A 127.0.0.1 -s 90000000 1409 ? S<s 0:00 /usr/lib/frr/mgmtd -d -F traditional --daemon -A 127.0.0.1 1411 ? S<sl 0:00 /usr/lib/frr/bgpd -d -F traditional --daemon -A 127.0.0.1 -M rpki 1418 ? S<s 0:00 /usr/lib/frr/ripd -d -F traditional --daemon -A 127.0.0.1 1421 ? S<s 0:00 /usr/lib/frr/ripngd -d -F traditional --daemon -A ::1 1425 ? S<s 0:00 /usr/lib/frr/ospfd -d -F traditional --daemon -A 127.0.0.1 1428 ? S<s 0:00 /usr/lib/frr/ospf6d -d -F traditional --daemon -A ::1 1431 ? S<s 0:00 /usr/lib/frr/isisd -d -F traditional --daemon -A 127.0.0.1 1434 ? S<s 0:00 /usr/lib/frr/babeld -d -F traditional --daemon -A 127.0.0.1 1437 ? S<s 0:00 /usr/lib/frr/pim6d -d -F traditional --daemon -A ::1 1443 ? S< 0:00 /usr/lib/frr/ldpd -L -u frr -g frr 1444 ? S< 0:00 /usr/lib/frr/ldpd -E -u frr -g frr 1446 ? S<s 0:00 /usr/lib/frr/ldpd -d -F traditional --daemon -A 127.0.0.1 1451 ? S<s 0:00 /usr/lib/frr/nhrpd -d -F traditional --daemon -A 127.0.0.1 1455 ? S<s 0:00 /usr/lib/frr/staticd -d -F traditional --daemon -A 127.0.0.1 1460 ? S<s 0:00 /usr/lib/frr/bfdd -d -F traditional --daemon -A 127.0.0.1 1463 ? S<s 0:00 /usr/lib/frr/fabricd -d -F traditional --daemon -A 127.0.0.1 3486 pts/0 S+ 0:00 grep frr [edit] vyos@r1#
Apr 30 2025
More info: Maybe VyOS being affected by https://github.com/FRRouting/frr/issues/18537 ?
The simplest—and perhaps most crude—way to accomplish this may be to restart the vyos-domain-resolver service. This will automatically update the FQDN cache, remote groups, and restart the timer for regular pull intervals.
In T5493#222634, @adestis wrote:You are right, when a correct "base" address for the prefix is used.
If not the prefix is silently discarded (192.0.0.0/24 vs. 192.0.0.8/24).
I am ok with it. Just important for documentation.
Generated rules:
vyos@r14# cat /run/nftables-ct.conf #!/usr/sbin/nft -f
In short, setting listen-address requires an explicit 'systemctl restart nginx' instead of the existing 'systemctl reload-or-restart nginx'; a workaround before merge of the PR is to call the restart.