can reproduce ob EPA3:

Hold back on this for a moment. Might be a hardware error since behaviour under rc11 is strange as well.

Same issue with 1.2.0-rolling+201901070337 as well

look at T1181

There are no disadvantages in doing so. Any contribution is welcome.

Absolutely -- I'll test it next week!

wireguard identifies peers on their key, improve the command for sh int wireguard wg01 peers etc. so that the peer name from the config is visible as well.

@ekim https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address the dhcp issue, can you please test? I only tested on VMs yet.

I just tested this on 1.2.0-EPA3 and it works here. Please re-test with EPA3.

All right @ekim I have that feature working in an experimental package. If you want to test it you can build it from here:
https://github.com/hagbard-01/vyos-netplug via dpkg-buildpackage -b -tc -uc -us and install it on any rolling iso. I used the latest for my tests, but it should work on older ones too. It will still take a little time to have that pushed into the normal build process, since it requires some integration work.

@ekim Yeah, that is a known issue I was looking into a while ago already. disable/enable in eth interfaces should now work in the latest rolling, the plug-in and unplug will still need a little. I'll keep this task here open for it.

That’s correct, when deleting disable from the interface config. Additionally, It doesn’t seem like dhclient gets triggered when a physical interface is unplugged then plugged back into that same port, but should receive a new address as a different dhcp serving a different dinner is available

@ekim I think I found it. When I put the interface into disabled mode and then delete disabled, the dhcp client isn't started anymore if the address is supposed to be received via dhcp, correct?

Yes, no issues on either DHCP server. All other clients on the network perform as expected.

Have you checked on the server DHCP server side for issues?

Superseded by T1178

Seems to be a problem with just that build. I'll install a newer rolling when I get a chance and see if that corrects it.

Edit... actually I can't update anything:

With VyOS as the edge:

Next rolling will have the fix applied:
https://github.com/vyos/vyos-1x/commit/76fe726e3530158ee175d34b9cb74209ccca2345

From the 1.2.0 instance (10.240.4.31) I'm able to ping the 1.1.8 (10.240.4.32) instance immediately after adding the address, but cannot ping out to the internet until after a reboot.

Do you mean the 31 and 32 also couldn’t ping eachother?

This won't help in production case, as that uses a /30 network with only 2 possible addresses. One is the floating VRRP address and the other is the destination for the static route.

I see in the config that you do not have an interface IP on the VRRP members.
This works in 1.1.8 most of the time. But can you test if 1.2.0 works with those added. The hello source address is not needed then and the chances are the kernel wil load the connected route this way.

This is probably a duplicate of T1120, which should be fixed now.

RC11 is getting old, please retry with latest rolling: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901040337-amd64.iso

We have been waiting for 1.2 to roll for a long time. We have some running in Vyatta (Lenny), some on Vyatta (Squeeze), some on Vyos Hydrogen, and now a summer build from '18, plus RC7 & RC11. Trying to get packages to run the same way across all so change management is consistent has been fun.

Thanks for the update. May I ask which distro?

since we have the need to add some packages but not upgrade or interfere with what you have done, this does the trick.

we write a lot of packages for ourselves that are in our own repo. we layer them on top of your distro. someone probably issued a global upgrade, rather than for just our stuff.

digging a little deeper, all installations having this issue also have had the package xl2tpd replaced. you ship with 1.3.6+dfsg-2-vyos0. somehow it got replaced with 1.3.8+dfsg-1~bpo8+1

Solved by disabling engine ID when the version is 9, not sure if this is enough but on my router it works.

Until version 1.7.0 it was possible to (mistakenly) configure the
NetFlow v9 SourceID field/IPFIX Observation Domain ID with the old
NetFlow v5 jargon, ie. '1:1'. This is now threated as invalid and
a positive 32-bit number, ie. '100000', is expected. If exporting
NetFlow v5, nothing changed: the Engine ID/Engine Type input, ie.
'1:1', is still valid and expected.

This behavior was already present in the old Quagga implementation in Vyos 1.1.7.
As a workaround we always shutdown the peers when doing a planned reboot.

IPv6 seems to have the same issue. Peer shutdown in configuration, reboot, results below:

I've made some tests...
I have build a lab with next configuration:

vyos@vyos:~$ show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route

Can you share your configuration please? I use rc11, too as l2tp/ipsec access concentrator and everything is fine here.

I have a look into it but I doubt that this will be an issue. Charon is usually taking care of the routes if an IPSec tunnel has been established and you have a valid SA. The redirects from the settings above shouldn't interferer with it at all. If a mode tunnel is being used with public IPs, the packets will leave the system unencrypted anyway as long as no valid SA exists, so they will go the default route. I'll check if the perl script is actually changing these settings, that would be not so nice since you will face a race condition which would explain why I can't reproduce your issue, since I never tested with a working IPSec tunnel :). I'm having the flu right now, so please give me a few days to have a look.

I found. This is VPN settings.
Based on information from Linux IP stack flow diagrams, IPSec policy applying after route decision, and ICMP redirects doing before this. So we can't leave send_redirects=1 on interface, where we receive unencrypted traffic for IPSec.
But, we can:

1. Check for firewall send-redirects 'enable' and prevent to commiting vpn ipsec options, when send_redirects is enabled.
2. Disable send_redirects only on interfaces, where we expect incoming unencrypted IPSec traffic.

I'm not sure, what is better.

Can you check ig you have any postscripts running or any manual sysctl variable set? Or do you experience that on new insatllations?