Hello Behzad,
the issue is originated by the fact that in iBGP sessions the AS path attribute is not modified when propagating an advertisement to another iBGP peer. Actually only when sending the advertisement to an eBGP peer the AS number of the BGP speaker is added to the AS path attribute (in first position).
This behaviour has the potential for loops in the propagation of the advertisement that can travel among several iBGP peers and could be sent back to the original node that injected the route in the AS.
The real problem arises if the originator node withdraws the BGP advertisement, in absence of control mechanisms the node could be fooled by a copy of advertisement received by another node and re-advertise the just withdrawed IP prefix.
As a result in the AS there would still be present an advertisement for a prefix that is not existing anymore.
For this reason an iBGP speaker cannot propagate advertisements received by an iBGP peer RX to any other iBGP peer.
This mechanism is built in BGP and cannot be disabled for the reasons explained above.
The most important consequence is the requirement for a full mesh of iBGP sessions that leads to scalability problems, because given N iBGP nodes N*(N-1)/2
iBGP sessions would be required.
In order to avoid the full mesh scalability problems two different methods (that might be combined) have been developed.
Both methods allow for relaxing iBGP split horizon rule by adding other BGP attributes to keep track of history of advertisement within the AS.
BGP Route Reflectors: these special nodes act as route servers by reflecting advertisements received by client nodes (as defined on RR side only).
Reflection is safe because the RR adds two attributes to the advertisement :
- BGP originator-id contains the 4 byte BGP router-id of the node that has injected the prefix into the AS
- BGP cluster-list contains an ordered list of route reflection, The list is formed by RR BGP router-ids and/or by cluster-ids. (a cluster-id is a sort of identifier to be used when two or more RRS serve the same set of client nodes).
These two new attributes allow for safe propagation of routes within the AS:
all RRS need to be in full mesh between themselves, but most of nodes in the AS don't need anymore a direct session. This solves the scalability issue.
When an advertisement is received the two attributes are checked:
BGP originator-id allows to the node that has the BGP router-id = BGP originator-id to ignore the advertisement
BGP cluster list allows to a RRS to ignore an advertisement if the cluster list already contains its own cluster-id (that might be equal to its own BGP router-id if a cluster id is not set explicitly in RRS BGP configuration)
The second method to overcome scalability issues is the use of BGP confederations:
in this case the AS is divided in several mini AS each with its own private AS number.
These private AS numbers of mini AS are used to build the Confed AS path attribute that allows to use EBGP rules for loop avoidance. This attribute is separate from main AS path attribute and when a node has a true eBGP session with a router in outer world the following happens:
the Confed AS attribute is removed
the main AS attribute is modified adding the ufficial AS number in front (leftmost /first position) before sending to true eBGP peers.
Within each mini AS Route reflection could be use combining the two methods.
This second method requires configuration changes in all nodes in the AS. RR requires changes only on devices acting as RR servers.
So in most cases the first method is deployed.
Hope to help
Giuseppe
