- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
May 5 2025
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'
I have tested the lab without IPSec for 3.5 hours - PIMD is alive
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.
Same stuff see screenshoot:
Deploy a new VM with 1.4.2 copy configuration to the /config/config.boot (remove HW-id's), and reboot the router or execute load
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.