BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of
peers increases. The number of IBGP sessions increases rapidly with the number of routers:

BGP provides two alternative configuration strategies to reduce the number of fully meshed peers.

You can either:

  • Configure confederations.
  • Configure route reflectors.

Both of these strategies are complex and can create their own problems. Neither strategy is typically
used unless the mesh of IBGP peers approaches 100 sessions per peer.

Configuring a Confederation

IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh
inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed
internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the
point that each router has about 100 peering sessions.

AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown).
Border router Salem has an EBGP session with a neighbor in AS 325.
Border router Boston hasan EBGP session with a neighbor in AS 413.

 

Illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of
peering sessions. According to common practice, use a number from the private range of AS numbers

—from 64512 to 65535—to identify each sub-AS. AS 29 is now a confederation of
three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers.

A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS
because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries.
To the external neighbors, AS 29 appears the same as it ever was.

The following commands partially configure router Salem:

router bgp 64720
bgp confederation identifier 29
bgp confederation peers 64721 64722
neighbor 10.2.25.4 remote-as 64720
neighbor 10.2.25.8 remote-as 64721
neighbor 10.2.25.2 remote-as 325

The bgp confederation identifier command establishes router Salem as a member of Confederation 29.
The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members
of the same confederation as the sub-AS that includes router Salem.

The neighbor remote-as commands specify the IBGP connection with a neighbor in sub-AS 64720
and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325.

Similarly, the following commands partially configure router Harvard:

router bgp 64721
bgp confederation identifier 29
bgp confederation peers 64720 64722
neighbor 10.2.25.7 remote-as 64720 

From router Newport’s perspective, router Salem is simply a member of AS 29:

router bgp 325
neighbor 10.2.25.6 remote-as 29

From router Mason’s perspective, router Boston is simply a member of AS 29:

router bgp 413
neighbor 10.3.3.2 remote-as 29

 

   bgp confederation identifier

  • Use to establish a router as a member of the specified BGP confederation.
  • To systems outside the confederation, the confederation appears as an autonomous system
    with an AS number the same as the confederation identifier.
  • The new confederation identifier is used in open messages and in the AS path in update messages
    that are sent after you issue the command.

To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear.

    bgp confederation peers

  • Enables EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref,
    MED, and next-hop attributes.
  • You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword
    and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers.
  • If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the
    filter list, then the peer is considered to be in the same confederation.
  • This command takes effect immediately and bounces only those sessions whose peer type
    changed as a result of issuing the command.