- User Since
- Apr 24 2019, 5:50 AM (49 w, 6 d)
Sat, Apr 4
Can highly recommend: http://repo.saltstack.com/2019.2.html#debian (includes Jessie)
Wed, Mar 25
I'm not expecting a persisted-across-reboots FRR config — hence suggesting tmpfs — so when the system boots there is nothing there. Obviously something would need to create the (empty) FRR config files in tmpfs before running FRR, otherwise I expect all the FRR daemons will fail to start.
We've seen this recently on bleeding-edge (yesterday's version) of 1.3. I'm currently investigating what tripped ospf6d, but I suspect it's going to be some Ubiquiti routers spewing their nasty OSPFv3 implementation.
Sep 29 2019
Agreed, I'm going to workaround with set system sysctl custom, but also submit a PR: https://github.com/vyos/vyatta-cfg-system/pull/107
…or, indeed, it'd be great to be able to restart FRR and have it get a new config when this happened just now:
Sep 23 2019
That's fixed the problem we had, but we've encountered some other strangeness.
Thank you, @c-po, I'll go deploy it now, then! :-)
Has this been merged into 1.2, or just 1.3? Because all of the 1.2-rolling images currently available from downloads.vyos.io right now have this bug in them :-(
MikroTik RouterOS supports something like this:
Why does this BGP neighbor need to be configred in the VyOS CLI? Wouldn't it be added automatically as a side-effect of wanting netflow data to have ASNs? Maybe add a flag to netflow, for those of us who are carrying full tables.
Having had bgpd peg a core to 100% (for no discernible reason), I'd welcome the ability to give quag^WFRR a kick, rather than rebooting the entire VyOS box.
We run ntop on a separate device, and export netflow data to the ntop/nprobe box from our routers (VyOS included). Would that work in your scenario too?
Symptoms which cause no configuration of the device after booting into 1.2:
PR to fix this: https://github.com/vyos/vyos-1x/pull/136