Page MenuHomeVyOS Platform

VRRP Starts After FRR, Creating Inconsistent Routes -
Closed, ResolvedPublicBUG


I found this problem in 1.2.1. Problem did not occur in 1.1.8.

I'm sure it can happen in other situations, but i found it because the VIP address for VRRP is not within the same subnet as my interfaces.

[email protected]# show interfaces ethernet eth0
 duplex auto
 hw-id 52:54:00:42:1a:6f
 smp-affinity auto
 speed auto

[email protected]# show interfaces ethernet eth5
 duplex auto
 hw-id 52:54:00:33:0e:ca
 smp-affinity auto
 speed auto

[email protected]# show high-availability vrrp group eth0-200 
 advertise-interval 1
 authentication {
     password apaswd
     type ah
 interface eth0
 vrid 200

[email protected]# show protocols static route 
 next-hop {
[email protected]# show protocols static route 
 next-hop {

When the firewall starts, all the interfaces come up and routes are applied. So is pointed to
Then VRRP starts and creates the interface, so logically the route to is directly connected via eth0. But the route doesn't update to reflect that. Instead we get a recursive default route.

S> [1/0] via (recursive), 00:00:40
  *                   via, eth5, 00:00:40
C>* is directly connected, eth0, 00:00:32

If i remove the greater prefix and reboot it works fine (of course) and if i delete and re-add the default route after the firewall has booted it works fine. But that isn't much of a permanent fix.

[email protected]# delete protocols static route 
[email protected]# commit
[email protected]# set protocols static route next-hop
[email protected]# compare 
[edit protocols static]
+route {
+    next-hop {
+    }
[email protected]# commit

[email protected]:~$ show ip route 
S>* [1/0] via, eth0, 00:00:39

Could potentially be a problem when VRRP transitions from one firewall to another too.

We need to either make sure keepalived starts before static routes are applied, or FRR needs to be able to see when static routes change and update as needed.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Issues in third-party code
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

zsdc changed the task status from Open to Confirmed.Aug 21 2019, 4:27 PM
zsdc added a subscriber: zsdc.

The problem is in FRRouting itself. It can be reproduced in 7.0.1-20190820-04-g047efd6, 7.1-20190820-02-g1ed807a. But in 7.2-dev-20190820-03-g9316c82 everything work as expected.
We should try to find which changes fixed this problem and reapply it to one of the current stable FRR versions or wait for the next stable.

syncer triaged this task as Normal priority.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.

This appears to be fixed in 1.2.4 EPA1.

It definitely seems related to the FRR commit referenced by @Viacheslav

I'll do more testing tomorrow with the current EPA.

dmbaturin changed Why the issue appeared? from Will be filled on close to Issues in third-party code.
dmbaturin set Is it a breaking change? to Perfectly compatible.
dmbaturin set Issue type to Bug (incorrect behavior).