8472 is the default port used by the Kernel, and thus fully backwards compatible with older installations. 4789 is the IANA assigned value which you could configure using remote-port.

IMHO the only reasonable solution would be to git bisect the Kernel and find the commit which introduced the problem.

Just commenting, UEFI boot is now working (tested in hyper-v gen2 VM with 1.2 20190520). Personally, I care from a performance perspective: hyper-v gen2 network adapters greatly outperform the "legacy network adapter" available to gen1, which is a full software emulated NIC.

I'll check this tonight.

the commit success now in the latest rolling.

@sentania Can you please test with the latest rolling, the issue should have been fixed now.

I have just tested Kernel 5.1.2 which has a newer igb driver (version: 5.6.0-k) but still no go. Not really sure where to go next.

I'm noticing this issue while attempting a pxe boot to live install on the same chipset but for a quotom unit. Most data that covers this problem seems to point to the kernel being the culprit as previously indicated.

Confirmed fixed in vyos-1.2.0-rolling+201905210337

Confirmed fixed in vyos-1.2.0-rolling+201905210337

@rob Fix will be in next rolling release

https://github.com/vyos/vyatta-openvpn/commit/cdd5d072f5a722156a06e600b5742e8bc3854b55

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

I can't see 'unknown command' lines in log anymore, on VyOS 1.2.0-rolling"201905180337.

@dmbaturin merge if it's not already there

Build Docker container two times on different machines (Linux host and macOS host) ... no problems detected. closing this.

Can't reproduce the issue using commit 217aa6afaeb of vyos-build repo

is that still an issue in the latest rolling image?

@sentania http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.19.1+vyos2+current9_all.deb or next rolling release will have it patched. It was just not implemented in the backend, so the parameter was never read from the cli.

looks like even if not listed it can be set, but not applied via cli. also need to test if it works.

Looks like the 7.1-dev frr branch is eiter not up to date or the frr documentation isn't updated.

bug confirmed.

The solution was tested and fully worked.

Awesome, thx for letting me know.

@hagbard, everything works fine now. Thank you!

just thought I'd ask... did this make it into 1.2 yet? 1.2.1?

set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 distance '100'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 next-hop-interface 'eth3'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 distance '200'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 next-hop-interface 'eth2'

I see, thx.

This is not the same.

set protocols static table 100 interface-route 10.100.100.0/24 next-hop-interface eth1

generate:

test-06# show running-config staticd 
Building configuration...

Hi, @rob
It works! Thanks a lot. This case can be closed now.

@zsdc Is that even require in table, doesn't the below work?

https://github.com/vyos/vyatta-cfg-quagga/commit/468e19f564023771d774ee32ccffc4ccffed897c should fix the discovered issue. It can be imported to table as well.

I found an issue which prevents the implementation:

@hagbard solution works. Please, add it also to the stable branch and to the set protocols static table section.

can you describe your problem a little bit more.
I do something like this in some cases maybe it match on your use case:

Test with latest vyos-1.2.0-rolling+201905120337-amd64.iso success.
Thank you.

Ok,
the first step is done

Unfortunately a build of vyatta-webproxy was not triggered on push to GitHub. Next rolling will have it!

Test with 1.2.0-rolling+201905110337

@rodge.liu I think that might be the issue. I have seen similar behavior on DHCP set interface when the DHCP take quite some time to reply.

successfully tested on:
Version: VyOS 1.2.0-rolling+201905081347
Built by: [email protected]
Built on: Wed 08 May 2019 13:47 UTC
Build ID: 7093c43d-6ea7-45c9-a7c5-3fdf07c0ebc7

Please test with next rolling release if this problem is fixed so we can close this issue if this is ok for you. Whitlist issues should be separate ones. Thanks for assistance.

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.

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.