@UnicornNL, Used rufus, and unetbootin from windows 10

The driver for the Intel X520-DA in Vyos 1.1.8 is version 3.15.1. Intel's latest driver version is 5.5.1

Need to use win32diskimager and should work just fine
https://sourceforge.net/projects/win32diskimager/

I have had this exact problem running windows 10 and creating the image with Rufus 3.3. The workaround I used was to install 1.1.8 and then installing the latest image within the os using the iso.

@commo How did you prepare the usb drive?
On which os, and what tools did you use?

This was fixed some time ago.
https://github.com/vyos/vyos-strongswan/commit/2cfa2c5f85babbfae11898888d6e8c7ca99cdeb5#diff-ab17f7fac35ebad14feb31b720eba1b0R173

It's quite a shame that iproute2 can't do it on its own. I've added a workaround.

Indeed, I missed one command when adjusting the script for the new syntax!

Yeah, missing sudo. Thanks for finding it!

This is a purely cosmetic issue, but I agree, an annoying one, especially with lots of duplicate messages. I've reported the issue to FRR.

I think Intel now even recommends using Brocade 1gigabit modules for SFP+ modules when needing to down grade a 10G port to gigabit now, since they no longer manufacture 1G modules, so this is bound to bite people. Perhaps default to adding the allow_unsupported_sfp=1 for the various intel drivers perhaps?

Would it be possible to ask also for IPv6 support?

@vtsingaras I see it is merged in upstream, try to merge in vyos asap.

I believe we have similar issue on the Intel i40e. FYI

Here is the dmesg | grep ixgbe output on startup:

@c-po We've several servers with VyOS 1.2.x and IPv6 BGP session. We've long wanted to control the BGP IPv6 sessions via SNMP, but now only IPv4 is possible. Write me to Slack if I can somehow help with writing this functionality.

It's a classic issue. You need to create rules with "exclude" option for such networks.

With the new BGP syntax where IPv4 is in its own address family just like IPv6, the no default ipv4-unicast option should work as expected. See T849.

I guess this is best done along with openvpn scripts rewrite.

For mellanox etc. I'm just using the kernel source package.

We did some tests with RC5. Sometimes the complet configuration gets loaded after a reboot, but most of the time not. Maybe a timing issue?

This patch fixes in my case crashes that would result from big NFLOG packets (32K in my case)

Yes! Radius auth is working nicely, now the cli config part needs to be finished.

Same behaviour also with this comand:

I made a few further tests. These errors occure in log every 5min. That's the routing-table refresh intervall of the network monitoring system. I deactivated encryption of snmp and captured the traffic in these moments. Now I can reproduce this by a snmpwalk to OID .iso.org.dod.internet.mgmt.mib-2.ip.ipRouteTable.ipRouteEntry.ipRouteDest (.1.3.6.1.2.1.4.21.1.1)

Sorry for the mixup of the kernel version numbers in my original post. I corrected it. But good you can reproduce the issue.

In T935#24147, @Line2 wrote:

tested again on VyOS 1.2.0-rc5 (kernel 4.14.75), same packetloss.

works as expected on 1.2.0-rc4

Didn't test it with 1.2 only with 1.1.8

DNS issue, not wireguard related. Using the endpoint IPs is working correctly.

So far so good. Traffic works when using endpoint IPs a instead of the name, still looking into that, but in general no problem with wireguard found.

Tried editing our config. Could not find a force gateway option in the load balance sections. Can you confirm where the force gateway option would be?

tested again on VyOS 1.2.0-rc5 (kernel 4.14.75), same packetloss.