@thinkl33t can you please also provide a "faulty" /etc/hosts file?

Oy. Turns out that other routers (like those that found in ISP-provided cable modems) can have subtle quirks in their DHCPv6-PD implementations. I've worked around another one.

A quick progress update: I have fixed a bug (that may or may not have been present before) that prevented renew dhcpv6 interface eth3 (or whatever interface) from working outside of an active configuration session. I imagine most uses of dhcp lease renewal would occur in a normal router login session.

Maybe if hostname is empty, we can prepend the mac address to the fqdn which will be stored in /etc/hosts

Something seems to be totally off with set system domain-name and set system domain-search domain

1.2-RC5 already supports this (and I assume newer but I can't test it with my motherboard for other reasons-T1066). I am with BT (UK) and it works great (see my config below). RC5 does however still contain T1065 which is related to this but has been fixed in a later release candidate (RC11 I think).

 ethernet eth3 {
     address 192.168.5.1/24
     duplex auto
     mtu 1508
     pppoe 0 {
         default-route auto
         mtu 1500
         name-server none
         password xxxxxxxxx
         user-id [email protected]
     }
     smp-affinity auto
[edit]
# set interfaces ethernet eth3 pppoe 0 mtu
Possible completions:
   <68-1500>    Maximum Transmission Unit (MTU) in bytes
   1500

Well, I've been developing it against the 1.2.0 branch. It might work back-ported to 1.1.8, but that's not my focus.

@fromport how to reproduce? Is this possible with VMWare ESXi? If now, which virtualisation tool to use for testing?

Your given example can thus be enabled via set service dns forwarding domain microsoft.com server 127.0.0.1

Okay, a wildcard as in * does not work and is not supported by our underlying pdns-recursor.

configure -h is a bit "cryptic" (imo)
It doesn't show the defaults, so i ran a regular configure and then editted the build/build-config.json

@oliveriandrea can you please retest with latest rolling release if it already works?

https://github.com/vyos/vyos-wireguard/commit/95f110c1f1693c7e70b78a54459f6aeefde42772

You rock Geoff!

Hey! Sorry I was out for a bit. But I'm back now. Time to catch up.

Hi adestis, what you descripe is possible to do today with the help of a shellscript and the crontab, if you are interested i could help you create a script that does this for you, the one drawback is that the failover-time is in the ballpark of minutes, and the routes are not present in the configuration... Also, cron fills the log with messages every time it executed

currently the command run under the hood is

cat $(printf "%s\n" /var/log/messages* | sort -nr) | grep -e pluto -e xl2tpd -e pptpd -e ppp

Please retest with a new rolling release tomorrow

This bug can't be reproduced in 1.2.0-LTS and 1.2.0-rolling+201902080337, so seems that it was fixed in some of previous releases. Closing ticket.
Feel free to reopen it if the the same behavior will be spotted in one of current releases.

Patch does not apply cleanly, need to backport it but will do

@c-po can you probably merge and close this one

Can you retest on the latest rolling and see if that repeats?

Bug confirmed. The problem is in FRRouting CLI (FRRouting 7.1-dev).
Will see what we can do with this.

Hello, @MrXermon!
We can't reproduce this bug. Maybe, there are some other errors, which can affect route-maps?
If you have the old configuration, can you check update procedure with an update to 1.2.0-LTS and current rolling?

Hello, @rizkidtn!
Is any problems still exist with your configuration or we can close this issue?

Hello, @dongjunbo!
Can you check behavior with new versions? If the problem still exist show us an example of such big configuration, or at least count of objects and their types in this config.

Hello, @bjtangseng!
Can you recheck this with fresh versions? Seems that in 1.2.0-LTS and rolling everything is OK. Also, if there is no VPN logs at all (for example, VPN is not configured), you can see output like in first message and then this will be not a issue.

Hello, @TrueTechy!
As I understand, this situation can exist only if interface is in down state? Can you check this behavior with fresh VyOS version?

The system is a Supermicro SYS-5018D-FN8T with 2 x 240G Intel SSDs and 16G of RAM.

Can you describe the system and disks involved?

There must be something missing in the initrd image or something like that.

No, neither fixed it.

@jmlccdmd See the fix in T1120. Does changing the rootdelay to something longer fix it for you? Or turning off acpi as suggested?

I booted sys-rescue-cd 6.0 in EFI mode from usb stick.

Hi Syncer,

I would consider adding EVPN support via FRR as soon as kernel support for the inter working between vxlan and bridge interfaces is more fleshed out. Maybe I should create a new task for that.