From: James (james@towardex.com)
Date: Wed Jun 23 2004 - 03:35:27 GMT-3
The FSM states that router shall wait for specific amount of time while in
Active or Idle state. When you clear a bgp session (clear ip bgp * or thelike(
it will reset the FSM for the affected neighbor, thereby forcing BGP Process
to restart the FSM states for that said neighbor. So the Active timer for that
neighbor gets reset, and everythign restarts back to Idle, which then translates
into Connect state. Now that you've fixed the layer2/3 issue, it will
successfully connect this time and immediately bring up the session quickly.
When troubleshooting downed bgp session, after you've fixed the problem, it
is advisable to clear the downed neighbor, to speed up the session-turnup
process by resetting the FSM process.
The time it takes for router to wait in Active state I believe can be controlled
by 'neighbor a.b.c.d timers connect X', which adjusts the connect timer. But I
never tried this yet myself, so I can't confirm this part for sure yet.
Also, misconfiguration of BGP will cause the peers to fall back to Idle state
at the OpenSent stage. The bgp OPEN message includes AS number, etc , etc
attributes as well as capability code exchange that are needed to bring up the
session. Misconfiguration will provide misconfigured attributes in the OPEN
msg, thus causing peers to fall back to Idle state.
Hope this helps..
-J
On Wed, Jun 23, 2004 at 04:14:41PM +1000, Devi Mallampalli wrote:
> Thanks for your feedback, James.
>
> I asked this Q because the other day when I had trouble in bringing
> couple of neighbors up during a lab practice , I have noticed that one
> neighbor in Q is struck in "Active " state and I found that she is not
> reachable (I can not ping it). Then that I had to go to L2 & L3 issues
> and make sure she is reachable via TCP.
>
> Meanwhile I was clearing both "ip route table" as well as "IP bgp table"
> and waited for 2 or 3 minutes each. But as soon as I fixed that
> neighbor's reachability issue, neighbor came on line with in sh ip bgp
> sum table.
>
> And the second neighbor was struck in "Idle state". Immediately I found
> that node is reachable via IP , but still struck in to "Idle state".
> After further analysis , I have realized that I have mentioned a wrong
> remote-as on that neighbor's prefix.
>
> Devi.
>
>
>
>
> -----Original Message-----
> From: James [mailto:james@towardex.com]
> Sent: Wednesday, 23 June 2004 4:04 PM
> To: Devi Mallampalli
> Cc: ccielab@groupstudy.com
> Subject: Re: Sh IP BGP Sum - T/S the BGP neighbors.
>
>
> if i am thinking correctly, the bgp session is managed by the Finite
> State Machine (FSM), which transitions following states until bgp TCP
> connection is established between the peers, in following order:
>
> 1. Idle - router waits random time before attempting TCP connect 2.
> Connect - attempting tcp connection to remote peer 3. Active -
> connection timedout? wait random time, then go back to step 2. 4.
> OpenSent - connection is opening. 5. Established - session is up 6. Any
> Number - session is established and number of bgp prefixes received.
>
> i don't exactly renumber all steps of the FSM, so above may not be 100%
> accurate, but you get the idea..
>
> so speaking in english, ifyou see Active, your session is down. most
> likely
> b/c connection is being rejected at one of the routers, or connection is
> being timed out or other fatal errors preventing the peering to start.
>
> hope this helps! :)
>
> -James
>
> --
> James Jun TowardEX
> Technologies, Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
> On Wed, Jun 23, 2004 at 03:47:42PM +1000, Devi Mallampalli wrote:
> > As part of trouble shooting BGP neighbor relationship problems , Am I
> > safe to think that when ever I do not see any "number" under last
> > column of "State/PfxRcd" (with sh ip bgp sum command) and that section
>
> > shows me that peer is under , "Active" state , it means that I do not
> > have IP reachability problem between peers.
> > &
> > "Idle" state , it means that I do have IP reachability , but I have
> some
> > sort of configuration problem under BGP process , i.e. with my
> > remote-peer N/W prefix mentioning under BGP process or specifying a
> > wrong AS number.
> > Thanks for any verification.
> > Devi.
> >
> >
> >
> >
> >
> >
> >
> >
> > *************************************************************
> > This email and any files attached are considered
> > confidential and intended solely for the use of the individual or
> > entity to whom this email is addressed. If you have received this
> > email in error, please send a reply message to this email address.
> > This footnote also confirms that the above email has been
> > scanned for the presence of computer viruses.
> > *************************************************************
> >
> > ______________________________________________________________________
> > _
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
>
> *************************************************************
> This email and any files attached are considered
> confidential and intended solely for the use of the
> individual or entity to whom this email is addressed.
> If you have received this email in error, please send a
> reply message to this email address.
> This footnote also confirms that the above email has been
> scanned for the presence of computer viruses.
> *************************************************************
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:48 GMT-3