Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

BGP Confederations for IBGP Scaling

 

Understanding BGP Confederations

BGP confederations are another way to solve the scaling problems created by the BGP full mesh requirement. BGP confederations effectively break up a large autonomous system (AS) into subautonomous systems (sub-ASs). Each sub-AS must be uniquely identified within the confederation AS by a sub-AS number. Typically, sub-AS numbers are taken from the private AS numbers between 64,512 and 65,535.

Within a sub-AS, the same internal BGP (IBGP) full mesh requirement exists. Connections to other confederations are made with standard external BGP (EBGP), and peers outside the sub-AS are treated as external. To avoid routing loops, a sub-AS uses a confederation sequence, which operates like an AS path but uses only the privately assigned sub-AS numbers.

The confederation AS appears whole to other confederation ASs. The AS path received by other ASs shows only the globally assigned AS number. It does not include the confederation sequence or the privately assigned sub-AS numbers. The sub-AS numbers are removed when the route is advertised out of the confederation AS. Figure 1 shows an AS divided into four confederations.

Figure 1: BGP Confederations
BGP Confederations

Figure 1 shows AS 3 divided into four sub-ASs, 64517, 64550, 65300, and 65410, which are linked through EBGP sessions. Because the confederations are connected by EBGP, they do not need to be fully meshed. EBGP routes are readvertised to other sub-ASs.

Example: Configuring BGP Confederations

This example shows how to configure BGP confederations.

Requirements

Overview

Within a BGP confederation, the links between the confederation member autonomous systems (ASs) must be external BGP (EBGP) links, not internal BGP (IBGP) links.

Similar to route reflectors, BGP confederations reduce the number of peer sessions and TCP sessions to maintain connections between IBGP routing devices. BGP confederation is one method used to solve the scaling problems created by the IBGP full mesh requirement. BGP confederations effectively break up a large AS into subautonomous systems. Each sub-AS must be uniquely identified within the confederation AS by a sub-AS number. Typically, sub-AS numbers are taken from the private AS numbers between 64512 and 65535. Within a sub-AS, the same IBGP full mesh requirement exists. Connections to other confederations are made with standard EBGP, and peers outside the sub-AS are treated as external. To avoid routing loops, a sub-AS uses a confederation sequence, which operates like an AS path but uses only the privately assigned sub-AS numbers.

Figure 2 shows a sample network in which AS 17 has two separate confederations: sub-AS 64512 and sub-AS 64513, each of which has multiple routers. Within a sub-AS, an IGP is used to establish network connectivity with internal peers. Between sub-ASs, an EBGP peer session is established.

Figure 2: Typical Network Using BGP Confederations
Typical Network Using BGP
Confederations

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

All Devices in Sub-AS 64512

Border Device in Sub-AS 64512

All Devices in Sub-AS 64513

Border Device in Sub-AS 64513

Step-by-Step Procedure

This procedure shows the steps for the devices that are in sub-AS 64512.

The autonomous-system statement sets the sub-AS number of the device.

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure BGP confederations:

  1. Set the sub-AS number for the device.
  2. In the confederation, include all sub-ASs in the main AS.

    The number 17 represents the main AS. The members statement lists all the sub-ASs in the main AS.

  3. On the border device in sub-AS 64512, configure an EBGP connection to the border device in AS 64513.
  4. Configure an IBGP group for peering with the devices within sub-AS 64512.

Results

From configuration mode, confirm your configuration by entering the show routing-options and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Repeat these steps for sSub-AS 64513.

Verification

Confirm that the configuration is working properly.

Verifying BGP Neighbors

Purpose

Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.

Action

From the CLI, enter the show bgp neighbor command.

Sample Output

user@host> show bgp neighbor

Meaning

The output shows a list of the BGP neighbors with detailed session information. Verify the following information:

  • Each configured peering neighbor is listed.

  • For State, each BGP session is Established.

  • For Type, each peer is configured as the correct type (either internal or external).

  • For AS, the AS number of the BGP neighbor is correct.

Verifying BGP Groups

Purpose

Verify that the BGP groups are configured correctly.

Action

From the CLI, enter the show bgp group command.

Sample Output

user@host> show bgp group

Meaning

The output shows a list of the BGP groups with detailed group information. Verify the following information:

  • Each configured group is listed.

  • For AS, each group's remote AS is configured correctly.

  • For Local AS, each group's local AS is configured correctly.

  • For Group Type, each group has the correct type (either internal or external).

  • For Total peers, the expected number of peers within the group is shown.

  • For Established, the expected number of peers within the group have BGP sessions in the Established state.

  • The IP addresses of all the peers within the group are present.

Verifying BGP Summary Information

Purpose

Verify that the BGP configuration is correct.

Action

From the CLI, enter the show bgp summary command.

Sample Output

user@host> show bgp summary

Meaning

The output shows a summary of BGP session information. Verify the following information:

  • For Groups, the total number of configured groups is shown.

  • For Peers, the total number of BGP peers is shown.

  • For Down Peers, the total number of unestablished peers is 0. If this value is not zero, one or more peering sessions are not yet established.

  • Under Peer, the IP address for each configured peer is shown.

  • Under AS, the peer AS for each configured peer is correct.

  • Under Up/Dwn State, the BGP state reflects the number of paths received from the neighbor, the number of these paths that have been accepted, and the number of routes being damped (such as 0/0/0). If the field is Active, it indicates a problem in the establishment of the BGP session.