backported to crux

Changing squid_ldap_auth to basic_ldap_auth should be enough to fix the ldap part.

So you used /usr/lib/squid3/basic_ldap_auth? Then I‘m going to correct the scripts

this config worked as expected with Microsoft AD.

Once you verify if the module works I‘m happy to fix it.

yesterday i give up with it, i will try it again later and report it here.

Does it work as expected?

We have to consider a situation. If all physical interfaces do not have a link UP, the configuration of l2tpv3 cannot be configured. This part seems to be a problem with IP l2tp.

@hagbard Yes, we reach the other tunnel endpoint via router 10.52.192.9. This is also running without any issue. Only after a reboot not the whole configuration gets sometimes loaded. If this fails, you are able to do a load and a commit. This will setup the missing part without any issue.

Will be in the next rolling available.

As a work around do either:

@krassle I added your patch. will be in next rolling release. thx

@c-po
Hello, unfortunately this issue is not fully resolved (tested in Crux 1.2.1) because the name of the shared-network is still prepended to the hostname in /etc/hosts by dhcp_server.py. It's hard-coded, but should be conditional to actually restore the old behaviour (before core rewrite), where (like @CBRjack described) a flag "disable_prefix" triggered by the "use-host-decl-name" option did prevent the old dhcp-config.pl from prepending the shared-network-name.

I've had this bug occur on 1.2.0-rc11, at one site (with moderately high load) at least once a day, and at the second site (with small load) only once after several months.
After upgrading to the latest 1.2.0 rolling release I've had no issues any more, however the bug may still remain.
It may have something to do with DNSSEC setting as the second system that ran flawlessly for months before started doing it immediately after setting dnssec=validate.

Fix confirmed in the following version:

So is it considered a bug or works as intented?

Already fixed by @hagbard and deployed into current rolling release.

I've got a few more bits of information on this. I've managed to get DNS resolution to consistently work by placing the actual DNS servers in the dns section of my config instead of using just the system config keyword.

I just spawn a Smokeping to monitor the DNS server with a cache of 0 entries, lets see.

@Maetthi You reach 10.52.192.174 via router 10.52.192.9, is that correct in your config example above? If so, did you try to capture the traffic on 10.52.192.9 for .14 and 174?
I've used your example above, however on vm's only and changed your /29 to a /24 and didn't find any problems. So the question is if you can see on .9 the SCC* messages?

There are things that should be simply incorrect grammar, and this is one of them, as of me.

As per request from dmbaturin on slack:

I'm currently running 1.2.0-201904160337 and I seem to have stumbled upon a similar issue, but this time with L2TP/IPsec links, which when come up fail to also configure their related static routes.

@syncer Which version of frrouting is VyOS currently built against?

Only when you create an address, can be via dhcp or manually.

If that is the only point, race conditions can occur. I assume this is only called when comitting or loading the config.

https://github.com/vyos/vyatta-cfg-system/blob/current/templates/interfaces/ethernet/node.tag/address/node.def#L10

When is host_name.py called? Maybe my dhcp server just responds slow and host_name.py is called before dhcp server responds? Is that possible?

I can't reproduce, tested live and installed.

I just had another go with vyos-1.2.0-rolling+201904260337-amd64 and no different. My board has igb not ixgbe (I think that is a different chipset)

@syncer Sorry for the delay.. life got a bit hectic the last few months.

https://github.com/vyos/vyos-1x/commit/6d848ec832d2911db487a2b04235759971022d47

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html#bandwidth-shaping