transmit prefix from one AS to another AS within the AS
(loop protection inside AS)prefix learned from an iBGP peer can not be advertised to the other IBGP peer .
this solution requires that all iBGP speakers be fully meshed.
In an AS that has a large number of iBGP speakers, a full mesh can present a scalability issue.
Solutions to this issue involving route reflection(RR) and confederation
An IGP is definitely required. In Figure 2-2, R3 is not directly connected to R6. How will R3 form an iBGP session without some form of routing information to reach R6? The answer is to have an IGP provide infrastructure reachability inside the autonomous system. Internal BGP was never designed to exist without an IGP, but in conjunction with an IGP. An iBGP route is often recursively resolved using an IGP. Comparison of iBGP and IGP
| IGP | iBGP |
|---|---|
| Changes a prefix’s next hop at each router to point to a directly connected address. | Does not change a prefix’s next-hop attribute. |
| Automatically discovers and forms neighbor relationships. | Requires manual configuration. |
| Provides information about how to traverse a given AS or reach a given location. | Provides information about what is available at a location, without indicating how to reach it. |
Comparison of iBGP and eBGP
| iBGP | eBGP |
|---|---|
| Peering inside an AS must consist of a full mesh, because an iBGP speaker is not allowed to pass on prefixes learned from one iBGP peer to another iBGP peer. | Has no full-mesh requirement. |
| Advertises the LOCAL_PREF attribute,which eBGP does not. Does not modify the next hop and AS_PATH. Next-hop reachability within the AS is provided by an IGP. | Modifies next-hop and AS_PATH attributes. |
| Does not require direct connectivity, because iBGP uses an IGP to allow reachability to a remote next hop. | Requires direct connectivity by default. In almost all cases, a common IGP is not shared between eBGP peers. Cisco IOS software provides a workaround to this requirement with the use of eBGP multihop. |
| Requires prefix synchronization between iBGP and IGP to prevent routing loops and black-holing of traffic.Prefix synchronizationmeans that a prefix learned via iBGP is not included in the best-path selection unless that same prefix exists in the IGP. If the IGP is OSPF, the router ID for the prefix in the IGP must also match the router ID of the BGP peer advertising the prefix.Synchronization may be disabled if this AS does not provide transit for another AS or if all routers in the transit path are running BGP. It is generally a good practice to disable prefix synchronization. | Has no synchronization requirement. |
| Routes from iBGP are not redistributed into an IGP by default, even if the redistribution from BGP into the IGP is configured, because this could result in routing loops. If it is mandatory that iBGP prefixes be redistributed into an IGP, IOS provides thebgp redistribute-internalcommand. | Has no such restriction. |
Path Decision Process