IBGP Full Mesh, Route Reflectors, and Confederation

In contrast to most fellow authors, I would like to start the BGP discussion with Internal BGP (IBGP). This and all subsequent labs use OSPF as the underlying IGP to provide the necessary connectivity that BGP requires for both session establishment and proper signaling operation. We will start with a manually configured full-mesh IBGP setup and gradually move to a more elegant configuration with the use of peer groups and route reflectors. Confederation as an alternative approach to overcome the scalability limits of full-meshed IBGP is demonstrated as well. In the course of the discussion, we will look at the finite state engine (FSM) and examples of the OPEN and UPDATE messages passed between BGP speakers.

The BGP specifications dictate (for loop-prevention purposes) that a BGP speaker must not advertise prefixes heard from another IBGP speaker to a third IBGP speaker. Because of this convention, you must configure a full-mesh between all IBGP speakers within an AS. Obviously, this approach does not scale. Fortunately, BGPv4 provides two ways to approach this problem?route reflectors and confederation?in various possible setups and combinations:

• Single route reflector (not recommended, single point of failure)

• Clustered route reflectors

• Redundant route reflectors

• Confederation ("EIBGP")

• Hybrid architectures (route reflector cluster and confederation)