From: Kevin Baumgartner (kbaumgar@xxxxxxxxx)
Date: Tue Aug 01 2000 - 13:57:56 GMT-3
Alan
Totally agree with you on not waiting too long between exams.
I basically took the 1st lab test to see what it was like and didn't
expect to pass. Then with work commitments, I had to reschedule
the second attempt a number of times. It ended up that it was over
a year from the 1st attempt. And in someways I felt less prepared
then the first attempt. Didn't do that much better on the second attempt.
I have been practicing a lot of different senarios in the last 6 months
and feel a lot better prepared than the first two attempts. This seems to
be the key to passing the test, along with time management.
Kevin
At 10:43 AM 7/31/00 -0700, you wrote:
>Hello All, my name is Alan Simpkins. I will be taking
>my 4th swing at the lab at the end of Nov. I have
>taken it in San Jose twice, and most recently at RTP
>(Bad Idea). Here are a couple thoughts:
>
>1. Don't wait too long between exams, I waited a yr
>between 2nd, and 3rd.
>
>2. Practice BGP as if No sync is not an option, it
>probably will not be allowed.
>
>Regards
>
>Alan Simpkins
>CCNP, CCDP, BNCHS, and NNCSS
>
>--- pkm@calweb.com wrote:
> > Based on my lab experiences with BGP, I do not think
> > that fully IBGP
> > speakers is a requirement. Let's say that al your
> > router inside your
> > transit AS are only BGP speakers and there is no IGP
> > runnning. You will
> > still have to use the NO SYNCH command on the IBGP
> > speakers, regardless
> > of having full IBGP mesh topology. If no synch is
> > used, the network will
> > not appear in the route table even if it in the BGP
> > route table. There
> > is a good example on the Cisco web site at :
> > http://www.cisco.com/warp/public/459/14.html (BGP
> > Case study Section 2):
> > http://www.cisco.com/warp/public/459/14.html#A15.0.
> > Also, the book All
> > in oneCCIE lab study guide has good examples of the
> > no synch rule.
> > Also, for the CCIE lab, it is most likely that you
> > will have to apply
> > the next-hop-self statement to the transit AS. The
> > combination of these
> > two commands (next-hop-self and no synch) allows the
> > BGP route table to
> > show up in the IP route table of the IBGP speakers
> > correctly. See all in
> > one CCI Elab study guide. http://www.mentortlabs.com
> > has a good lab
> > demonstrated the issues with no synch and
> > next-hop-self in a NBMA
> > network.
> >
> > Sincerely,
> >
> > Phillip
> >
> >
> >
> > Geatti wrote:
> >
> > > Fred,The sync rule basically says in order to
> > advertise a route it
> > > needs to be in the RIB (Routing information base)
> > and the routing
> > > table. Turning sync off via the "no sync" command
> > will allow you to
> > > advertise a given route without it being learned
> > via IGP first. Now
> > > most people would say, why on earth would you want
> > to redistribute all
> > > the routes learned via EBGP into IGP, that would
> > be crazy yeah? And
> > > you would be right. Running no sync with IBGP
> > routers is the way to
> > > go.However to run no sync you must meet one of the
> > following
> > > criteria....a. you must be fully meshed IBGP
> > within your AS. ORb.
> > > you are a stub network - not transit. The reason
> > for the sync rule is
> > > to prevent a packet arriving into your AS
> > destined for another AS
> > > (meaning you are transit) getting to a router
> > within your AS that does
> > > not know what to do with it. If you are running
> > sync with IGP this
> > > would not matter as you would have a IGP route to
> > the external
> > > destination. If you are not in sync as soon as
> > your packet hits the
> > > router it won't know how to handle it, doesn't
> > have an IGP route to
> > > the destination nor is it running IBGP, it won't
> > have a route to that
> > > external AS, the packet is dropped.The sync rule
> > says that IGP must be
> > > synchronized with BGP routes, this is not
> > practical in most cases.
> > > Therefore make sure that when you use no sync on
> > all routers within
> > > you AS that you are fully meshed via IBGP or using
> > something like
> > > route reflectors to make appear so. If you are
> > fully meshed via IBGP
> > > there is no need to be sync.Sync does require you
> > to have an exact
> > > match I believe, 10.0.0.0 /8 does not catch
> > 10.10.10.0 /24 and
> > > 10.5.0.0 /16. An exact match is necessary.Hope
> > this is of some
> > > helpMarco-----Original Message-----
> > > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com]On Behalf Of
> > > Fred Nielsen
> > > Sent: Saturday, July 29, 2000 8:51 PM
> > > To: ccielab@groupstudy.com
> > > Subject: BGP Synchronization rule
> > >
> > >
> > > I would like to hear the opinions of the
> > group on the
> > > synchronization rule, which states
> > *something* like: a BGP
> > > router will not forward an externally learned
> > route to
> > > another external peer until the route is also
> > present in
> > > that router's IGP as well. The Halabi book
> > touches on this,
> > > but didn't spend enough time for me to really
> > understand the
> > > intent behind the rule, other than to prevent
> > routing loops
> > > inside an AS. Because many typical
> > configurations out there
> > > do not redist BGP routes into IGP's, you see
> > the "no
> > > synchronization" command employed fairly
> > often. Why is sync
> > > turned on by default in the IOS? Is it part
> > of the
> > > specification perhaps? Also, referring to
> > "external peer"
> > > above, this really means separate router
> > entities running
> > > IBGP within an AS, right? Not between EBGP
> > peers, where the
> > > rule doesn't apply.. And one more question,
> > does the IGP
> > > route have to match precisely, or can a less
> > specific route
> > > do the trick? In other words, can the
> > presence of
> > > 10.0.0.0/8 in the IGP allow BGP to forward a
> > 10.1.0.0/16
> > > route? Hoping all this makes sense.------
> > > Fred Nielsen [fred_nielsen@hotmail.com]
> > > ------
> > >
> >
>
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:20 GMT-3