Re: bgp scan-time

Petr,

Thank you for this insight...

---- Petr Lapukhov <petr_at_internetworkexpert.com> wrote:
> BGP scanner is mainly used to validate BGP next-hops, that is to
> re-calculate BGP dependencies on IGP. Between scanner runs, BGP (normally,
> see exception below) does not respond to IGP events, e.g. link failure
> reports or cost changes that may result in best-path re-election. If you
> want to detect edge link failure via IGP, you need to advertise this link
> into IGP. In this case, during next periodic run, BGP scanner will respond
> to link fault as reported by IGP and re-calculate best-paths. This periodic
> process makes BGP more stable and robust in response to IGP events.
>
> However, in modern networks, event-drivent next-hop validation is used in
> most scenarios. This is known as "BGP next-hop tracking" - BGP registers
> next-hop values (commonly their number equal number of exits from local AS)
> with IGP process and reacts when IGP event occurs: cost change or prefix
> unreachability. This makes BGP scanner process practically obsolete, though
> it's still used for few other purposes, e.g. conditional advertisement. The
> net effect is that BGP convergence within a single AS could be almost as
> fast as IGP (of course, full table walks and FIB updates still take their
> toll). Tracking is enabled in all recent IOS versions and could be tuned
> using the command "*bgp nexthop trigger". *The obvious drawback is
> vulnerability to IGP instabilities, which requires careful tuning of IGP.
>
> Notice that in order to rely on IGP for notification of link faults you need
> to advertise peering links into IGP, and not use the BGP's "next-hop-self"
> command at the edge routers. This potentially makes IGP (and BGP in turn)
> less stable, so IGP event dampening or IP event dampening should be used to
> minimize the effects of flapping links. If you decided not to advertise
> peering link into IGP, then convergence will be based on BGP's detection of
> failed link (e.g. keepalives or L2 even report) and flow of BGP
> withdraw/update messages across the BGP mesh, which is considerably slower
> as compared to quick IGP event flooding.
>
> HTH,
>
> 2011/4/17 <dls152_at_cox.net>
>
> > when should you use bgp scan-timer?
> >
> >
> > ---- Paul Negron <negron.paul_at_gmail.com> wrote:
> > > Well, since scan time reflects how often the BGP Table is read and the
> > > TIMERS represent the keep alive and hold timer adjustments. I would say
> > that
> > > your best answer would be "TIMERS" for that particular problem with
> > limited
> > > evidence. Only because you mentioned a link failure.
> > >
> > > Paul
> > > --
> > > Paul Negron
> > > CCIE# 14856 CCSI# 22752
> > > Senior Technical Instructor
> > > www.micronicstraining.com
> > >
> > >
> > >
> > > > From: <dls152_at_cox.net>
> > > > Reply-To: <dls152_at_cox.net>
> > > > Date: Sun, 17 Apr 2011 22:25:51 -0400
> > > > To: <ccielab_at_groupstudy.com>
> > > > Subject: bgp scan-time
> > > >
> > > > Does lowering the bgp scan-time help with converegence when primary
> > link
> > > > fails? Or does the timers bgp does this?
> > > >
> > > > Thx!
> > > >
> > > > -Darrell
> > > >
> > > >
> > > > Blogs and organic groups at http://www.ccie.net
> > > >
> > > > _______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
> CCDE #20100007
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Apr 17 2011 - 23:33:11 ART