On Sat, Mar 06, 2010 at 06:52:24PM +0100, Rogier Krieger wrote: > On Sat, Mar 6, 2010 at 17:26, PP;Q Q P(P8P?P8QP8P= <chipits...@gmail.com> > wrote: > > no, I want routes exactly to carp. > > That sounds odd. Routes are something different than what particular > host responds to frames directed to a specific hardware address. > > If I understand the rest of your description correctly, you want only > the master bgpd to have sessions and to somehow distribute its routes > to the backup(s), with the backups starting with that 'state' and > initiate connections to your BGP peers whenever a master goes down. I > doubt that'll work. > > In your scenario, if your master goes down, there are no longer any > BGP sessions up with any of your peers. If I'm not mistaken, that will > cause them to withdraw the prefixes you previously advertised from > their tables and no longer forward traffic to you. >
Right, as soon as the master dies the routes will be withdrawn (there may be some overlap since it is possible that carp switches before bgpd realizes the loss). At the moment it is not possible to have a real backup router running. I have some ideas and partial diffs that will allow backup CARP nodes to preload tables. Main problem is that we need graceful restart for this but most peers (as in cizzzcoee) are not able to assist graceful restart. Btw. I'm looking for a device that is capable of doing graceful restarts (as for example some foundry) to test my diff against. Would be great if I could get access to a lab router to play with. > When your new master is promoted, it will set up a new session with > your peers. This is probably not the sort of failover you want to see > happening in production. > That's why you have multiple bgpd routers with redundant pathes. -- :wq Claudio
