High-availability BGP with BIRD

[Jan Bramkamp]

On 22.08.2013 03:08, Thomas Johnson wrote:
> Please let me know if bird-users is not the appropriate place for this
> post; admittedly it is more of a "best practices" question...
> 
> I am in the process of trying to develop a plan for deploying BGP in a
> high-availability configuration, using a pair of FreeBSD hosts running
> BIRD. A number of questions have come up, leaving me unsure how to
> proceed. The fact that this is my first experience with BGP doesn't
> help matters. The following diagram outlines how I envision the
> [physical] configuration.
> 
>                   +----------+
>            +------+ router-a +-------+
>     xxxxxxxx      +----------+       |
>    xx      xx                     +--+-----+       +------------+
>   xx  LAN   x                     + switch +-------| ISP router |
>   x        xx                     +--+-----+       +------------+
>   xx   xxxxx      +----------+       |
>    xxxxx   +------+ router-b +-------+
>                   +----------+
> 
> I dumped this in a pastebin, in case my mail client mauls
> it..http://pastebin.com/rDTDMA7j
> 
> In this scenario, router-a and router-b are running FreeBSD, with CARP
> to provide a virtual IP for failover. The two routers act in a
> failover manner, with router-b taking over the virtual IP upon failure
> of router-a. The goal is to maintain the fast failover (seconds) that
> I get from CARP in non-BGP configurations. I am wondering if the
> following method is a common/feasible/best solution.
> 
> Under normal conditions.
> * BOTH router-a and router-b establish BGP sessions to the ISP. This
> way, each router has a copy of the BGP routing table in memory, ready
> to go.
> * router-a advertises my prefixes to the ISP router.
> * all regular traffic is handled by router-a.
> 
> If router-a fails.
> * Programmatically update the router-b BIRD config to begin
> advertising prefixes.
> * router-b already has the BGP table in memory, so routing can resume
> immediately.
> 
> Is there a better way to achieve this? Will my ISP laugh at me when I
> ask them to assign me a /29, and allow me to run two BGP sessions?
> 
> Thank you!
> TJ
> 
Congratulations now the switch is your single point of failure.

Running two BGP sessions for HA isn't usual but i have the impression
you want to implement several "roles" in one pair of devices without
thinking about the roles firsts.

role 1: BGP edge router
role 2: default gateway
role 3: stateful packet filter (NAT)?

+--------------+  eBGP  +----------+  OSPF +------+       +-------+
| ISP router a |<------>| router a |<--+-->| fw a |<--+-->| def a |<--+
+--------------+        +----------+   |   +------+   |   +-------+   |
                             ^         |              |               |
                             | iBGP    |              |              LAN
                             v         |              |               |
+--------------+  eBGP  +----------+   |   +------+   |   +-------+   |
| ISP router b |<------>| router b |<--+-->| fw b |<--+-->| def b |<--+
+--------------+        +----------+       +------+       +-------+

Now you merge router x,fw x,def x into one device each.

+--------------+  eBGP  +----------+  LAN
| ISP router a |<------>| router a |<--+
+--------------+        +----------+   |
                             ^         |
            iBGP,CARP,pfsync |         | CARP
                             v         |
+--------------+  eBGP  +----------+   |
| ISP router b |<------>| router b |<--+
+--------------+        +----------+

Use devd to react to CARP state changes on the crossover cable between
the routers. It might be a good idea to use cloned loopback interfaces
for iBGP to simplify further expansions. Also you use net/ifstated for
more complex checks, activate CARP preemption and demote the carp groups
according to the services (e.g. established BGP session, DNS resolver
working, etc.).

SEE ALSO:
     devd.conf(5), devd(8), carp(4), pfsync(4), rc.conf(5)