Re: BGP Synchronization rule

From: pkm@xxxxxxxxxx
Date: Tue Aug 01 2000 - 19:48:58 GMT-3


   
   Yes correct. Inside your AS. Check the lab and the book/documentation
   I recommended. Obviously, BGP was developed to allow routing among
   automous system but in the case of IBGP, you have either the choice to
   redistribute BGP into IGP (not recommended) or use the no
   synchronization command. BGP always check the IP routing table for
   validity of a route. BGP and IGP need to be synchronized, which is on
   by default. To bypass this, use the no synch. command inside your IBGP
   routers.
   
   Sincerely,
   
   Phillip Moulay
   
   Fred Nielsen wrote:
   
      Thanks for everyone's input, good stuff all. Phillip mentions a
     point below that I am was a little stumped on for a while also, not
     only will a router not forward a route but the route won't even
     make it to the router's local routing table without "no sync" or an
     IGP route in place. ------
     Fred Nielsen [fred_nielsen@hotmail.com]
     ------
     
   ----- Original Message -----
   From: pkm@calweb.com
   To: GeattiCc: ccielab@groupstudy.com ; asafayan@msdinc.comSent:
   Sunday, July 30, 2000 2:55 PMSubject: 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 (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