|
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.
|