[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quagga-dev
Subject:    [quagga-dev 265] Re: [quagga-users 491] Re: Hardware Spec for a route
From:       Paul Jakma <paul () clubi ! ie>
Date:       2003-09-29 12:26:23
[Download RAW message or body]

On Mon, 29 Sep 2003, Gilad Arnold wrote:

> I don't believe it blocks bgpd:

yeah, i didnt think it could either, but i had an unexplained 4-day
outage (friday to monday - we hadnt setup monitoring for that bgpd
and didnt notice) on a bgpd, and the only thing i can pin it on is
having left a 'show ip bgp' sitting in the pager. when i hit q on the
pager on tuesday morning it apparently went back to normal and
immediately reset the sesssion and all was well. 

I dont know though if it was a problem with all peers or just the ISP
who got in touch. That bgpd had one other upstream peer who are
really good about monitoring and usually raise all sorts of alarms 
within ten minutes max of there being a problem, but they hadnt.

maybe it was coincidence.. i dont know.

> what I've experienced in zebra itself ('show ip route'), and what I
> see in bgpd/bgp_route.c as well, is that when the lines limit is
> reached, the current route node is recorded to the vty's output_rn
> member (together with some other parameters, like the callback
> function, etc) and the process is released until further input is
> received from the user, be it 'continues' or 'break'.

yep. i dont know how it would block bgpd.

> The only lock I can think of is the refcount of the current route
> node, however this shouldn't block anything, at least not as long
> as the route table is intact, of course (can that happen?! what
> happens upon 'no router bgp'? worth checking!... ;-> )

how do you mean? while vty output is suspended in pager?

anyway, i dont know how, and maybe it was pure coincidence, perhaps 
some other problem altogether, i dont know - but its something on my 
'must investigate' list anyway.

> Gilad

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam@dishone.st
Fortune:
try again

[prev in list] [next in list] [prev in thread] [next in thread]