We have touched on several aspects of Internal BGP (IBGP) in the preceding sections. IBGP is not a separate BGP process that you enable on a BGP speaker.
Instead, IBGP is the term used to refer to all BGP speakers within the same AS.
Since all BGP speakers are under the same administrative authority and are run- ning a common IGP, we use the term IBGP to refer to the relationship each Figure 10.19Synchronization and IBGP
OSPF 1
Router 7 Router 4 Router 2
Router 6
IBGP AS 1
AS 1001
AS 4
AS 3 AS 2
Router 1
AS 4 AS 4
AS 4
Router 5 Router 3
Router 8
speaker has with the others. IBGP requires a full mesh of peering, which may become difficult to manage in a large network. Cisco provides two features to resolve the complexities of a full BGP mesh.These features operate by either grouping a collection of routers with common policies into a common AS using a Route Reflector (RR) and Route Reflector Client (RRC) configuration, or by establishing a Confederation among all BGP speakers in the AS.
Internal BGP
Internal BGP (IBGP) is the term given to BGP speakers within the same AS.
IBGP requires that all BGP speakers in an AS share the same information
regarding network prefixes that reside within the AS, and regarding network pre- fixes learned from neighboring ASs. Furthermore, a BGP speaker will not pass information it learns from IBGP to an EBGP neighbor unless a corresponding prefix exists in the IGP database.This is called synchronization and was discussed in the previous section.
Route Reflectors
We can use Route Reflectors (RR) in a network to assist with the full mesh peering required with IBGP.This concept involves grouping BGP speakers into logical clusters or groups.You should plan your groups along a hierarchical boundary, and this hierarchy should follow the physical topology. If it does not, routing loops can occur because of conflicting information.Therefore, you need to pay close attention to how the Route Reflector Clients (RRC) will get infor- mation from the Route Reflectors.We can think of this as a consistent informa- tion flow from the RRs down to the RRCs. In all cases, consider the redundant links in the network as both an asset and a problem.
Figure 10.20 depicts an IBGP network with twelve routers.The full mesh rule indicates that each of these BGP speakers will have eleven neighbors. In this diagram, there are two peer groups that are each served by two Route
Reflectors.The four Route Reflectors have a full mesh peering to ensure consis- tent information by all RRs. In this case, we are using OSPF as the IGP, and the Route Reflector sessions follow the physical topology.Thus, Routers 3 to 6 have a connection to Router 1 and Router 2, and Routers 9 to 12 have a connection to Router 7 and Router 8.
Confederations
Confederations are used like Route Reflectors to solve the problem of full meshing within a large AS. However, a BGP Confederation does not have the physical topology requirements that exist with Route Reflectors. Confederations divide an AS into subASs and reduce the IBGP peering sessions of each BGP speaker to a manageable number.Within each subAS, a full mesh of IBGP peering is required, and the subAS appears as another AS within the BGP Confederation.The outside world will not see the subASs that reside within the BGP Confederation in the AS_PATH information of a network prefix.Thus, to the outside world, a Confederation is seen as one AS. For this reason, we can implement private AS numbers fairly easily within the Confederation, and use a public registered AS for peering with the Internet or other corporations.The outside world will see only a public AS in the AS_PATH information for all net- work prefixes that originate from within the Confederation.
The subASs communicate using EBGP peering sessions. However, routing within the Confederation behaves like IBGP, since the NEXT_HOP, MED, and LOCAL_PREF values are preserved when crossing a subAS boundary. It should be noted that migrating from a non-BGP Confederation configuration to a Confederation network requires major reconfiguration.Therefore, the implemen- tation should be carefully planned in an existing BGP network. Also, routing Figure 10.20Route Reflector Design and Function
OSPF 1
IBGP
AS 1001
IBGP
RR Peer Group 1
RR Peer Group 2
IBGP
Router 9 RRC Router 10
RRC
Router 11 RRC Router 12 Router 8 RRC
RR Router 7
RR RR Sess.
RR Sess.
RR Sess.
RR Sess.
IBGP
Router 2 RR Router 1 Router 3 RR
RRC
RR Sess.
RR Sess.
RR Sess.
RR Sess.
Router 4 RRC
IBGP Router 5
RRC Router 6
RRC
RR Sess.
through the Confederation often takes less than optimal network paths.
Therefore, you should make a careful review of the IP flow through the network and perhaps set some BGP policies to prevent this situation.
Figure 10.21 depicts a simple Confederation configuration. In this example, AS 1001 is split into two subASs, namely, AS 65500 and AS 65501, respectively.
Routing within AS 65500 and AS 65501 follows the rules of IBGP with a full mesh. Since the NEXT_HOP value is not modified between subASs, the IGP must provide an appropriate route.With this network, we have two peering con- nections to the Internet via a single Service Provider (SP). In the future, we can add connections to a different SP using Router 2 and Router 8.We would then have SP redundancy to the Internet.