I agree, a separate DNS would be way easier to maintain if you have a lot of TLDs you need/want to block, since squid has to load it from a list, let's see if anyone is still using that, other wise it would be nicer and easier to scrape that off and implement a nameserver tag node win the cli.

And PR for vyos-1x: https://github.com/vyos/vyos-1x/pull/540

PR for vyos-build: https://github.com/vyos/vyos-build/pull/123

I've previously mentioned light blocking (domain level, gTLD level), but with the increasing amount of DoH, having a means to kill off DoH and force special DNS processing, including offload to a separate DNS server (managed by a security appliance for example, say PiHole or similar) would be valuable.

Is there any interest in the following scenarios:

Tested with:

set service dns dynamic interface eth0.203 service custom host-name 'test.vyos.net'
set service dns dynamic interface eth0.203 service custom login 'vyos'
set service dns dynamic interface eth0.203 service custom password 'vyos'
set service dns dynamic interface eth0.203 service custom protocol 'dyndns2'
set service dns dynamic interface eth0.203 service custom server 'vyos.io'

This also happens on service deletion

Looks like it's a floating bug - I've just sucscessfuly disabled a vti interface on another router (running vyos 1.2.6-epa1).

In T2508#74559, @dongjunbo wrote:

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

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