Project

General

Profile

Actions

Bug #9668

closed

Running /etc/rc.newipsecdns breaks FRR BGP on VTI interfaces

Added by Chris Linstruth over 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
08/05/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4-p3
Affected Architecture:

Description

Running /etc/rc.newipsecdns breaks FRR BGP on VTI interfaces

Create a simple FRR BGP session across an IPsec VTI

Announce a route to the other side. 172.25.233.0/24 is our subject 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,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 [0/0] via 172.25.228.1, vtnet1, 00:03:07
C>* 10.20.30.0/30 is directly connected, ipsec1000, 00:03:07
C>* 172.25.228.0/24 is directly connected, vtnet1, 00:03:07
B   172.25.233.0/24 [20/0] via 10.20.30.1, ipsec1000, 00:01:37
K>* 172.25.233.0/24 [0/0] via 10.20.30.1, ipsec1000, 00:03:07
C>* 172.25.234.0/24 is directly connected, vtnet0, 00:03:07
C>* 172.25.235.12/31 is directly connected, vtnet2, 00:03:07
BGP table version is 1, local router ID is 172.25.235.12, vrf id 0
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.25.233.0/24  10.20.30.1               0             0 65000 i

Displayed  1 routes and 1 total paths

Run /etc/rc.newipsecdns on the side receiving the route. The routes are still received but are marked inactive and are not installed in the routing table.

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,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 [0/0] via 172.25.228.1, vtnet1, 00:06:55
C>* 10.20.30.0/30 is directly connected, ipsec1000, 00:00:16
C>* 172.25.228.0/24 is directly connected, vtnet1, 00:06:55
K * 172.25.233.0/24 [0/0] via 10.20.30.1 inactive, 00:00:16
B   172.25.233.0/24 [20/0] via 10.20.30.1 inactive, 00:00:16
C>* 172.25.234.0/24 is directly connected, vtnet0, 00:06:55
C>* 172.25.235.12/31 is directly connected, vtnet2, 00:06:55
BGP table version is 1, local router ID is 172.25.235.12, vrf id 0
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.25.233.0/24  10.20.30.1               0             0 65000 i

Displayed  1 routes and 1 total paths

Restarting FRR seems to clear it.

Actions #1

Updated by Chris Linstruth over 2 years ago

Confirmed same behavior on latest 2.5.0 snapshots.

Actions #2

Updated by Jim Pingle over 2 years ago

  • Project changed from pfSense Packages to pfSense
  • Category changed from FRR to IPsec
  • Target version set to 2.5.0

Not an FRR issue. The IPsec interface goes away and comes back, and it never latches back on. FRR needs to be restarted after the IPsec interface comes back, so it's only fixable in base as far as I can see. Unless it's an upstream FRR bug.

Actions #3

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #4

Updated by Jim Pingle over 2 years ago

Second solution is better but still not ideal. Rather than restarting all packages, when IPsec is reloaded via rc.newipsecdns FRR will shut/no shut all VTI interfaces which seems to make it latch back on OK. Also requires FRR 0.6.3 or later.

Actions #5

Updated by Jim Pingle almost 2 years ago

  • Target version changed from 2.5.0 to 2.4.5
Actions #6

Updated by Chris Linstruth almost 2 years ago

In addition to using this patch on a couple of customer sites with success, I just specifically tested this again between 2.4.4-p3 and 2.4.5. The 2.4.4-p3 side exhibits the issue, the 2.4.5 side brings the routes back up on the VTI interface. Looks good.

Actions #7

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF