Bgp – How to run redundant BGP via Quagga on /30 netblock

bgpvrrp

My new BGP upstream has allocated a IPv4 /30 netblock as the glue block for connecting our routers. I however want to run two routers, and failover between them. If the netblock was larger (/29), I could easily run BGP sessions from both of my routers, with or without VRRP (they could run VRRP too).

Is there a reasonable VRRP/keepalived failover configuration that I can implement without getting them to expand the glue block?

Both of my routers are running Linux (one Ubuntu, one Gentoo), with Quagga; the basic configuration works fine.

Best Answer

You have multiple Linux solutions for first hop redundancy out of your LAN to the two routers (Quagga itself doesn't support VRRP but you can use Quagga in conjunction with any of these without any issues):

keepalived (as you've already mentioned)
uCARP - A Linux port of OpenBSD's CARP (Common Address Redundancy Protocol)
vrrpd - A sparsely documented and largely untested VRRP daemon, but an option nonetheless

Note that none of these have anything to do with BGP redundancy, which I believe is the real problem you're trying to solve. However, it should be quite possible to run VRRP on the provider side of your two Quagga hosts and configure the VRRP virtual IP as "your side" of your ISP-assigned /30 and use that to peer with your ISP. The failover time would likely be close to the same (if not just a hair faster than) the solution with Linux-HA below. With that said, I'd personally believe that the Linux-HA solution would be cleaner and simpler, but this also may depend on the topology.

As for your options with BGP, there is an IETF draft for "multisesssion BGP" that introduces a new BGP capability code which aims to support multiple BGP sessions with the same peer over the same address, but this draft assumes that both of the sessions would be on the same device, however the draft is brand new and support for this is not likely to be in current revisions of Quagga.

One other option is to use Linux-HA to set up a heartbeat cluster between your two boxes, and configure it as such so that if the primary router fails, the heartbeat will recognize this and turn up Quagga/BGPd/etc on the standby router when that happens.

Related Solutions

How to Redirect BGP Routes into a File with Quagga

Let's assume that you are in a bash shell on the quagga router... use the script command to capture output from quagga (or any other interactive CLI session)... a contrived example which saves the quagga bgp routes to a file named bgp_routes.txt

$ script bgp_routes.txt
Script started, file is bgp_routes.txt
$ telnet localhost 2605
... authenticate as required
Router# terminal length 0
... run show ip bgp command
Router# exit
$ exit

Routing – Redirect Inbound Traffic to Another Router Not Running BGP

There may be a way to acheive this by exploiting the following BGP next hop rule:

From RFC 4271, 5.1.3 NEXT_HOP:

When sending a message to an external peer, X, and the peer is one IP hop away from the speaker:

- If the route being announced was learned from an internal peer or is locally originated, the BGP speaker can use an interface address of the internal peer router (or the internal router) through which the announced network is reachable for the speaker for the NEXT_HOP attribute, provided that peer X shares a common subnet with this address. This is a form of "third party" NEXT_HOP attribute.

Could you try this:

Remove the OSPF adjacency between Cisco and Mikrotik on network 192.168.2.0/30
Create the OSPF adjacency between the Cisco and Mikrotik routers across the shared network 198.51.100.0/29
Make sure that the routes the Cisco router is learning via OSPF have a next hop of 198.51.100.5
Clear the BGP sessions. The Cisco router should now advertise routes to internal subnets with a BGP NEXT_HOP of 198.51.100.5

This article shows an example:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

BGP Next Hop (Multiaccess Networks)

This example shows how the next hop behaves on a multiaccess network such as Ethernet.

Assume that RTC and RTD in AS300 run OSPF. RTC runs BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA with regard to 180.20.0.0, RTC uses as next hop 170.10.20.3. RTC does not use its own IP address, 170.10.20.2. RTC uses this address because the network between RTA, RTC, and RTD is a multiaccess network. The RTA use of RTD as a next hop to reach 180.20.0.0 is more sensible than the extra hop via RTC. Note: RTC advertises 180.20.0.0 to RTA with a next hop 170.10.20.3. If the common medium to RTA, RTC, and RTD is not multiaccess, but NBMA, further complications occur.

Best Answer

Related Solutions

How to Redirect BGP Routes into a File with Quagga

Routing – Redirect Inbound Traffic to Another Router Not Running BGP

Related Topic