Out-of-Band Route Reflectors
As explained earlier, BGP can establish multihop BGP sessions and does not change the next-hop path attribute when routes are advertised to IBGP neighbors. Some large network topologies use dedicated BGP routers for route reflection that are outside of the data path.
These out-of-band route reflectors provide control plane programming for the BGP routers that are in the data path and only require sufficient memory and processing power for the BGP routing table. Out-of-band route reflectors should not use the next-hop-self, or it will place the route reflector into the data path. Organizations that use MPLS L2VPNs, L3VPNs, and so on will use multiple out-of-band route reflectors for exchanging BGP path information.
Confederations
RFC 3065 introduced the concept of BGP confederations as an alternative solution to IBGP full mesh scalability issues shown earlier. A confederation consists of sub-ASs known as a Member-AS that combine into a larger AS known as an AS Confederation. Member ASs normally use ASNs from the private ASN range (64512-65535). EBGP peers from the confederation have no knowledge that they are peering with a confederation, and they reference the confederation identifier in their configuration.
Figure 1-11 demonstrates a BGP confederation with the confederation identifier of AS200. The Member-ASs are AS65100 and AS65200. R3 provides route reflection in Member-AS 65100.
)
Figure 1-11 Sample BGP Confederation Topology
Confederations share behaviors from both IBGP sessions and EBGP sessions. The changes are as follows:
The AS_PATH attribute contains a subfield called AS_CONFED_SEQUENCE. The AS_CONFED_SEQUENCE is displayed in parentheses before any external ASNs in the AS_PATH. As the route passes from Member-AS to Member-AS, the AS_CONFED_SEQUENCE is appended to contain the Member-AS ASNs. The AS_CONFED_SEQUENCE attribute is used to prevent loops, but it is not used (counted) when choosing shortest AS_PATH.
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.
IOS XR nodes do not require a route policy when peering with a different Member-AS, even though the remote-as is different.
The next-hop address for external confederation routes does not change as the route is exchanged between Member-AS to Member-AS.
The AS_CONFED_SEQUENCE is removed from the AS_PATH when the route is advertised outside of the confederation.
Configuring a BGP confederation is shown in the following steps:
Step 1. Create the BGP Routing Process. Initialize the BGP process with the global command router bgp member-asn.
Step 2. Set the BGP Confederation Identifier. Identify the BGP confederations with the command bgp confederation identifier as-number. The as-number is the BGP confederation ASN.
Step 3. Identify Peer Member-ASs. 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; the remaining configuration follows normal BGP configuration guidelines.
Example 1-11 displays R1’s and R2’s BGP table. R1 resides in AS100 and does not see any of the BGP subconfederation information. R1 is not aware the AS200 is subdivided into a BGP confederation.
R2’s BGP table participates in the Member-AS 65100. Notice the next-hop address is not modified for the 10.67.1.0/24 (Network between R6 and R7) even though a Member-AS. The AS_CONFED_SEQUENCE is listed in parentheses to indicate it passed through Sub-AS 65200 in the AS200 confederation.
Example 1-11 R1’s and R2’s BGP Table
R1-IOS# show bgp ipv4 unicast
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
r> 10.1.12.0/24 10.1.12.2 0 0 200 i
*> 10.1.23.0/24 10.1.12.2 0 0 200 i
*> 10.1.25.0/24 10.1.12.2 0 0 200 i
*> 10.1.34.0/24 10.1.12.2 0 200 i
*> 10.1.46.0/24 10.1.12.2 0 200 i
*> 10.1.56.0/24 10.1.12.2 0 200 i
*> 10.1.67.0/24 10.1.12.2 0 200 i
R2-IOS# show bgp ipv4 unicast
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
*> 10.1.12.0/24 0.0.0.0 0 32768 i
* i 10.1.23.0/24 10.1.23.3 0 100 0 i
*> 0.0.0.0 0 32768 i
* 10.1.25.0/24 10.1.25.5 0 100 0 (65200) i
*> 0.0.0.0 0 32768 i
*>i 10.1.34.0/24 10.1.23.3 0 100 0 i
*>i 10.1.46.0/24 10.1.34.4 0 100 0 i
*> 10.1.56.0/24 10.1.25.5 0 100 0 (65200) i
* 10.1.67.0/24 10.1.56.6 0 100 0 (65200) i
*>i 10.1.46.6 0 100 0 (652000) i
Example 1-12 displays the NLRI information for 10.67.1.0/24 from the perspective of R2. Notice that the NLRI from within a confederation includes the option of confed-internal and confed-external for sources.
Example 1-12 Confederation NLRI
R2-IOS# show bgp ipv4 unicast 10.67.1.0/24
! Output omitted for brevity
BGP routing table entry for 10.1.67.0/24, version 8
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1 3
Refresh Epoch 1
(65200)
10.56.1.6 from 10.1.25.5 (10.1.56.5)
Origin IGP, metric 0, localpref 100, valid, confed-external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
(65200)
10.46.1.6 from 10.1.23.3 (10.1.23.3)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Originator: 10.1.34.4, Cluster list: 10.1.23.3
rx pathid: 0, tx pathid: 0x0