Hiya Mike, On Wed, 5 Jan 2005, Mike Hughes wrote:
> --On 05 January 2005 15:53 +0000 Sam Stickland <[EMAIL PROTECTED]> > wrote: > >> I've just added it's 49th and 50th BGP sessions to it, but they remain >> stuck in the IDLE stack. If I do a 'clear ip bgp nei x.y.z.w' then the >> state briefly changes to IDLE* and then back to IDLE. >> >> The neighbor configuration is identical to the other working sessions, >> and the next-hop is reachable and directly connected. >> >> It has 283MB of RAM free, and there isn't anything unusual in the logs. >> >> As I recall when I recently added it's 48th BGP session it stayed in the >> IDLE state for 5 minutes before establishing. >> >> Has anyone got any suggestions as to what's wrong? > > Any idea what the neighbour is? > Anything interesting or odd in the logs on the neighbour device? I've asked the peer for this information. In the meantime a quick MAC address check shows it's a cisco. > Foundry used to have an insanely aggressive BGP scanner. Maybe they have > toned it down a bit, and in doing so, gone ultra conservative? Perhaps, but there wasn't any problems with the first 47 BGP sessions - they all established correctly. I tried shutting down an iBGP session I could afford to lose. It didn't make any difference to the two stuck IDLE sessions, and it came back up again almost straight away when I brought it back. So that does suggest that it's a problem specific to these neighbours. (Just to clarify, when I save it's stuck in the IDLE state, it never moves into the ACTV or CONN states). Sam From [EMAIL PROTECTED] Wed Jan 5 11:14:12 2005 From: [EMAIL PROTECTED] (Stephen J. Wilcox) Date: Wed Jan 5 11:14:18 2005 Subject: [f-nsp] BGP Session stuck in IDLE state In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> sh mem ? Steve On Wed, 5 Jan 2005, Sam Stickland wrote: > Hiya Mike, > > On Wed, 5 Jan 2005, Mike Hughes wrote: > > > --On 05 January 2005 15:53 +0000 Sam Stickland <[EMAIL PROTECTED]> > > wrote: > > > >> I've just added it's 49th and 50th BGP sessions to it, but they remain > >> stuck in the IDLE stack. If I do a 'clear ip bgp nei x.y.z.w' then the > >> state briefly changes to IDLE* and then back to IDLE. > >> > >> The neighbor configuration is identical to the other working sessions, > >> and the next-hop is reachable and directly connected. > >> > >> It has 283MB of RAM free, and there isn't anything unusual in the logs. > >> > >> As I recall when I recently added it's 48th BGP session it stayed in the > >> IDLE state for 5 minutes before establishing. > >> > >> Has anyone got any suggestions as to what's wrong? > > > > Any idea what the neighbour is? > > Anything interesting or odd in the logs on the neighbour device? > > I've asked the peer for this information. In the meantime a quick MAC > address check shows it's a cisco. > > > Foundry used to have an insanely aggressive BGP scanner. Maybe they have > > toned it down a bit, and in doing so, gone ultra conservative? > > Perhaps, but there wasn't any problems with the first 47 BGP sessions - > they all established correctly. > > I tried shutting down an iBGP session I could afford to lose. It didn't > make any difference to the two stuck IDLE sessions, and it came back up > again almost straight away when I brought it back. > > So that does suggest that it's a problem specific to these neighbours. > > (Just to clarify, when I save it's stuck in the IDLE state, it never moves > into the ACTV or CONN states). > > > Sam > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp >
