Understanding BGP Session Types and Behavior

iBGP Scalability Enhancements

The inability of BGP to advertise a prefix learned from one iBGP peer to
another iBGP peer leads to scalability issues in an AS. The formula n(n −
1)/2 provides the number of sessions required, where n represents the
number of routers. A full mesh topology of 10 routers requires 45 sessions.
Route Reflectors - RFC 1966 introduces the idea that an iBGP peering can
be configured so that it reflects routes to another iBGP peer. The router that
is reflecting routes is known as a route reflector (RR), and the router that is
receiving reflected routes is a route reflector client. Route reflectors and
route reflection involve three basic rules:
• Rule 1 - If an RR receives an NLRI from a non-RR client, the RR
advertises the NLRI to an RR client. It does not advertise the NLRI to a
non-RR client.
• Rule 2 - If an RR receives an NLRI from an RR client, it advertises the
NLRI to RR clients and non-RR clients. Even the RR client that sent the
advertisement receives a copy of the route, but it discards the NLRI
because it sees itself as the route originator.
• Rule 3 - If an RR receives a route from an eBGP peer, it advertises the
route to RR clients and non-RR clients.
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1
Understanding BGP Session Types and Behavior
Route Reflector Configuration
Only route reflectors are aware of the change in behavior because no additional BGP configuration is performed
on route reflector clients. BGP route reflection is specific to each address family. The neighbor ip-address
route-reflector-client command is used under the neighbor address family configuration.
Figure 11-17 shows a simple iBGP topology. R1 is a route reflector
client to R2, and R4 is a route reflector client to R3. R2 and R3
have a normal iBGP peering.
Example 11-15 shows the BGP configuration for R1, R2, R3, and
R4. R1 and R2 are configured with the default IPv4 address family
enabled, and R3 and R4 have the default IPv4 address family
disabled. The neighbor ip-address route-reflector-client is
configured only on R2 and R3. R1 explicitly advertises the
10.1.1.10/24 network with a network statement.

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
Understanding BGP Session Types and Behavior
Route Reflector Configuration (Cont.)
Figure 11-18 shows the topology with the route reflector
and route reflector client roles to demonstrate the rules of
a route reflector in action.

R1 advertises the 10.1.1.0/24 prefix to R2 as a normal

iBGP advertisement. R2 receives and advertises the
10.1.1.0/24 prefix using the route reflector rule 2 as just
explained to R3 (a non-route reflector client). R3 receives
and advertises the 10.1.1.0/24 using the route reflector
rule 1 as explained to R4 (a route reflector client).
Example 11-16 shows the BGP table for the
10.1.1.0/24 prefix. Notice that the next-hop IP
address changes upon the route’s installation into
R2’s BGP table, but it remains the same on R2,
R3, and R4.
Notice the i immediately after the best path
indicator (>) on R2, R3, and R4. This indicates
that the prefix is learned through iBGP.
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3
Understanding BGP Session Types and Behavior
Loop Prevention in Route Reflectors
When RFC 1966 was drafted, two other BGP route reflector–specific attributes were added to prevent loops.
ORIGINATOR_ID: This optional non-transitive BGP attribute is created by the first route reflector and sets the
value to the RID of the router that injected/advertised the route into the AS. If the ORIGINATOR-ID is already
populated on an NLRI, it should not be overwritten. If a router receives an NLRI with its RID in the Originator
attribute, the NLRI is discarded.
CLUSTER_LIST: This non-transitive BGP attribute is updated by the route reflector. This attribute is appended
(not overwritten) by the route reflector with its cluster ID. By default, this is the BGP identifier. If a route reflector
receives an NLRI with its cluster ID in the Cluster List attribute, the NLRI is discarded.
Example 11-17 shows all the BGP path attributes for the prefix 10.1.1.0/24 on R4. Notice that the originator and
cluster fields are populated appropriately for the prefix.

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 4
Understanding BGP Session Types and Behavior
Confederations
RFC 3065 introduced the concept of BGP
confederations as an alternative solution to the
iBGP full mesh scalability issues shown earlier. A
confederation consists of member ASs that
combine into a larger AS known as an AS
confederation.
Figure 11-19 demonstrates a BGP confederation
with the confederation identifier AS200. R3
provides route reflection in member AS 65100.
Follow these steps to configure a BGP confederation:
Step 1. Initialize the BGP process with the global command router bgp member-asn.
Step 2. Identify the BGP confederations with the command bgp confederation identifier as-number.
Step 3. On routers that directly peer with another member AS, identify the peering member AS with the
command bgp confederation peers member-asn.
Step 4. Configure BGP confederation members as normal and then following the normal BGP
configuration guidelines for the remaining configuration.
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 5
Understanding BGP Session Types and Behavior
Confederations (Cont.)
Example 11-18 Shows BGP session configuration for a
confederations. R1 and R7 are not aware of the confederation
and peer with R2 and R6 as though they were members of AS
200. Notice that R3 does not need the command bgp
confederation peers because it is not peering with another
member AS.

Confederations share behaviors from both iBGP sessions and

eBGP sessions but have the following differences:

The AS_Path attribute contains a subfield called

AS_CONFED_SEQUENCE. AS_CONFED_SEQUENCE is
displayed in parentheses before any external ASNs in AS_Path.
As the route passes from member AS to member AS,
AS_CONFED_SEQUENCE is appended to contain the member
AS ASNs. The AS_CONFED_SEQUENCE attribute is used to
prevent loops but is not used (counted) when choosing the
shortest AS_Path.
© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 6
Understanding BGP Session Types and Behavior
Confederations (Cont.)
• Route reflectors can be used within the member AS like normal iBGP peerings.
• The BGP MED attribute is transitive to all other member ASs but does not leave the confederation.
• The LOCAL_PREF attribute is transitive to all other member ASs but does not leave the confederation.
• The next-hop address for external confederation routes does not change as the route is exchanged
between member ASs.
• AS_CONFED_SEQUENCE is removed from AS_Path when the route is advertised outside the
confederation.

Example 11-19 shows R1’s BGP table, which

displays all the routes advertised from this
topology.

Notice that R2 removed the member AS

ASNs from the route as it is advertised
externally. AS 100 is not aware that AS 200 is
a confederation.

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 7
Understanding BGP Session Types and Behavior
Confederations (Cont.)
Example 11-20 shows R2’s BGP table, which participates in the member AS 65100.
Notice that the next-hop IP address is not modified for the 10.7.7.0/24 prefix that was advertised
by R7, even though it passed a different member AS. AS_CONFED_SEQUENCE is listed in
parentheses to indicate that it passed through sub AS 65200 in the AS 200 confederation.

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 8
Understanding BGP Session Types and Behavior
Confederations (Cont.)
Example 11-21 shows the full NRLI information from the perspective of R4 for the prefix
10.7.7.0/24 that was advertised from R7. Notice that the NRLI includes the fields confedinternal
and confed-external based on whether the NLRI was received within the same member AS or a
different one.

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 9