* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-09-09 00:35]: > On Mon, Sep 8, 2008 at 2:11 PM, Henning Brauer <[EMAIL PROTECTED]> wrote: > > phew. > didnt mean to scare you with a false alarm... just thought that line was > funny when i came across it...
that's what i thought when i wrote it :) it has the nice side effect of making sure people actually report it when they run into it, which by all means should be impossible. > > session staying in Active is not an error. it waits for the connection > > from the other side. > it seems to wait indefinitely which is problematic... maybe there could be > something else wrong. staying indefinately in Active is not necessarily an error. > > if it is configured passive it will stay in > > Active until there is a connection and never try itself. and i seem to > > remember sth with passve in the carp and depend case, but it's been a > > while that i touched that code. > I don't have any passive directives on any of the systems involved so I > would imagine that the firewalls would be triggered to initiate the tcp > connection to its peers as soon as it realizes the carp interface is now > master. maybe im wrong here? that should work i think. as said, it's been a while. > > now that i rewrote the timers stuff i > > could actually finally kill the little ugliness involved with it now. > > if i just find time :) > any suggestions for a workaround in the meantime? what i am talking about is a code change without effects for the user. you should check 'bgpctl sh nei foo timer' -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
