<dmbaturin> Hi! If you are ready to help with testing it, I'll be happy to make a CLI.
<dmbaturin> I think it should be orthogonal with all other features indeed, so a perfec candidate for RC3.

please confirm the current state of this task

moved to frr in 1.2

@jwhipple can you confirm that issue exists on 1.2?

FRR is now included in 1.2.0rc but no large communities. It would be very nice to have support for it cause people like me got only 32bit ASN.....

@syncer @aldoleiva1 I have built binaries and installation scripts for Debian(8,8) and Ubuntu(14.04,16.04,18.04).
If I will have a build node VM or docker container I believe I can at-least make a binary package(tar) of Squid.
I have also written a nice helper and library https://github.com/elico/drbl-peer/ which can be used as an acl mechanism for Squid.
The only missing part is a helper that has a list of domains from a hosts style file like SquidGuard and can block or allow a specific white or blacklist with an auto dynamic reload option.

Wiki instructions for system package settings now seem to be gone.

I am running VyOS 1.2.0-rc2. A restatement of the problem, which can be reproduced on any system. At least one of these files needs to exist for the kernel module to load:

I don't think we should support restricted boot. As per MS's own specification, all x86 boards should allow the user to disable it, and to my knowledge, they all do.

This bug is in effect also without using dynamic routing.

If you disable the StrongSwan farp module, it appears to resolve the problem:

Sorry for spamming this thread, but I found this bug report that might be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1488421

I've tested the above setup with 1.2.0-rc1 and the problem persists.

Oddly, I couldn't reproduce the issue on my latest image. Perhaps there is more to it. We are preparing a release candidate now, please re-test when it's out.

I've also managed to test ipsec/vti today by setting up a test environment like this:

I checked issue with and without IPSEC/vti.
Without vti arp worked fine. Then I applied config with vti router began to respond for all arp requests with all own MACs.

I also have ipsec/vti.

@ThomasB we have similar issue, my point is may you can spin up an isolated copy with similar config in your env
we don't have issues on 6.5 so i wondering if that is env specific (just pointing with the finger to the sky)

@syncer I would be happy to give it a try, even if it's a little risky for me. My router VM is running on an ESXi server, and when the ARP issue strikes I loose direct access to ESXi and have to go through the tunnel. That basically means that if the router VM breaks, I won't be able to access anything on that server. The server is located in a datacenter 1.500 km away.

@ThomasB can you just test config without vti/ipsec in place?

Just a though... I noticed that vlesk has IPSEC tunnels over vti in his config, and so do I. I remember previous 1.2.0-rolling builds had issues with IPSEC/vti where the router wouldn't respond to ARP because of some routing table mumbo-jumbo I don't quite understand. This has since been worked-around, because it can't really be fixed at the moment.

So not specific to kernel version

I rechecked the solarflare card - issue still exists. Didn't catch it last time because my config got a little messed up with all the image swapping.

In T852#20403, @ThomasB wrote:

I can confirm that the test image works for me as well.

THX for testing. I'm currently buiulding a second image for testing and will keep you updated! The second one ships Linux Kernel 4.19-rc6 so we can see if the issue still exists or is gone!

I can confirm that the test image works for me as well.

I checked image vyos-1.2.0-rolling+201810071039-amd64.iso kernel 4.14.65 work fine. Router respond only for own requests.

I’ll see if I can test it tonight (CET) and report back.

Okay, can you please test if the issue exists with the following image:

Anyone also tried loading some up2date firmware from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ ?

We can switch back to 4.14. for testing, yes

@dmbaturin @c-po i will suspect new kernel
can we build an image with previous to 4.18 kernel to confirm?

I have the exact same problem since updating from 1.2.0-rolling+201805280337 to 1.2.0-rolling+201810060337. My VyOS VM is running on ESXi 6.5 with two virtual VMXNET3 interfaces. The (shared) physical interface is an Intel i210 Gigabit interface.

Bug confirmed.

Thanks a lot. I tried to reproduce it on various machines without success, which leads me to the assumption that the issue might be the NIC firmware. I just had e1000 to test with, but that's all working fine.
Can you please check the following:

I prepared config and pcap file. I removed e100 NIC from bridge, however problem present. Windows can't get address nor static neither dynamic. Windows determined it as address conflict.

May be duplicate of T483

Can you please share the output of the command 'show conf comm'. thx.

I have same issue with bridge, wich consist of Intel NICs (drivers igb and e100). Router responding for all arp requests.
My NICs are: Intel Corporation 82575GB Gigabit Network Connection (rev 02) and Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)

Ok, I'm going to build the official driver for the 4.18.11 kernel then.

Finally got back up here to test. Swapped out the Mellanox NIC with a Solarflare card on latest, works. 201807292210 image with Mellanox card, works. Latest image and different Mellanox card, broken. Definitely looks like a driver issue, the new kernel seems to have a far older version. No virtualization involved.

It all works now, right? Closing then.