frr will not bring up BGP session?
-
Hello,
I am running pfsense 2.4.5 and FRR 0.6.7_3.
I have an exceptionally rudimentary BGP configuration setup on two nodes (identical pfsense + frr versions) and cannot get the BGP sessions to establish, or seemingly even attempt to establish (tcpdumping port 179 on both pfsense machines).
I have disabled authentication on both sides as well, just to make the configuration even "cleaner" (to get it up and going) but this seems to make no difference.
zebra.conf:
##################### DO NOT EDIT THIS FILE! ###################### ################################################################### # This file was created by an automatic configuration generator. # # The contents of this file will be overwritten without warning! # ################################################################### password [redacted] log syslog
bgpd.conf
##################### DO NOT EDIT THIS FILE! ###################### ################################################################### # This file was created by an automatic configuration generator. # # The contents of this file will be overwritten without warning! # ################################################################### password [redacated] log syslog # BGP Config router bgp 64597 bgp log-neighbor-changes address-family ipv4 unicast redistribute connected redistribute static redistribute kernel exit-address-family # BGP Neighbors neighbor 10.254.1.100 remote-as 64597 neighbor 10.254.1.100 description BGP with pfSense02-x address-family ipv4 unicast neighbor 10.254.1.100 activate no neighbor 10.254.1.100 send-community exit-address-family
FRR status ->
BGP summary:pfSense01.x.internal> show bgp summary IPv4 Unicast Summary: BGP router identifier 172.19.0.1, local AS number 64597 vrf-id 0 BGP table version 10 RIB entries 16, using 2944 bytes of memory Peers 1, using 13 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.254.1.100 4 64597 0 0 0 0 0 never Active Total number of neighbors 1
BGP neighbors:
pfSense01.x.internal> show ip bgp neighbors BGP neighbor is 10.254.1.100, remote AS 64597, local AS 64597, internal link Description: BGP with pfSense02-x BGP version 4, remote router ID 0.0.0.0, local router ID 172.19.0.1 BGP state = Active Last read 00:02:36, Last write never Hold time is 180, keepalive interval is 60 seconds Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens: 0 0 Notifications: 0 0 Updates: 0 0 Keepalives: 0 0 Route Refresh: 0 0 Capability: 0 0 Total: 0 0 Minimum time between advertisement runs is 0 seconds For address family: IPv4 Unicast Not part of any update group Community attribute sent to this neighbor(large) 0 accepted prefixes Connections established 0; dropped 0 Last reset 00:02:36, Waiting for NHT BGP Connect Retry Timer in Seconds: 120 Next connect timer due in 85 seconds Read thread: off Write thread: off FD used: -1
Any guidance or hints on why I cant get BGP sessions up and running on either one of these pfsense installs would be greatly appreciated. Thanks!
-
Sorry, i'm trying to fix the formatting above but I keep getting hit with "post content is flagged as spam".
-
Stuck on "Active" and not getting "established" with nothing in the log makes me think:
Did you open 179/tcp on the firewall so these 2 IP addresses can talk to each other on 179/tcp ?
Or the interfaces that you try to BGP over have the box "Block private networks and loopback addresses" ticked thus filtering your RFC1918 traffic.
-
@notseth Did you find a solution to this?
-
@joe_f My solution was migrating away from pfSense to a Cisco CSR1000V.
I opened a case with the FRR team but that did not end up with a proper resolution - https://github.com/FRRouting/frr/issues/6915 -
Very strange, I use pfSense 2.4.5-p1, 2.5.1-REL, 2.5.2-RC, 2.6.0-DEV with FRR doing BGP and this issue has always been solvable.
Only showstopper I have come across these past few weeks is https://redmine.pfsense.org/issues/11545 - If you assign virtual IPv6 addresses to WAN, FRR in pfSense may decide to use one of them for outbound communication, even to your BGP peers which will usually result in the session stuck in "active" and not getting "established" because the peer expects you to come from a specific address.