On Mon, Sep 8, 2008 at 4:26 PM, Henning Brauer <[EMAIL PROTECTED]>wrote:
> * [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. I understand that an Active state is part of the natural progression of a BGP session and is not necessarily an "error" per se, however when I'm originating routes from my firewall and upon a failover, manual or otherwise, waiting up to 4 minutes for a timer to expire seems to be inadequate and problematic for my network. what am i missing? On a sidenote, a few minutes ago when attempting to start up a vpn session by running isakmpd -v -S -K, then ipsecctl -f /etc/ipsec.conf, the bgp session unexpectedly and suddenly dropped from an established to an idle state, without me even fussing around with the interfaces, carp,bgp or failing over... This seems to be a separate issue but this time I did get a FATAL error.... I tried failing over to other firewall but my initial issue came into play where the session did not get established fast enough for me so I had to manually kill the bgp daemon and restarted it to bring it back up quickly... Any ideas on this front? Sep 8 19:50:20 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): write error: Operation not permitted Sep 8 19:50:20 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Established -> Idle, reason: Fatal error Sep 8 19:50:20 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): write error: Operation not permitted Sep 8 19:50:20 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Established -> Idle, reason: Fatal error Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Idle -> Connect, reason: Start Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): connect: Operation not permitted Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Connect -> Active, reason: Connection open failed Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Idle -> Connect, reason: Start Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): connect: Operation not permitted Sep 8 19:50:50 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Connect -> Active, reason: Connection open failed Sep 8 19:50:58 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): connect: Operation not permitted Sep 8 19:52:50 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): connect: Operation not permitted Sep 8 19:52:50 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): connect: Operation not permitted Sep 8 19:53:57 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): state change Active -> Idle, reason: Stop Sep 8 19:53:57 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Active -> Idle, reason: Stop Sep 8 19:53:57 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Active -> Idle, reason: Stop Sep 8 19:54:23 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): state change Idle -> Connect, reason: Start Sep 8 19:54:23 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): connect: Operation not permitted Sep 8 19:54:23 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): state change Connect -> Active, reason: Connection open failed Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Idle -> Connect, reason: Start Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): connect: Operation not permitted Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Connect -> Active, reason: Connection open failed Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Idle -> Connect, reason: Start Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): connect: Operation not permitted Sep 8 19:54:23 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Connect -> Active, reason: Connection open failed Sep 8 19:54:37 susan bgpd[20945]: neighbor x.y.z.141 (iBGP-fw-pri): state change Active -> Idle, reason: Stop Sep 8 19:54:37 susan bgpd[21725]: route decision engine exiting Sep 8 19:54:37 susan bgpd[20945]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Active -> Idle, reason: Stop Sep 8 19:54:37 susan bgpd[4111]: kernel routing table decoupled Sep 8 19:54:37 susan bgpd[20945]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Active -> Idle, reason: Stop Sep 8 19:54:37 susan bgpd[20945]: session engine exiting Sep 8 19:54:37 susan bgpd[4111]: Terminating Sep 8 19:54:42 susan bgpd[10127]: startup Sep 8 19:54:42 susan bgpd[26850]: route decision engine ready Sep 8 19:54:42 susan bgpd[18453]: listening on 0.0.0.0 Sep 8 19:54:42 susan bgpd[18453]: listening on :: Sep 8 19:54:42 susan bgpd[18453]: session engine ready Sep 8 19:54:42 susan bgpd[18453]: neighbor x.y.z.141 (iBGP-fw-pri): state change None -> Idle, reason: None Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.83 (iBGP-rtr-sec): state change None -> Idle, reason: None Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.82 (iBGP-rtr-pri): state change None -> Idle, reason: None Sep 8 19:54:42 susan bgpd[18453]: neighbor x.y.z.141 (iBGP-fw-pri): state change Idle -> Connect, reason: Start Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Idle -> Connect, reason: Start Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Idle -> Connect, reason: Start Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.83 (iBGP-rtr-sec): state change Connect -> OpenSent, reason: Connection opened Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.83 (iBGP-rtr-sec): state change OpenSent -> OpenConfirm, reason: OPEN message received Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.82 (iBGP-rtr-pri): state change Connect -> OpenSent, reason: Connection opened Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.82 (iBGP-rtr-pri): state change OpenSent -> OpenConfirm, reason: OPEN message received Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.83 (iBGP-rtr-sec): state change OpenConfirm -> Established, reason: KEEPALIVE message received Sep 8 19:54:42 susan bgpd[18453]: neighbor a.b.c.82 (iBGP-rtr-pri): state change OpenConfirm -> Established, reason: KEEPALIVE message received Sep 8 19:54:43 susan bgpd[10127]: nexthop a.b.c.83 now valid: directly connected Sep 8 19:54:47 susan bgpd[10127]: nexthop a.b.c.82 now valid: directly connected when it rains it pours i guess... > > > > 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. > thats what i thought... > > > > 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' just wondering why the initial connectretry timer seems to be so high? 4 minutes? would you recommend I not lower this to something kind of extreme, say 10 seconds? > > -- > 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
