Re: bgp scan-time

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