BGP Route Reflectors and Confederations - part3
This is part 3 of 4. My shortish summarized version of Cisco BGP Route Reflectors and Confederations.
Route Reflectors:
iBGP MUST have full mesh to prevent loops, thus to scale, you can use Route Reflectors.
- Clients must have full mesh connection to Route-Reflectors.
- Route Reflector groups add a cluster-id attribute to routes.
Route Reflectors process updates as follows:
- Routes learned from eBGP peers: Sent to all iBGP, eBGP, Clients and Non-Client peers.
- Routes learned from iBGP (non-client) peers: Sent to all eBGP and Client peers.
- Routes learned from iBGP (client) peers: Sent to all peers except sender.
Example Route Reflector Client Setup (No client-side setup needed):
1
|
|
Example Route Reflector Cluster Setup:
1 2 |
|
Confederations:
Another way to solve the iBGP full mesh problem is to use Confederations.
- An AS inside an AS
- Uses INTRA-AS numbers which are stripped before sending updates via eBGP.
- Inter-Confederation peers are treated as eBGP to establish, but as iBGP relating to attributes.
- Public AS split into smaller Sub Autonomous Systems (Sub-ASs).
- Breaks iBGP AS into smaller Autonomous Systems.
- Typically use private AS numbers (64512 – 65535)
- Full iBGP mesh required within confederation AS / Sub-AS (RR also an option within confederation)
Example:
1 2 3 4 5 6 7 8 9 10 11 |
|