I hacked this into VyOS/Vyatta some 5 years ago - all it took was commenting out a snippet in Zone.pm and /opt/vyatta/share/vyatta-cfg/templates/zone-policy/zone/node.tag/from/node.def to prevent VyOS from complaining when creating a zonex_to_zonex chain

Intel QAT works for CRUX brunch. As for rolling with the newest kernel 5.8.5, it seems some issues on the modules building stage.

Issue seems to be related to quote handling. OS seems to have version as 1.2.5 and GRUB file shows "1.2.5". show system image reflects the GRUB name. If I manually remove the quotes from the GRUB file, I can successfully rename and delete the image.

From official docs

@c-po I build qat manually but add --enable-qat-lkcf to https://github.com/vyos/vyos-build/blob/crux/packages/linux-kernel/build-intel-qat.sh#L55 and it seems it works

vyos@R2-QAT:~$ show system acceleration qat device qat_dev0 flows 
+------------------------------------------------+
| FW Statistics for Qat Device                   |
+------------------------------------------------+
| Firmware Requests [AE  0]:              147225 |
| Firmware Responses[AE  0]:              147225 |
+------------------------------------------------+
| Firmware Requests [AE  1]:              113758 |
| Firmware Responses[AE  1]:              113758 |
+------------------------------------------------+
| Firmware Requests [AE  2]:              144886 |
| Firmware Responses[AE  2]:              144886 |
+------------------------------------------------+
| Firmware Requests [AE  3]:              147221 |
| Firmware Responses[AE  3]:              147221 |
+------------------------------------------------+
| Firmware Requests [AE  4]:              113774 |
| Firmware Responses[AE  4]:              113774 |
+------------------------------------------------+
| Firmware Requests [AE  5]:              144891 |
| Firmware Responses[AE  5]:              144891 |
+------------------------------------------------+

The perl scripts didn't create any config line, that's why I'm asking. I have it already implemented and successfully tested with the new python code, but wonder how people were able to use it all by just using the cli. I may need somebody for testing with AD, since I don't have access to any AD environment anymore.

Tested on 1.3-rolling-202009060846

PR https://github.com/vyos/vyos-build/pull/124

Large enterprises usually use LDAP/AD to authenticate and log its users web browsing, so this should be added. Anonymous binding is kinda old fashioned so maybe it was a bug.

Does anyone know if ldap auth worked at all with the old perl backend? I try to find out how likely I need to migrate cli entries. from what I have seen, ldap auth with anonymous ldap browsing didn't generate any required config for squid.

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.