Just booted vyos-1.2.0-rolling+201906230337-amd64.iso (4.19.52) and it does not work so that narrows it down a bit more. Either 4.19.53 or 4.19.54. Or were there any other changes to VyOS between June 23 and June 27 (other than the kernel) that could have fixed it?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Jun 27 2019
Hi c-po,
Just to confirm, HTTP proxy in this context being nginx being a reverse proxy frontend for GUI and API HTTP servers, likely living on localhost bindings, right?
I have upgraded a couple of clusters to 1.2.0-rolling+201906240337 and systems started successfully, and I also applied the hotfix indicated in thel pull request (https://github.com/vyos/vyatta-cfg-system/pull/102/files) to several productive clusters by just adding "/interfaces" to $VYATTACFG variable with the same successful results, so I can confirm that the fix provided by @mtudosoiu works great.
Jun 26 2019
In T1416#38821, @zsdc wrote:I have checked behavior in 4.3.5 and 4.4.1 versions. The information about hostname is still not synced from primary to secondary.
I wonder if this was even ever a working feature. Perhaps check the source of isc-dhcp.
As I see from the information in the Debian bug report, it is about the other bug - when hostname not rewritten after offering lease. From the ISC-DHCP changelog:
This corrects an issue where leases that were offered but ignored retained the client hostname from the original client.
Also, I have found another one problem - there is no trigger in the failover mechanism to run external commands, which are using for hostname updates. This means that, even if hostname would be synced via failover, this will be not enough for updating information inside the hosts.
Therefore, due to lack of functionality inside the ISC-DHCP syncing hostnames inside the hosts file via DHCP failover is currently impossible in the VyOS.
Yeah, I'd mark this not-a-bug. Update the documentation to mention hosts file update with failover doesn't maintain consistent state between failover servers.
All done so far, still need to do the show service commands and verify() to check the values before trying to write the config. But other than that it's working well.
I have checked behavior in 4.3.5 and 4.4.1 versions. The information about hostname is still not synced from primary to secondary.
As I see from the information in the Debian bug report, it is about the other bug - when hostname not rewritten after offering lease. From the ISC-DHCP changelog:
Since this changed dhcp6.client-id to only accept colon-separated hex lists, configs that still have the strings will fail to apply, leading to nonworking configs.
Should we bump the dhcp-server vyatta-config-version and write a migration script?
Shouldn't there be a separate dhcpv6-server/relay vyatta-config-version? Perhaps the migration script could add those.
In T1416#38770, @jjakob wrote:I think this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810971
Fixed in isc-dhcp 4.3.4-1 so pulling in newer isc-dhcp should fix it.@dongjunbo I don't understand the question. If you mean hostname and IP sync for DHCP leases, then yes, it should already do that via failover (except for hostname sync, which should work but doesn't due to this bug). Vyos uses isc-dhcp, so whatever it supports can be done in vyos (read isc-dhcp version 4.3.1 documentation).
As for the show statistics bug, please open a separate task and provide some more info (most useful would be /config/dhcpd.leases so we can test the code locally).
I think show_dhcp.py could do with some overhaul in the spirit of my recent show_dhcpv6.py additions, with better handling of different lease states etc.
Jun 25 2019
local auth successfully tested and started to implement. nouth can be set as an option too. radius still needs to be tested, but is always has a higher priority than any other authentication module. Shaper will be the last item implemented before it is going to be released to the rolling images, after that community can test.
@zx2c4 thanks for clarification. But why does OSPFv2 work as it uses multicast too if I remember correctly.
I think this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810971
Fixed in isc-dhcp 4.3.4-1 so pulling in newer isc-dhcp should fix it.
Yes. It explicitly doesn't do it.
@zx2c4 any known limitations around multicast in WG?
Another request: Is that easy to may host-update sync hostname and ip address with 2 vyos ?
In T1416#38611, @zsdc wrote:Hello, @dongjunbo!
Have you tried current rolling releases to check if leases information view work correctly now?
Seem like static counting still not right
This hasn't been possible because it links to vyconf, which makes a UNIX cultural assumption. However, I'm moving the tree handling modules and the parsers into a reusable library that can be used by both vyconf and libvyosconfig, and custom applications as well. Then it should be possible.
display dhcp lease should works, right?
How about dhcp work in failover mode. Should 2 dhcp server got hostname and sync match of hostname and ip address in 2 vyos ?
Jun 24 2019
Authentication is still missing, but so far is a well working prototype. DHCP relay is going to be implemented next as well as radius before I have a look into local auth.
Provided configuration from the first message was successfully loaded in 1.2.0-rolling+201906240337.
@csalcedo, could you test new rolling to check if the problem is solved for you too?
Hello, @dongjunbo!
Have you tried current rolling releases to check if leases information view work correctly now?
As I see, from current VyOS scripts, keepalived restart only at router startup or if all VRRP groups were deleted. In case of configuration change we use reload, which is correct.
This means that we get nothing from the keeping state in case of the restart - there is no sense to keep states of deleted groups, and we have nothing to keep at first startup.
https://github.com/vyos/vyos-1x/pull/77
tested working on rolling (current)
Jun 23 2019
[ 131.476053] i40evf: Intel(R) 40-10 Gigabit Virtual Function Network Driver - version 3.6.15 [ 131.476055] Copyright(c) 2013 - 2018 Intel Corporation.
vyos@vyos# dpkg -l | grep pdns ii pdns-recursor 4.2.0~rc1-1pdns.jessie amd64 PowerDNS Recursor
[ 82.439572] i40e: loading out-of-tree module taints kernel. [ 82.446562] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 2.9.21 [ 82.446564] i40e: Copyright(c) 2013 - 2019 Intel Corporation.
It‘s a known bug on powerDNS and should be fixed in 4.2 release
Still present on 1.2.0-rolling+20190616
Some domains were still working normally while most returned SERVFAIL.