From: Padhu@xxxxxxxxxxxx
Date: Mon Jul 31 2000 - 01:51:05 GMT-3
Thanks very much guys. After i created the loopbacks,i had messed up the
configs with no update-ource from the loopbacks ..I put in the neighbors
with next hop self and it works great. Appreciate your quick response.
Cheers,padhu
-----Original Message-----
From: Fred Ingham
To: Padhu@steinroe.com; ccielab@groupstudy.com
Cc: pkm@calweb.com
Sent: 7/30/00 10:56 PM
Subject: Re: BGP Synchronization rule - Next hp self
A will need next-hop-self on the neighbor statements to B and
C. C will need next-hop-self on the neighbor statements to A and B.
A,B,C will need no sync per the other reply.
Padhu@steinroe.com wrote:
>
>
> Does the next-hop-self need to be on all IBGP neighbor commands ?
> I have a scneario in test where routers A ,B & C are in AS 100.
> Routers D & E are in AS 200 and 300 respectively.
> A,B& C - FULL IBGP MESH .
> EBGP
> A<------------->D ( 128.10.0.0)
> IBGP
> B C-------->E ( 150.150.0.0)
> EBGP
>
> On rtr-a the neighbor to c has next hop self included
> I have the next hop self on rtr c also...
>
> however A brings in the ip of D as the next hop and that is what is
visible
> in C also for the 128.10 network instead of bringing in the IP of A
itself
> ( Inspite of having the next hop self )..
>
> I did clear ip bgp * and all that ...I am missing something
> here...Appreciate you help on this. Thanks .
>
> Cheers,Padhu
> EBGP
> -----Original Message-----
> From: pkm@calweb.com
> To: Geatti
> Cc: ccielab@groupstudy.com; asafayan@msdinc.com
> Sent: 7/30/00 4:55 PM
> Subject: Re: BGP Synchronization rule
>
> 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
> <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
> <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
> <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
> <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
> <mailto:fred_nielsen@hotmail.com> ]
> ------
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:59 GMT-3