Project

General

Profile

Actions

Bug #10182

closed

BGP learned routes dropping from routing table

Added by Luki TJ almost 5 years ago. Updated almost 5 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
-
Start date:
01/13/2020
Due date:
% Done:

0%

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

Description

Hi,

I'm running pfSense as VPN Head-end with multiple Site-to-Site IPSEC Connections. Most of theses connection are in tunnel mode with dynamic Public IP - Addresses on the remote site. The Routers on the remote Sites are not capable of running routed IPSEC.
One Site-to-Site VPN Connection is configured in VTI Mode and exchanging routes with the remote Site using BGP. This works fine so far. Problem is if a remote Site in Tunnel Mode reconnects with a new Public IP to the VPN Head-End the BGP Routes learned from the VTI IPSEC remote Site gets dropped on the Head-End.

From general Log (in reverse order):

Jan 13 01:03:13 php-fpm 42614 /rc.newipsecdns: The command '/sbin/ifconfig 'ipsec4000' create reqid '4000'' returned exit code '1', the output was 'ifconfig: create: bad value'
Jan 13 01:03:13 check_reload_status Reloading filter
Jan 13 01:03:13 php-fpm 42614 /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.

From zebra log:
Jan 13 01:03:13 zebra 35796 kernel_rtm_ipv4: 172.16.xx.0/20: rtm_write() unexpectedly returned -4 for command RTM_DELETE

After this events the prefix learned from the ebgp peer are removed from the routing table.

zebra deamon (show ip route):

B 172.16.xx.0/20 [20/0] via 172.16.xx.x inactive, 00:56:56

route get 172.16.xx.1
route to: 172.16.xx.1
destination: default
mask: default
gateway: 62.xxx.xxx.117
fib: 0
interface: pppoe1
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1492

To get this prefix back into the routing table, I have to restart the BGPd or zebra deamon.

The Head-End Router is also running ospf for the internal network and hasn't this issue. There is a redistribution configured from ospf into bgp and vise versa.

Actions

Also available in: Atom PDF