Project

General

Profile

Bug #9668

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

Added by Chris Linstruth 4 months ago. Updated 4 months 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 4 months 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 4 months ago

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

Revision 64c18f53 (diff)
Added by Jim Pingle 2 months 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.

(cherry picked from commit 15701e03e36051907a23ddbe5ab04f42c94c0944)

Revision 7ba8d654 (diff)
Added by Jim Pingle 2 months ago

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

(cherry picked from commit a264f870479c36ac1599b936bbdd547f0f8a99ec)

History

#1 Updated by Chris Linstruth 4 months ago

Confirmed same behavior on latest 2.5.0 snapshots.

#2 Updated by Jim Pingle 4 months 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 4 months ago

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

#4 Updated by Jim Pingle 4 months 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