On further thought, using option 1 and randomising the next hop used wouldn't provide a very good distribution of load as it would be on a per network route basis and not on a per IP basing like proper multipath. Would also be costly in route look ups etc.
So looks like we would need to use 'maximum-paths n' in OpenBGP to insert multiple routes into the kernel FIB and use next-hop-self on the iBGP neighbour ASBR routers connecting to the exchange etc, to achieve full load balancing across ASBRs. That would provide a good load distribution but means we also have to wait for BFD (Bidirectional Forward Detection) support on BGP to address the convergence issues of using next-hop-self. What do people think? Thanks for your thoughts :) Andy Sent from my iPhone > On 29 Mar 2014, at 21:45, Andy <a...@brandwatch.com> wrote: > > Hi, > > Is OpenBGPD capable of inserting equal cost multi-path routes into the > kernel FIB like OpenOSPFD can? > > > I have equal cost routes being received into OpenOSPFD's RIB from two > different OSPF ASBR neighbors, for accessing the same IXP network to > which we are connected. These two multi-path routes are inserted into > the Kernel FIB fine. > If I ping various routers on the IXP network I can see that multi-path > is being used and a different ASBR neighbor is used for each IP etc.. > Great :) > > [LIVE]root@mg131:~# ospfctl show rib | grep 5.57.80 > 5.57.80.0/22 185.25.30.2 Type 1 ext Network 21 01w1d09h > 5.57.80.0/22 185.25.30.1 Type 1 ext Network 21 01w0d04h > > [LIVE]root@mg131:~# netstat -rn | grep 5.57.80 > 5.57.80/22 185.25.30.2 UGP 0 42 - 32 vlan202 > 5.57.80/22 185.25.30.1 UGP 0 77 - 32 vlan202 > > > > I therefore of course also have equal cost routes being received into > OpenBGPD's RIB from the two different iBGP peers (the same two ASBR > neighbors as above), for all the networks received via our IXP BGP peerings. > OpenBGPd by default only selects one path to the remote networks, the > nexthop in the IXP network for the path is translated into a directly > connected nexthop (using the OSPF routes for the IXP network). > > [LIVE]root@mg131:~# bgpctl show rib | more > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > I*> 1.0.0.0/24 5.57.80.136 1000 0 15169 i > I* 1.0.0.0/24 5.57.80.136 1000 0 15169 i > I*> 1.0.4.0/24 5.57.80.128 100 1 6939 7545 56203 i > I* 1.0.4.0/24 5.57.80.128 100 1 6939 7545 56203 i > I*> 1.0.5.0/24 5.57.80.128 100 1 6939 7545 56203 i > I* 1.0.5.0/24 5.57.80.128 100 1 6939 7545 56203 i > . > . > > [LIVE]root@mg1311:~# netstat -rn | more > Routing tables > > Internet: > Destination Gateway Flags Refs Use Mtu Prio Iface > 1.0.0/24 185.25.30.2 UG 0 0 - 48 vlan2302 > 1.0.4/24 185.25.30.2 UG 0 0 - 48 vlan2302 > 1.0.5/24 185.25.30.2 UG 0 0 - 48 vlan2302 > . > . > > However it always chooses the same directly connected ASBR for every > route during the next-hop translation step and no load balancing is > achieved. :( > > Even if I use 'next-hop-self' on the ASBR's to remove the nexthop > translation step, the same ASBR is always chosen (due to BGP best path > selection always matching for each route). > > I also don't want to use next-hop-self anyway as that would *destroy* > convergence times should an ASBR be unavailable, as in the absence of > BFD it would be relying on BGP long timers to change the route, instead > of having OSPF's fast convergence to change the next-hop in less than a > second. > > > From my understanding the only options are; > 1) Randomize the directly connected nexthop used during in the next-hop > translation step. > 2) Use next-hop-self on the ASBR's to insert two routes into the RIB > with different next-hops (one for each ASBR) (requiring BFD for BGP to > not destroy convergence), and also enable BGP multi-hop > (http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#bgpmpath) > > to insert both RIB routes into the FIB, so the kernel can perform > equal-cost multi-path routing. > > > Thanks for your time and for reading. > Cheers, Andy. > > > > > /**/
