Re: BGP question

Correct Rakesh.

Just to add to split horizon rule debate:

Split Horizon for *iBGP* governs decision from a senders perspective. Here
is an excerpt from article 9.2 of the standard:
* "When a BGP speaker receives an UPDATE message from an internal peer,
   the receiving BGP speaker SHALL NOT re-distribute the routing
   information contained in that UPDATE message to other internal peers
   (unless the speaker acts as a BGP Route Reflector [RFC2796])."*
Which is basically saying if you received it from iBGP, do not send it to
any other iBGP. We all know how to override this using manual techniques
(manual meaning we need to define where the updates will be redistributed),
but this is a principal rule.

Split horizon for *eBGP* is applied from the receivers perspective. This is
from article 9.1.2 of the standard:
* "If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function. AS loop
   detection is done by scanning the full AS path (as specified in the
   AS_PATH attribute), and checking that the autonomous system number of
   the local system does not appear in the AS path."*
This also implies that sender can send an update to eBGP peer, even if that
peer will most likely discard the route because of AS_PATH loop.
Interestingly, due to optimization techniques Cisco does that alot, and it's
perfectly within the standards.

Here is another general rule from the standard, but it refers to route
ORIGINATION, meaning router creates a route, using one of the available
methods (network command, redistribution, conditional injection, etc)
* "A route originated by a BGP speaker SHALL NOT be advertised to a peer
   using an address of that peer as NEXT_HOP. A BGP speaker SHALL NOT
   install a route with itself as the next hop."*

On Thu, Apr 9, 2009 at 4:11 AM, rakesh m <raaki.88_at_gmail.com> wrote:

> as per the definition of bgp split horizon
>
> updates coming from the neighbor cannot be forewarded to other ibgp
> neighbors
>
> > the solution for this would be configuring full mesh topology ibgp
> neighbor relationship or using
> route - reflectors are mentioned ...
>
> here nothing is mentioned about the two ebgp neighbor relations ships nor
> routing table
>
> bgp sync rule :
>
>
> if updates received from ibgp neighbor , it cannot be used in routing
> table
> nor send to other ebgp neighbor till same update come from an igp
>
> there is clearly a difference as far as i see ..
>
> the concept of route-reflector =! concept of synchronaisation
>
>
> practically you can run a bgp network without a igp and still using
> route-reflectors doing trick for you ..
>
> correct me if iam wrong guys
>
> guday
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net