@michmoor said in BGP convergence with BFD working smoothly with the settings below.:

Thats why i mentioned if pfsense is at the Edge of the network - internet facing and doing OSPF/BGP. In that case you are more than likely in a multi-wan scenrio so in my opinion disabling reply-to is OK.

👍
Agreed.
Sent you a PM, hope you don't mind..

@pwabrat Sorry for the delayed reply,

the issue resolved by Route Redistribution in pfSense Kernel Routes of "Extended_LAN"
cbabfeed-7467-45d0-b3dc-5d8a06e8bdd8-image.png

Thank you for the support.

@marcosm understood. i was just adding unsolicited feedback :)

@dudumiquim

I first reported the issue. There is a redmine.

https://redmine.pfsense.org/issues/14483

.
Has anyone encountered this issue? Is there a way to prevent all BGP sessions from restarting when only one ISP goes down?

Disable Gateway Monitoring Actions for your WAN. That somewhat solves one issue but there is instability with Ipsec and FRR

@michmoor said in Updating to pfSense+ 24.3 breaks routing - kernel routes now gone:

@Kevin-S-Pare

Nothing offensive in the config.
I don't know why you have bgp always-compare-med and bgp-determinstic-med configured at the same time.. If you are using MED to influence outbound routing then you should pick one option.

Based on the fact that you stated traceroutes and pings work out to the internet than we know that routing is good.
I do know there were behavorial changes to pfsense after 22.05 namely state policy changes.

https://www.netgate.com/blog/state-policy-default-change#:~:text=State%20Policy%20Options&text=As%20pfSense%20software%20is%20security,the%20system%20default%20State%20Policy

I have a sneaky suspicion you are running into this. I can see it happening if traffic leaves Upstream1 and comes back on Upstream2.

If i were you i would change to Floating state policy and perform your tests. It really seems you are hitting this behavior change.

Changing to the floating states worked! Thank you!

@michmoor said in FRR 10 coming with script support ?:

Yep yep that's right. Sorry for confusing issues.

Np, we need more people engaged in this, FRR is a great software but it is not working smoothly with pfsense IPsec VTIs.

@Gorf Did you look at your primary config file? I can see some "FRR" info on mine that is still there even though I took the package off..

@michmoor me too.

https://forum.netgate.com/topic/195542/i-from-24-0-3-upgrade-to-24-11-frr-bgp-service-can-t-start/9

it is should add the bgpd_options=" -A 127.0.0.1 -M rpki" in daemons.

@stephenw10 said in I from 24.0.3 upgrade to 24.11 FRR BGP service can't start:

How is it configured? Does it appear correctly in vtysh 'show run'?

no.

show run
Building configuration...

Current configuration:
!
Warning: connecting to mgmtd...success!
Warning: connecting to zebra...success!
Warning: connecting to bgpd...failed!
Warning: connecting to watchfrr...success!
Warning: connecting to bgpd...failed!
Warning: connecting to staticd...success!
Warning: connecting to bgpd...failed!
Warning: connecting to bgpd...failed!
Warning: connecting to bgpd...failed!
frr version 9.1.2
frr defaults traditional
hostname pf
log syslog
service integrated-vtysh-config
!
password
!
ipv6 prefix-list cymru-out-v6 seq 50 deny ::/0 le 128
ipv6 prefix-list ipv6in seq 95 deny fe80::/10 le 128
ipv6 prefix-list ipv6in seq 120 deny 3ffe::/16 le 128
ipv6 prefix-list ipv6in seq 125 deny 2001:db8::/32 le 128
ipv6 prefix-list ipv6in seq 130 deny 2001::/32
ipv6 prefix-list ipv6in seq 135 deny 2001::/32 le 128
ipv6 prefix-list ipv6in seq 140 permit 2002::/16
ipv6 prefix-list ipv6in seq 145 deny 2002::/16 le 128
ipv6 prefix-list ipv6in seq 155 deny fe00::/9 le 128
ipv6 prefix-list ipv6in seq 160 deny ff00::/8 le 128
ipv6 prefix-list ipv6in seq 205 permit 2000::/3 le 48
ipv6 prefix-list ipv6in seq 900 deny ::/0 le 128
ipv6 prefix-list ipv6in seq 999 deny any
ipv6 prefix-list myv6out description my ipv6 out
ipv6 prefix-list myv6out seq 50 permit
ipv6 prefix-list myv6out seq 55 permit
ipv6 prefix-list myv6out seq 60 permit
ipv6 prefix-list myv6out seq 65 permit
ipv6 prefix-list myv6out seq 75 permit
ipv6 prefix-list myv6out seq 80 permit
ipv6 prefix-list myv6out seq 85 permit
ipv6 prefix-list myv6out seq 999 deny any
!
route-map RPKI deny 20
exit
!
route-map RPKI permit 30
set metric 100
exit
!
route-map RPKI permit 50
set metric 0
exit
!
route-map ipv6routein permit 80
match ipv6 address prefix-list ipv6in
exit
!
end

@frijolierthnthou Were you able to solve this issue? I've been dealing with this same exact problem from the past 2 weeks

" stop advertising these routes if the LAN interface goes down as the virtual IPs use 1:1 NAT to route traffic to internal IPs."

If the physical interface goes down then the subnet reachable out of that interface will be withdrawn in route advertisements.
VIPs like loopbacks, are logical and are always UP.

@mcury It seemed like a bug to me as well but this is my first time doing this kind of configuration. I felt like I was going crazy or had done something wrong. Thanks for the response.

@swiss If the log entries do not provide sufficient detail, one thing you can do is run a packet canpture on the VPN interface vor TCP port 179 and use wireshark to show you exactly what is being sent that your side does not like. Then you have something to either accommodate in your configuration or ask the other side to stop doing.

@marcosm Does this fix the issue with selecting the redistribute default always? Whether a default is present or not?

@mcury Yes. It's here.

@michmoor - Yes, disabling the firewall didn't solve the issues, but I don't want a router only without any firewalling capabilities exposed to the public internet.

@yon-0 I'm not sure about CE, but there is FRR 9.1 in the latest PFsense+ 24.3 release. What is your motivation for upgrading from FRR 9.0.2 to 9.1 in pfSense CE 2.7.2?