From: Joseph D. Phillips (josephdphillips@fastmail.us)
Date: Sun Jul 25 2004 - 03:07:10 GMT-3
Thanks very much.
On Sat, 24 Jul 2004 23:43:37 -0400, "James" <james@towardex.com> said:
> On Sat, Jul 24, 2004 at 08:12:37PM -0700, Joseph D. Phillips wrote:
> > I notice in a couple places, Karl Solie and Leah Lynch, in CCIE
> > Practical Studies II, use a static route to null 0 in order to make sure
> > that a local network advertises properly to a BGP peer.
>
> What Karl and Leah had done is mostly done in real-world environment,
> where it
> is recommended that an AS always null-route w/ high A.D. their aggregate
> to
> prevent route-looping up to whomever they have default-route or less
> specific
> route pointed to (also to stabilize their BGP announcements when their
> internal
> IGP or connected interfaces holding the announced routes begin flapping).
> This
> seems like to be a BCP amongst most people doing BGP.
>
> > For example, on page 805, there is an explicit advertisement of the
> > 191.19.42.0/24 net within BGP, and just to be on the "safe" side, they
> > added: ip route 191.19.42.0 255.255.255.0 null0 253
> >
> > I understand the need for a high administrative distance on the static
> > route, but is this kind of route allowed in the lab exam?
>
> Since it is statically/manually configured, IMHO it constitutes static
> route.
> So I think it is safer to stay away from doing that in lab unless you are
> permitted to do so.
>
> >
> > Is it one of those real world things we're not allowed to do on lab day?
>
> Sounds like it. :)
>
> Since BGP scans rib before announcing a prefix, the only course of action
> w/o
> null route is probably to create loopbacks and assign addrs there..
>
> -J
>
>
> --
> 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 : Sun Aug 01 2004 - 10:12:02 GMT-3