Bug #9668
closed
Running /etc/rc.newipsecdns breaks FRR BGP on VTI interfaces
100%
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.
Updated by Chris Linstruth over 5 years ago
Confirmed same behavior on latest 2.5.0 snapshots.
Updated by Jim Pingle over 5 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.
Updated by Jim Pingle over 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 15701e03e36051907a23ddbe5ab04f42c94c0944.
Updated by Jim Pingle over 5 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.
Updated by Jim Pingle about 5 years ago
- Target version changed from 2.5.0 to 2.4.5
Updated by Chris Linstruth about 5 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.
Updated by Jim Pingle about 5 years ago
- Status changed from Feedback to Resolved