Page MenuHomeVyOS Platform

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

Description

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.

vyos@FW# show interfaces ethernet eth0
 address 169.254.123.9/30
 duplex auto
 hw-id 52:54:00:42:1a:6f
 smp-affinity auto
 speed auto

vyos@FW# show interfaces ethernet eth5
 address 192.168.10.2/29
 duplex auto
 hw-id 52:54:00:33:0e:ca
 smp-affinity auto
 speed auto

vyos@FW# show high-availability vrrp group eth0-200 
 advertise-interval 1
 authentication {
     password apaswd
     type ah
 }
 interface eth0
 virtual-address 192.168.22.12/24
 vrid 200

vyos@FW# show protocols static route 0.0.0.0/0 
 next-hop 192.168.22.1 {
 }
vyos@FW# show protocols static route 192.168.0.0/16 
 next-hop 192.168.10.4 {
 }

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

S>  0.0.0.0/0 [1/0] via 192.168.22.1 (recursive), 00:00:40
  *                   via 192.168.10.4, eth5, 00:00:40
C>* 192.168.22.0/24 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.

vyos@FW# delete protocols static route 0.0.0.0/0 
[edit]
vyos@FW# commit
[edit]
vyos@FW# set protocols static route 0.0.0.0/0 next-hop 192.168.22.1
[edit]
vyos@FW# compare 
[edit protocols static]
+route 0.0.0.0/0 {
+    next-hop 192.168.22.1 {
+    }
+}
[edit]
vyos@FW# commit

vyos@FW:~$ show ip route 
S>* 0.0.0.0/0 [1/0] via 192.168.22.1, 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.

Details

Difficulty level
Unknown (require assessment)
Version
1.2.1
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).