04-06-2009 06:50 AM
04-06-2009 07:31 AM
Omar,
There is a rule in BGP that prevents a BGP peer to advertise an update to a iBGP peer if this same update has been received via iBGP. This rule is there to avoid routing loops inside a single AS. Before RFC1966, this restriction forced all bgp peers within the same AS to be fully meshed. RFC1966 defined the concept of route reflection to relax this restriction.
Please refer to RFC 1966 to learn more about how route reflection solves the routing loop issue.
http://www.ietf.org/rfc/rfc1966.txt?number=1966
Regards
04-06-2009 01:15 PM
Hello Omar,
the BGP route reflector feature allows to relax the need for a full mesh by providing some fields (BGP attributes indeed) that allow to detect a routing loop within a single AS:
the Originator-Id contains the BGP router-id of the router that originated an advertisement
the Cluster-list provides a list of all the "reflections" that an advertisement has experienced: it is made as a list of BGP router-ids of BGP route-reflectors (or of cluster-ids that have the same form of dotted decimal)
In this way a router in receiving different "copies" of the same advertisement can decide what info is more reliable.
And BGP route reflector servers can realize that there is no need to propagate an advertisement that has already been "reflected" by the twin reflector (the same cluster-id)
All starts from the fact that the AS path attribute is not modified within a single AS domain.
So somewhat similar mechanisms to trace the story of an advertisement inside an AS has been introduced with BGP route reflectors.
Hope to help
Giuseppe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide