User Details
- User Since
- Nov 14 2018, 3:43 PM (284 w, 6 h)
Aug 14 2020
Just an update on this... I _had_ two systems with this problem, but have found a possible workaround?
Apr 16 2020
Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.
Sep 27 2019
Yes, this _was_ still a problem but the workaround solves the issue for
me. I've been able to upgrade the 1.1.8 instances to 1.2.3 after adding
this extra interface route.
Jun 19 2019
Jan 28 2019
Unfortunately I still see the problem when the blackhole routes are set with a distance of 240 and the 0.0.0.0 route is distance 1.
Jan 24 2019
The problem discussed here sounds remarkably similar to what I'm seeing: https://github.com/FRRouting/frr/issues/2230
I've tried several variations on the VRRP configuration, and it doesn't seem to make any difference. As far as I can tell, nothing is wrong with VRRP. It is only relevant as a source for change in the routing table. I can demonstrate the problem on a single instance with no VRRP.
Jan 17 2019
The abnormal part of our setup might be that we have blackhole routes in
place to prevent any accidental leakage of private IP addresses through a
public class C network. The configurations posted above are contrived -
purely to demonstrate the problem, but it does reliably demonstrate the
regression from 1.1.8 to 1.2.0.
Jan 6 2019
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.
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.
Jan 4 2019
Dec 11 2018
One fairly simple workaround is to add a couple lines to /config/scripts/vyatta-postconfig-bootup.script
Nov 20 2018
Unfortunately this is still not enabled in 1.2.0-rc8.