Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OPENBGP with CARP, nexthop<carp ip=""></carp>

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    10 Posts 5 Posters 7.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      acherman
      last edited by

      Hey everyone, I am trying to finalize my config for adding BGP to peer with our two upstream providers (Shaw and Telus).  Here is what our basic connections look like:

      As is discussed in multiple places (like this tread: http://forum.pfsense.org/index.php/topic,46032.0.html, I have 2 routers that currently use CARP to connect to both providers with a shared IP address, and I want to create a BGP session from each router to each provider in order to allow the failover times to stay on par with CARP's capabilities.  I'm stuck in trying to figure out exactly how to do this.  There is reference to using the an attribute set line like network xx.xx.125.0/24 set nexthop xx.xx.127.250 to set the nexthop the provider uses to the CARP IP, but I'm confused on how this works for both providers.  Do I add a line for each CARP address like this:

      network xx.xx.125.0/24 set nexthop xx.xx.127.250
      network xx.xx.125.0/24 set nexthop xx.xx.241.4

      I'm just not sure how that will be interpreted at each provider.

      Any help is appreciated.  Thanks in advance.

      Aaron

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        IIRC, the BGP state can't sync between the two nodes, so you're better off getting separate feeds for each wan on each box (4 feeds total) rather than trying to do it with two.

        Otherwise when CARP fails you have to wait for BGP to completely rebuild its relationship(s) with the ISPs.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • A
          acherman
          last edited by

          Hey Jim, that's exactly what I have - one feed from each WAN provider to each router, 4 in total.  So, I want to create a BGP session from each router to each provider, 4 sessions in total, so that if a failure occurs we don't have to wait for BGP to establish a session.  But, I need to figure out how to tell each provider to forward packets (nexthop) to my carp addresses instead of the real interface addresses.  I assume this is done via the network set nexthop as noted, but I don't understand how it works with both providers when there is a different carp IP for each.  It seems like the providers would get confused if I advertise the same network twice, with a different nexthop IP in each.

          If it's not possible to do this with OpenBGP and CARP (which I have assumed it is, there is some info out there, but nothing specific to this detail), is it likely that I can tell my providers to statically enter my CARP addresses as their nexthop?

          1 Reply Last reply Reply Quote 0
          • J
            jnex26
            last edited by

            Sounds like your having the same problems as me.

            in Theory you should be able to have a bgp session set up on the primary and secondary router.

            In the case of a failure of the primary wan then a carp failover to the secondary firewall would give you the a much faster response time as the secondary firewall should already have the session "Setup" but idle, however carpdev is not yet implemented into freebsd so we can't use the demote feature which quite frankly sucks.

            in your situation I would probably use "depend on" to allow BGP to follow carp failover it does mean that the case of a router failure your looking at longer failover times.

            alternatively only have one session per router then allow CARP to manage the failover, this allows for fast failover but if carp cannot detect a physical interface failure (connection plugged though a switch) then you will need something to manage the failover of carp.

            1 Reply Last reply Reply Quote 0
            • R
              Reiner030
              last edited by

              Hi

              the setup is eays… when you find out how it woks... it had costs me severald long days and nights :(

              => OpenBGP has a very unlogical way to create the routing tables  and announcing metric and nexthops (and guessable other things, too).

              => I have realized it this way (adopted to your needs): => it can be only configured "raw":
              Important is always "the order" of filter rules (and the combination^^)
              And don't forget to "mesh" the peers...

              
              as-own              = 12345
              as-peer1           = 123
              as-peer2           = 124
              
              local_ip_gw1    = xx.xx.127.xx
              local_ip_gw1_v6 = 
              local_gw1       = xx.xx.127.250
              peer_ip_gw1     = xx.xx.127.xx
              peer_ip_gw1_v6  =   
              
              local_ip_gw2    = xx.xx.241.xx
              local_ip_gw2_v6 = 
              local_gw2       = xx.xx.241.4
              peer_ip_gw2     = xx.xx.241.xx
              peer_ip_gw2_v6  =  
              
              AS         $as-own
              fib-update yes
              router-id  $local_ip_gw1   # or what you want
              
              group "Peer1" {
                      remote-as  $as-peer1
                      holdtime   20 
                      # no-modify needed in combination with filter
                      # rule to set CARP IP address as nexthop :-(
                      set        nexthop  no-modify
                      neighbor $peer1_gw {
                              descr "GW_Peer1"
                              local-address $local_ip_gw1
                      }
                      neighbor $peer1_gw_v6 {
                              descr "GW_Peer1_v6"
                              local-address $local_ip_gw1_v6
                      }
              }
              
              group "Peer2" {
                      remote-as  $as-peer2
                      holdtime   20 
                      # no-modify needed in combination with filter
                      # rule to set CARP IP address as nexthop :-(
                      set        nexthop  no-modify
                      neighbor $peer2_gw {
                              descr "GW_Peer2"
                              local-address $local_ip_gw2
                      }
                      neighbor $peer2_gw_v6 {
                              descr "GW_Peer2_v6"
                              local-address $local_ip_gw2_v6
                      }
              }
              
              group "internal" {
                      remote-as  $as-own
                      holdtime   6
                      neighbor $peer_ip_gw1 {
                              descr "internal neighbor GW1"
                              local-address $local_ip_gw1
                      }
                      neighbor $peer_ip_gw1_v6 {
                              descr "internal neighbor GW1 v6"
                              local-address $local_ip_gw1_v6
                      }
                      neighbor $peer_ip_gw2 {
                              descr "internal neighbor GW2"
                              local-address $local_ip_gw2
                      }
                      neighbor $peer_ip_gw2_v6 {
                              descr "internal neighbor GW2 v6"
                              local-address $local_ip_gw2_v6
                      }
              }
              
              match to   group Peer1     inet    set { nexthop $local_gw1         }
              match to   group Peer1     inet6  set { nexthop $local_gw1_v6    }
              
              match to   group Peer2     inet    set { nexthop $local_gw2         }
              match to   group Peer2     inet6  set { nexthop $local_gw2_v6    }
              
              # do not forget deny/allow rules
              
              

              Its important to set 2 filter rules… why ever... one who set the nexthop and the neighbor/peer based "no-modify". ::)

              Not needed for this task but to document it for other cases:
              Also there is a problem if you wand metric based routing.
              The metric is only accepted if the localpref is lowered:

              
              match to    group Peer2       set { metric 10 localpref -10 }
              
              

              Because I split my AS onto 2 buildings I need iBGP rules…
              When I try to use this filter to announce it to my iBGP peers there was the correct metric sent and set in my internal peer, but the external peer got all routes with metric 0 :(
              Till I found out that I must use an internal filter on my internal peer side instead of an outgoing filter on the source side:

              
              match from group internal    set { metric 10 localpref -10 }
              
              

              And you must add an empty line after the last rule that OpenBGPd is happy with the config file  ???

              Bests

              Reiner

              1 Reply Last reply Reply Quote 0
              • I
                IcePick
                last edited by

                I have been trying to get Reiner030's solution to work.

                I have been working on it in the lab so I have access to the upstream routers.

                Problem I am running into is that the next-hop IP is only set on routes learned from the CARP Backup cluster member.
                The cluster node with the CARP IP Masters sends its route to the upstream using its bgp peering IP.

                I can duplicate by disabling CARP on the master and then restarting the openbgpd on both nodes. The only routes with the CARP vIP set as next-hop set will be from the node with CARP disabled.

                Any suggestions?

                1 Reply Last reply Reply Quote 0
                • R
                  Reiner030
                  last edited by

                  @IcePick:

                  Problem I am running into is that the next-hop IP is only set on routes learned from the CARP Backup cluster member.
                  The cluster node with the CARP IP Masters sends its route to the upstream using its bgp peering IP.

                  you used also this line?

                  match to   group Peer1     inet    set { nexthop $local_gw1         }
                  

                  You can see what your OpenBGP would announces:

                  [2.1-BETA1][root@gw1.jws1.local]/root(31): bgpctl show ip bgp detail out neighbor PEERNAME-OR-IP

                  BGP routing table entry for xx.xx.xx.0/21
                      Nexthop xx.xx.9.122 (via xx.xx.9.122) from LOCAL (xx.xx.9.125)
                      Origin IGP, metric 0, localpref 100, weight 0, internal, valid, best, announced
                      Last update: 5d21h15m ago

                  Tthis is my direct announcement of my master/slave… my IBPG peer announcements are not listed in this overview ("from LOCAL").

                  Bests

                  1 Reply Last reply Reply Quote 0
                  • I
                    IcePick
                    last edited by

                    @Reiner030:

                    you used also this line?

                    match to   group Peer1     inet    set { nexthop $local_gw1         }
                    

                    yes using that line. It works perfect on the carp backup member, and if i disable carp on the master and restart bgpd it works there too.

                    Also found that if the peering is ibgp it works fine, only broken on the CARP master when doing ebgp peering.

                    1 Reply Last reply Reply Quote 0
                    • I
                      IcePick
                      last edited by

                      After making no headway with the ebgp/carp master issues we stopped trying to set the next hop to the carp IP in the announcement from the pfsense cluster.
                      We are now setting the next hop with a filter on the upstream router.

                      1 Reply Last reply Reply Quote 0
                      • R
                        Reiner030
                        last edited by

                        @IcePick:

                        After making no headway with the ebgp/carp master issues we stopped trying to set the next hop to the carp IP in the announcement from the pfsense cluster.
                        We are now setting the next hop with a filter on the upstream router.

                        yes, was our  first solution here, too till I found out why it happened on my side.

                        Problem was that even the read in output didn't helped much to understand why it won't work the "logical" way:

                        bgpd -v -n -f /var/etc/openbgpd/bgpd.conf

                        I guess there is a very special order of filtering rules but they are not officially explained (or I haven't them found)…

                        But Setting HOP on peer side should be good enough ;)

                        Bests

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.