@c-po

So VyOS is heavily dependant on this one, no need to remove.

This is not just wrong, but, as anyone who tried to go beyond the native CLI on EdgeOS can attest, almost slanderous. ;)
VyOS uses real coreutils (ip-utils-ng etc.) for those ones. Some VyOS packages list busybox but I believe it's a legacy. The only thing that probably truly depends on it is initramfs-tools, but with image upgrades, I think having initramfs-tools in VyOS is an artifact that is not needed.

I think it's better to assign @dmbaturin b/c he build the used pdns package located at http://dev.packages.vyos.net/repositories/current/debian/pool/main/p/pdns-recursor/ and I have no access to this location.

Latest Firmware can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/

@deafen can you please retest with latest VyOS 1.2.0 rolling? We have the latest 4.18.11 Kernel now.

That would be very nice to be able to use.
I just tested the rolling image and when i try to start bgpd with this module loaded it cannot find it.

https://www.syslinux.org/wiki/index.php?title=Isohybrid

This will be a killer feature. I wanted to spin a Atom C3000 board with VyOS 1.2 but that board comes with UEFI only so right now, no VyOS on this one. Debian Jessie CD on the other hand boots fine (build with UEFI support)

Will this make it into 1.2 before the freeze?

Oops. I forgot to add the actual package to our repos. Should be fixed now.

I've tested the default configuration in 1.1.8, and it looks like with preempt-delay not set it was also 0. Not sure where 300 came from.

I do agree that there should be a pre-canned way to do this.

@rps I think this is a bug, because this behavior is not by design - it just to happen ;-) . You may call i a design bug.

Does your box have a mellanox card? Is there any virtualization involved? Can you check the driver revision in non-/working state in the kernel? Use ethtool to find out the driver servicing your interface and then modinfo the kernel driver name to get its version.

I think the radvd should be made vrrp3 aware. In Juniper this looks like protocols router-advertisement interface <val> virtual-router-only: Send advertisemnets only for vrrp-inet6-group.

So I'm not sure this is a bug as much as a feature request. You CAN in fact accomplish what you're trying to do in VyOS 1.2 albeit manually using a transition script.

UEFI is not difficult.

Most of current distros can boot on legacy systems (e.g. with BIOS) and also UEFI
since many new server platforms switched to uefi we need to cover that.
Most of them can be switched from UEFI to legacy BIOS, however there are devices that not support such change

What happens on Hypervisors not supporting UEFI or older Hardware Platforms without UEFI?

@rps seems to be the case. sorry for the noise

In T840#19823, @c-po wrote:

arp_proxy setting was introduced in an ancient commit https://github.com/vyos/vyatta-cfg-system/commit/496526b572ca83308a858b2ec4771d2f05f4970c

arp_proxy setting was introduced in an ancient commit https://github.com/vyos/vyatta-cfg-system/commit/496526b572ca83308a858b2ec4771d2f05f4970c

This will need to be implemented using transition scripts in keepalived to enable and disable radvd for the prefix.

@dmbaturin I actually comitted the fix yesterday morning. Somehow Phabricator only shows the corresponding commits when logged in.

No problem, I appreciate the help :)

Yes, quite an embarassing mistake. I'm working on it.

Correction on Version: VyOS 1.2.0-rolling+201809192147

Can you provide the output of tcpdump -eni <sub-interface> 'arp' (e.g. eth1.2001) from a root shell on VyOS when this is happening? I would like to see the capture with MAC addresses included for the specific sub-interface involved (text rather than screenshot please).

Sure thing, I'll leave the bug ticket open.

Please find some older rolling releases here:

I've tried the oldest build, but it still has the issue. Is there any way to extract an image from another router? The timing does line up for it being a driver issue, I'm going to see if swapping to a different NIC helps next time I drive over, debugging remotely atm, so no rebooting allowed for a few days.

Hmm, sorry I don't have any windows machine, actually since 1996 I don't have any windows. So I can't test that. I tested with the build from 17th and also with your nat rules, still can't reproduce your issue you seeing. You can check on https://downloads.vyos.io/?dir=rolling/current/amd64 the isos, it goes back till Sept 5th. Or the other option is ti install just a different kernel.
If you need help with installing your own kernel, let me know.

Does anyone know where I can find a build on the old kernel? I deleted mine swapping images at some point. Starting to think that might be when it started.

It's what Windows does when you first assign an IP address - checks if it's in use and refuses to use it if it is. Linux boxes don't so they have working IPv4.

I tested your sniplet and can't reproduce your issue.
Why is your arp requestor a broadcast address?

IPv6 is all on different subnets, and I actually have working IPv6 networking while IPv4 is broken. v6 uses NDP instead of ARP so shouldn't be able to cause this.

I haven't tested this to verify but some initial thoughts:

I found this to occur sometimes when you configure the same subnet on multiple interfaces. The IPv4 seems to be OK in your config but the IPv6 is hidden and missing the last digit as well.
Also maybe you have created some strange behaving rule in NAT, if you have NAT configured could you post this config, or run through it yourself?

Config's pretty huge, here's the LAN interface. Need to go through and sanitize the rest. No proxy arp or similar anywhere, "arp" doesn't appear in the config at all. Issue occurs on all vlans.

Can you share your config please.

See https://phabricator.vyos.net/rVYOSONEX0ac5a4f94a8a4e84ed73c2288bcb9a4c77b9b695

Invalid SNMP addresses must be filtered, else the service won't start with this error message:

Sep 16 20:32:58 LR1 snmpd[4848]: Error opening specified endpoint "udp:192.168.1.1:161"
Sep 16 20:32:58 LR1 snmpd[4848]: Server Exiting with code 1
Sep 16 20:32:58 LR1 snmpd[4845]: Starting SNMP services::
Sep 16 20:32:58 LR1 systemd[1]: snmpd.service: control process exited, code=exited status=1
Sep 16 20:32:58 LR1 systemd[1]: Failed to start LSB: SNMP agents.
Sep 16 20:32:58 LR1 systemd[1]: Unit snmpd.service entered failed state.

I can confirm L2TP/IPSec working with Windows 10 (1803) and Apple iOS 11.4.1 together with RADIUS auth backend.

I've fixed it by adjusting the syntax for new StrongSWAN. The new way to do it is arguably better than it used to be, but I still wonder why the old syntax had to break. The fix is in 0.12.45+vyos2+current2 and should be in tomorrow's nightly build.

VyOS Kernel was rebuild with retpoline enabled https://phabricator.vyos.net/T819. As Kernel modules sometimes depend heavily on the unterlaying ABI (Application Binary Interface) this will break if the module is not rebuild.

@msbone used the version I mentioned and confirmed functionality. We have to find out what's wrong with the kernel build https://ci.vyos.net/job/vyos-kernel/142/

Last clean version is: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201809101921-amd64.iso

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201809120337-amd64.iso seems to be a non-functional build. When I boot it from scratch it drops me only into initramfs. @msbone did an upgrade on hist system from 1.2.0-rolling+201808171757. I advised him to the use the is o from Sept. 10 which I tested for it's functionality. I see if I can find out what happened with the latest build. IT' a kernel module load issue I can reproduce already when booting the iso.

4954.412990] wireguard: loading module not compiled with retpoline compiler.

This is whats happening when we add L2TP/vpn configurtion and do a commit:

Fixed by installing dependency.