To me it seems that even having the IBGP session won't help the OP's particular issue (though he should have it anyway for other reasons)... as the peer session goes down, the routes from it go down with it, and IBGP withdraws those announcements. Nothing gets held over. Maybe establishing a second peering session with each provider will help in your redundancy- that's what I currently do, and yes, it has come in handy.
I'm one week away from implementing OpenBGPD as route servers for maximum BGP redundancy. Here's my plan, maybe you can take something away from it for your own solution for redundancy- I have multiple egress points in my network (separate physical datacenters (DC's) with their own carriers, with the DC's linked together via Layer2 fiber access.) I use OpenBGPD as a route server (RS) at each DC to feed my edge routers a custom single table via IBGP (meaning the RS's are making the real EBGP multihop peerings with my carriers), making the edge routers essentially just packet forwarders. The DC's have layer2 access to each other, so I will populate each DC with an RS with CARP (in a VLAN) so the edge routers (and the carriers) only see one RS at a time, but multiple RS's are on standby. If a DC, edge router, RS, carrier, or Layer2 connections between the DC's fail, the RS's will be able to recover and continue to peer- either with everyone, or just their closest edge router and carriers (each DC has its own separate address blocks, so a split situation won't be a conflict.) As an extra step of redundancy against the RS's, I can have those edge routers form EBGP sessions with their directly connected peers, but only announcing a basic set of our prefixes (not individual /24's like the OpenBGPD RS's do for better traffic engineering, and only accepting a default route.) That way, if the entire redundant OpenBGPD router server model fails (which I doubt will happen), I still have basic routing with my carriers. Dan Farrell > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Stuart Henderson > Sent: Friday, October 13, 2006 6:45 AM > To: misc@openbsd.org > Subject: Re: Failover routers with OpenBGPD and independent BGP sessions > > On 2006/10/13 11:24, Ronnie Garcia wrote: > > >I have been recommended by our ISPs that I should also advertise > > >routes between the routers, so that if one's BGP session fails, it can > > >route packets to the other for a cleaner failover. I have not managed > > >to get this configuration working. > > > > Yes you should, this is called iBGP. All of your BGP routers should have > > a iBGP session with all of the others, in a full mesh (unless you are > > using a route reflector). > > OP has already done that in the config file, the problem is how to > add a route so the other provider's router can be reached. Normally the > provider's router is listed in the IBGP announcement so unless this is > overwritten in the IBGP announcements (by 'set nexthop) you need to have > a route to the provider's router (static or OSPF). > > From the sample config I guess OP may not realise that 'set nexthop' is > on announcements, it doesn't overwrite the nexthop on incoming routes. > Any confusion with the action of 'set' attributes, use bgpd -nv which > demonstrates clearly how they apply. > > On 2006/10/12 14:05, X Y wrote: > > I use depend on carp0 ... carp3 on the master router > > (chosen via advskew) to drop that session if it fails, > > 'depend on carp' is mostly for where you have a peer session running > from a carp address (e.g. if you're at an IXP where you are only > allowed one IP address and want to connect two routers). It is used > to hold the backup router in IDLE in normal conditions, and > immediately connect when it becomes master. I'm not sure this is > what you are intending to do? > > It might help to see some 'sh ip bgp d <some.prefix>'.
