8.3 Configuring BGP 
8.3.7 How to maintain BGP continuity inside an AS
BGP does not advertise routes learned via IBGP peers to other IBGP peers. If it did, BGP routing inside the AS would present a dangerous potential for routing loops. For IBGP routers to learn about all BGP routes inside the AS, they must connect to every other IBGP router in a full IBGP mesh. This full mesh needs to be only logical, not physical. In other words, as long as the IBGP peers can connect to each other using TCP/IP, you can create a logical full mesh even if the routers are not directly connected.

The figure illustrates one of the common mistakes that administrators make when setting BGP routing within an AS. This ISP network has three POPs: San Jose, San Francisco, and Los Angeles. Each POP has multiple non-BGP routers and a BGP border router running EBGP with other autonomous systems. The administrator has set up an IBGP connection between the San Jose border router and the San Francisco border router, and another IBGP connection between the San Francisco border router and the Los Angeles border router. In this configuration, EBGP routes learned via San Jose are given to San Francisco, EBGP routes learned via San Francisco are given to San Jose and Los Angeles, and EBGP routes learned via Los Angeles are given to San Francisco.

However, routing in this scenario is not complete. EBGP routes learned via San Jose will not be given to Los Angeles, and EBGP routes learned via Los Angeles will not be given to San Jose. This is because the San Francisco router will not advertise IBGP routes between San Jose and Los Angeles. What is needed is an additional IBGP connection between San Jose and Los Angeles (shown in the figure as a dotted line). You will see in Chapter 9 how this situation could be handled by using the concept of route reflectors, an option that scales much better when the AS has a large number of IBGP peers.

The following section discusses the synchronization issues that must be addressed when running IBGP within an AS.