Project

General

Profile

Bug #9668

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

Added by Chris Linstruth about 1 month ago. Updated about 1 month ago.

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

100%

Estimated time:
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.

Associated revisions

Revision 15701e03 (diff)
Added by Jim Pingle about 1 month ago

Restart packages at the end of rc.newipsecdns. Fixes #9668

Not an ideal solution but it does ensure that FRR routes function after
an IPsec event.

Revision a264f870 (diff)
Added by Jim Pingle about 1 month ago

Instead of restarting pkgs, add an IPsec reload hook they can use instead. Fixes #9668

History

#1 Updated by Chris Linstruth about 1 month ago

Confirmed same behavior on latest 2.5.0 snapshots.

#2 Updated by Jim Pingle about 1 month 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.

#3 Updated by Jim Pingle about 1 month ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Jim Pingle about 1 month 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.

Also available in: Atom PDF