https://github.com/vyos/vyos-wireguard/commit/7f686a8632ca81ba80813a92ed50fc0c6f1f04d8

https://github.com/vyos/vyos-kernel/commit/49c9ce28558f7d0ffa9f9f7985accf95890a298c

Next rolling will come with preliminary FRR BFD (FRR BFD manual http://docs.frrouting.org/en/latest/bfd.html) support.

I agree with you on many arguments. I just wanted to say my point of view.
There are many differences between vendors: in terminology, in behavior, in technologies. This is a normal situation. The same applying to engineers - we are very diversified, and this is beautiful :).

with my last post in mind, here are the workings of a cisco IOS loopback:

router(config)#int loop 123
router(config-if)#ip addr 1.4.4.1 255.255.255.0
router(config-if)#exit
router(config)#exit

@zsdc Thanks for your comments!

I strongly disagree about mixing dummy/loopback at any of level (CLI or under the hood). Now we have two different types of interfaces: dummy and loopback with the according to names. And they are equal only if you use a dummy for the /32 addresses. In general situation:

• Loopback interface will be used to reach any of the address inside the configured network;
• If the IP address assigned to a dummy interface, the system will respond only to this address, not for the whole network.

Example, to be more precise:

set interfaces loopback lo address 192.168.8.1/24
set interfaces dummy dum1 address 192.168.9.1/24

backported into 1.2.2

https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases#the-dhcpv6-lease-ia-declaration
isc-dhcpd can store IANA_DUID either as octal string (default) or hex, as set by lease-id-format parameter.
python-isc-dhcp-leases currently only supports string type, so it internally parses it into hex. We need to parse it again to add colons to unify with isc-dhcp hex format.
If python-isc-dhcp-leases were improved to add hex type support, we could set lease-id-format to hex and do away with all this parsing.

With https://github.com/vyos/vyos-1x/pull/74 tested working on crux.

Thanks for quick reply! :)

I think it may be a good idea.

+1

When were talking web-interface (not the api itself) it needs to have the functionality to "stage" multiple changes before commit'ing everything in one go, just like in the cli

What will be the desireded CLI syntax?

installation succeeds.

installation succeeds.

fixed by @UnicronNL

tested successfully with VyOS 1.2.0-rolling+201906191432

Verified working on APU2 board and updated documentation https://github.com/vyos/vyos-documentation/commit/a15862af900efd2b766c0d369d0748f2e140dd2f

Should be available in the next rolling release.
https://github.com/vyos/vyos-1x/commit/85c9e0200a4619f0388b7fd7ba9a03f4be933ef5

fixed in https://github.com/vyos/vyos-netplug/tree/equuleus

@runar https://github.com/vyos/vyos-xe-guest-utilities/tree/equuleus should fix that issue. Let me know how it goes.

this is also the case for ping 127.0.0.1 count 100 flood

I had initially not planned to drop the explicit set_value for console speed in migrate/system/3-to-4, as this was legacy for the system@4 component definition; however, (1) the file is soon to be removed when we drop config compatibility pre-6.5, (2) it is now redundant/wrong in the /opt/vyatta/etc/config/config.boot, as pointed out by c-po above. I will remove the add_console call from vyatta-config-migrate/migrate/system/3-to-4.