Overview
Details BGP confederation peerings, addressing their limitations and offering procedures for configuring BGP peering relationships within a confederation environment.
A BGP confederation peering is a routing relationship within a BGP confederation that
-
enables routers in different sub-autonomous systems (sub-AS) of the same confederation to exchange routing information
-
allows specific route advertisements using iBGP while circumventing standard iBGP full mesh requirements, and
-
provides mechanisms to override the split horizon rule and control route learning between peer routers.
Autonomous system (AS)
An autonomous system is a collection of routers under a single administrative domain that use Interior Gateway Protocols (IGPs) for internal routing and Exterior Gateway Protocols (EGPs), such as BGP, for inter-domain communication.
Sub-autonomous system (sub-AS)
A sub-autonomous system is a distinct subset within a larger autonomous system, with its own administrative control and routing policies. Sub-ASs are used within BGP confederations to simplify iBGP mesh requirements.
Confederation
A BGP confederation divides a single large AS into multiple sub-ASs, reducing the iBGP mesh. Externally, the confederation appears as a single AS, while internally it consists of multiple sub-ASs. Routers within different sub-ASs peer using eBGP, but exchange routing information similar to iBGP sessions, preserving BGP path attributes.
Autonomous System Number (ASN)
The ASN uniquely identifies each autonomous system or sub-autonomous system in BGP routing.
Split horizon
Split horizon is a BGP routing rule that prevents a router from advertising a route back into the sub-AS (or confederation) from which it was learned, thereby preventing routing loops.
| Feature Name |
Release Name |
Description |
|---|---|---|
| Peering Between BGP Routers Within the Same Confederation | Release 25.4.1 | Introduced in this release on: Fixed Systems (8700 [ASIC: K100])(select variants only*) *This feature is supported on Cisco 8711-48Z-M routers. |
| Peering Between BGP Routers Within the Same Confederation | Release 7.11.1 | You can now enable BGP peering between routers in the sub-autonomous system (AS) within a confederation to advertise specific router updates using iBGP. This capability ensures that the mesh of routers between sub-ASes in a confederation maintains consistent routing tables, ensuring proper network reachability. Enabling this feature helps improve preventing performance reduction and traffic management challenges. The feature introduces these changes: CLI: YANG Data Models
(see GitHub, YANG Data Models Navigator) |
Challenge of full iBGP mesh in large networks
In large-scale networks, maintaining a full iBGP mesh within an autonomous system becomes impractical as the number of routers increases.
Role of BGP confederations
BGP confederations allow a single AS to be partitioned into multiple sub-ASs, each of which maintains a full iBGP mesh internally. Routers in different sub-ASs establish eBGP-like sessions (called confederation peerings), but inside the confederation, the attributes of iBGP are preserved.
Impact of the split horizon rule
By default, the split horizon rule prevents routers in the same confederation from learning routes from one another if the route originated within the confederation.
Breaking split horizon
In scenarios requiring increased route flexibility or network customization, it may be necessary to break the split horizon rule. The allowconfedas-in command enables routers to bypass this restriction, allowing selected routes to be learned by peer routers within the confederation, and providing granular control over the number of times a route may be re-accepted within the confederation.
Example
In this sample topology, Router PE1 and Router PE2 are both part of a BGP confederation but belong to different sub-ASs (for example, PE1 in sub-AS 100, PE2 in sub-AS 20). The CE router advertises the route 10.10.10.0/24 to PE1, which then advertises it to the ISP router (AS 500). The ISP router then passes the route to PE2. PE2 sees the confederation's AS numbers in the AS_PATH and, by default, drops the route due to the split horizon rule. To permit route learning in this scenario, configure the allowconfedas-in command on both PE1 and PE2. This allows PE2 to accept the 10.10.10.0/24 prefix from PE1, even though both routers are in the same confederation.