On Sun, Mar 07, 2010 at 10:00:40AM +0500, ???? ??????? wrote: > 2010/3/7 Claudio Jeker <[email protected]>: > > On Sat, Mar 06, 2010 at 06:52:24PM +0100, Rogier Krieger wrote: > >> On Sat, Mar 6, 2010 at 17:26, P P;Q Q P(P8P?P8Q P8P= > > <[email protected]> > >> 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. > > we have Juniper on other side, I could test the patch. >
Thanks but I need full access to the device. When I know it is working I will send it out to tech@ so that people can test against other implementations. > > > >> 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. > > from the network point of view, packets will come from the same MAC an > IP address (because of CARP), so ... if BACKUP will "just continue to > maintain a session, established by MASTER", nobody will even know, 1 > sec is nothing in terms of BGP > You can not "just continue to maintain a session, established by MASTER". That implies that you can migrate a running TCP session plus all the necessary state information of the session engine from one system to another. -- :wq Claudio
