why don't we chang unbound to coredns ? Coredns will be more stronger thant unbound.

@Viacheslav it happened yesterday again but the stack trace was different. This time it was complaining that BGPD did not respond and the frr watch process tried to restart it, which of course did not help the situation.
I will continue to monitor but i think we can close this issue and wait for more details when it happens again.

@Viacheslav yes latest rolling release is working with your patch, thank you so much Sir.

PR https://github.com/vyos/vyos-1x/pull/539

@Cheeze_It
It would be great.

PR https://github.com/vyos/vyos-1x/pull/538

If you guys want, I can also try to test it out too...

@Hazza06 Can you check the latest rolling release?

@Dmitry in various reboots and real-config-tests we've seen it settle in a few seconds, and we've seen it do 121 failed again today:

@maznu but it seems really odd behavior, I mean message settled in 121 sec. failed!
121 sec - equal to 121 interfaces when the router is first booted. But if in config already present hw-id, it should be faster then 0 sec.
Will be interesting to reproduce this in our lab. Also will be helpful if you provide sudo dmesg output.

PR https://github.com/vyos/vyos-1x/pull/537

The bad behavior of udev/systemd was a topic of an interesting twitter thread...

As per @Dmitry's suggestions, I did exactly the above. Upon reboot it did not look promising:

@adestis yes, that is true....but that can be worked around. Any option can be used (either BFD, or ARP, or ICMP). I just wanted to give more ideas so that hopefully can get a working implementation for all 3.

@Cheeze_It BFD for static routes would be nice as well but sometimes the target you test against is not under your control and/or does not support BFD.

Even with customers routes redistributed by OSPF instead of iBGP, it has just crashed again:

I tried unit-cache earlier but it seems to have issues too - I've seen duplicate routes if the same client (all have static IP assigned by RADIUS based on username) connects to a different PPPoE server and the old route is not removed, as if the cached (not removed) PPPoE interfaces were not seen as removed in FRR. But I haven't investigated this in more detail as it's a production setup, can't experiment too much on live customers.
I'm considering if I could go back to redistributing PPPoE customers /32 routes in OSPF instead of iBGP - it has been that way for a few years (using MikroTik, before moving to VyOS), but I've recently changed it following "BGP Best Current Practices" http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf which recommends using OSPF only for infrastructure, not customers - seems logical to me as BGP was designed for much larger routing tables (all of the Internet), but perhaps OSPF is still good enough for just a few hundreds of customers.

Hello @marekm, I think [ppp]unit-cache=n might help in this case, but the main issue in FRR. Do you want a package for the test with these improvements?

unit-cache=n
By default is disabled: unit-cache=0

Resolved in PR536.

Multiple fixes have been placed into the 4.19 series Kernel. Could you please try upgrading to VyOS 1.2.5 or 1.2.6-epa1?

In T563#74302, @c-po wrote:

Please use the new get_config_dict() API calls.

Please use the new get_config_dict() API calls.

Squid will be used for authentication and controlling name resolution (pointing to a spacial DNS or so?) , no squidguard or caching will be used anymore. It also ran in transparent mode per default, which requires an iptables rules set. I think that feature can be removed, since a transparent proxy has no authentication options anyway.

I've just had two different routers (one bare metal and one VM) crash roughly at the same time, triggered by many PPPoE sessions disconnecting at the same time due to a short power failure (routers itself had power all the time, but power was interrupted for about a minute to a switch on the network between the routers and PPPoE clients). Stack traces are very similar (absolute addresses differ, but the same functions and offsets in them). And again, each time watchfrr restarted bgpd but it was not working until reboot. No problems so far with two other BGP routers running a similar configu but without any dynamic interfaces (only OSPF and BGP, no PPPoE servers).

I tested this in LAB and it seems works properly. Changing interface name for eth1 and eth2

vyos@vyos# delete interfaces ethernet eth1 hw-id 
[edit]
vyos@vyos# delete interfaces ethernet eth2 hw-id 
[edit]
vyos@vyos# set interfaces ethernet eth1 hw-id 50:01:00:02:00:02
[edit]
vyos@vyos# set interfaces ethernet eth2 hw-id 50:01:00:02:00:01
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save 
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vyos# run reboot now

After reboot

vyos@vyos:~$ sudo ethtool -P eth1
Permanent address: 50:01:00:02:00:02
vyos@vyos:~$ sudo ethtool -P eth2
Permanent address: 50:01:00:02:00:01

@maznu , can you provide next:

show configuration commands | match hw-id
sudo cat /run/udev/log/vyatta-net-name.coldplug

@c-po https://github.com/vyos/vyos-build/pull/121 will fix it, but I used .142 while the conifg file was from 136, so please review first. I tested it and the system speaker is fully functional again.
You can test it quickly via `echo -ne "\a"', which should make noise. Beep seems to be broken, looks like it can't be used via sudo, something I may can have a look later into.
cheers

echo -ne "\a" should give you a beep sound on the the system speaker too, if you just want to quickly test it. I tested it with deb10 minimal install, works via qemu too.
e.g: qemu-system-x86_64 -smp cpus=3 -soundhw pcspk -m 1024 -enable-kvm -drive file=os.img,media=disk (os disk is a deb10 netinstall).
With capabilities I meant the listed capabilities listed under the input link via sys:

Any news on this one? Have posted some of the pain I've been having in T291 where VyOS is neither behaving as per documentation (match on hw-id) nor consistently across reboots.

Yup, the same situation: It's there on LTS but not on nightly. Also nonexistent functionality on frr, so it can go from the completions too. (Although the CLI files are still in the vyatta-op-quagga repo.)
However it still seems to be stuck in reset on nightly:

$ reset ip bgp foo rsclient
% Unknown command:  clear ip bgp foo rsclient

We look forward to the solution of this problem