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 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.
Configure network interfaces.
Configure external peer sessions. See Example: Configuring External BGP Point-to-Point Peer Sessions.
Configure interior gateway protocol (IGP) sessions between peers.
Configure a routing policy to advertise the BGP routes.
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.
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  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
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:
- Set the sub-AS number for the device.[edit routing-options]user@host# set autonomous-system 64512
- In the confederation, include all sub-ASs in the main
The number 17 represents the main AS. The members statement lists all the sub-ASs in the main AS.[edit routing-options confederation]user@host# set 17 members 64512user@host# set 17 members 64513
- On the border device in sub-AS 64512, configure an EBGP
connection to the border device in AS 64513.[edit protocols bgp group to-sub-AS-64513]user@host# set type externaluser@host# set neighbor 192.168.5.2user@host# set peer-as 64513
- Configure an IBGP group for peering with the devices within
sub-AS 64512.[edit protocols bgp group sub-AS-64512]user@host# set type internaluser@host# set local-address 192.168.5.1user@host# neighbor 192.168.8.1user@host# neighbor 192.168.15.1
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.
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.
From the CLI, enter the show bgp neighbor command.
user@host> show bgp neighbor
Peer: 10.255.245.12+179 AS 35 Local: 10.255.245.13+2884 AS 35 Type: Internal State: Established (route reflector client)Flags: Sync Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: Preference LocalAddress HoldTime Cluster AddressFamily Rib-group Refresh Address families configured: inet-vpn-unicast inet-labeled-unicast Local Address: 10.255.245.13 Holdtime: 90 Preference: 170 Flags for NLRI inet-vpn-unicast: AggregateLabel Flags for NLRI inet-labeled-unicast: AggregateLabel Number of flaps: 0 Peer ID: 10.255.245.12 Local ID: 10.255.245.13 Active Holdtime: 90 Keepalive Interval: 30 NLRI advertised by peer: inet-vpn-unicast inet-labeled-unicast NLRI for this session: inet-vpn-unicast inet-labeled-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 300 Stale routes from peer are kept for: 60 Restart time requested by this peer: 300 NLRI that peer supports restart for: inet-unicast inet6-unicast NLRI that restart is negotiated for: inet-unicast inet6-unicast NLRI of received end-of-rib markers: inet-unicast inet6-unicast NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast Table inet.0 Bit: 10000 RIB State: restart is complete Send state: in sync Active prefixes: 4 Received prefixes: 6 Suppressed due to damping: 0 Table inet6.0 Bit: 20000 RIB State: restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 2 Suppressed due to damping: 0 Last traffic (seconds): Received 3 Sent 3 Checked 3 Input messages: Total 9 Updates 6 Refreshes 0 Octets 403 Output messages: Total 7 Updates 3 Refreshes 0 Octets 365 Output Queue: 0 Output Queue: 0 Trace options: detail packets Trace file: /var/log/bgpgr size 131072 files 10
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
Verify that the BGP groups are configured correctly.
From the CLI, enter the show bgp group command.
user@host> show bgp group
Group Type: Internal AS: 10045 Local AS: 10045 Name: pe-to-asbr2 Flags: Export Eval Export: [ match-all ] Total peers: 1 Established: 1 10.0.0.4+179 bgp.l3vpn.0: 1/1/0 vpn-green.inet.0: 1/1/0 Groups: 1 Peers: 1 External: 0 Internal: 1 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 1 1 0 0 0 0
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
Verify that the BGP configuration is correct.
From the CLI, enter the show bgp summary command.
user@host> show bgp summary
Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 6 4 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65002 88675 88652 0 2 42:38 2/4/0 0/0/0 10.0.0.3 65002 54528 54532 0 1 2w4d22h 0/0/0 0/0/0 10.0.0.4 65002 51597 51584 0 0 2w3d22h 2/2/0 0/0/0
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.