iBGP is used if an AS wants to act as a transit system to other ASs. You might ask, why can't we do the same thing by learning via eBGP redistributing into IGP and then redistributing again into another AS? We can, but iBGP offers more flexibility and more efficient ways to exchange information within an AS; for example iBGP provides us with ways to control what is the best exit point out of the AS by using local preference.
RTA#
router bgp 100
neighbor 190.10.50.1 remote−as 100
neighbor 170.10.20.2 remote−as 300
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100
neighbor 175.10.40.1 remote−as 400
network 190.10.50.0
RTC#
router bgp 400
neighbor 175.10.40.2 remote−as 100
network 175.10.0.0
Note: An important point to remember, is that when a BGP speaker receives an update from other BGP speakers in its own AS (IBGP), the receiving BGP speaker will not redistribute that information to other BGP speakers in its own AS. The receiving BGP speaker will redistribute that information to other BGP speakers outside of its AS. That is why it is important to sustain a full mesh between the IBGP speakers within an AS.
In the above diagram, RTA and RTB are running iBGP and RTA and RTD are running iBGP also. The BGP updates coming from RTB to RTA will be sent to RTE (outside of the AS) but not to RTD (inside of the AS).
This is why an iBGP peering should be made between RTB and RTD in order not to break the flow of the updates.
