> PS; We are against 'sloppy state' so much because we cannot sanitize > the sessions anywhere else (these firewalls connect to raw Transit). > > In the meantime I think we're going to be forced to use ifstated to > shutdown OpenBGPd on the backup :( > > Ugly and very slow, but I would rather this than risk insecurity.. > > Thanks for reading :)
I have (I think) almost exactly the same issue; doesn't pfsync between the redundant BGP routers solve your state-tracking problem? In my case, I have two BGP routers communicating with one upstream peer (one session per router), *not* using the CARP IP to establish BGP sessions. I had started with one BGP session originating from the CARP IP, but every time I failed over, all my announcements went away and instead of a ~60sec outage I had a ~4hr partial outage while my routes re-propagated and foreign ASes stopped damping the change. At the moment, I've disabled pf altogether, but preliminary testing shows that using pfsync solves my problem - both routers maintain the same state table, so it no longer matters which router processes any given packet (AFAICT). -Adam Thompson [email protected]
