BGP Confederations
Erick N. Borgard CCNP
With iBGP, every router in the BGP autonomous system must be fully meshed. The reason for this is because iBGP updates are not passed to other iBGP neighbors. This brings about scalability issues using the n(n-1)/2 formula to achieve a full mesh of connections. This document will look at a strategy to reduce the number of iBGP session needed inside a large autonomous system. RFC 5065 describes the use of Autonomous System Confederations for BGP. BGP confederations help with this scalability issue by allowing the engineer to subdivide the autonomous system into smaller sub-autonomous systems.
There are generally two(2) design methods when considering BGP confederations, one is to use one IGP throughout the autonomous system and the next hop value is not changed when updates are passed between intra-confederation eBGP peers. The other way to design it would be to use a different IGP within each sub-autonomous system and the next hop value is changed in updates between intra-confederation eBGP peers. This document will focus on the first method. Only one IGP will be used in this example.
All rules governing the behavior of iBGP will be the enforced inside each sub-autonomous system. This means that each sub-autonomous system must also use the full mesh rule.
Even though the engineer can break up the autonomous system into smaller, more manageable autonomous systems, the only thing that changes in the AS_CONFED_SEQ and AS_CONFED_SET values.(If aggregation is used) Other attributes, such as med, local preference, and next hop are not changed. When designing BGP confederations, it's common practice to use the private AS range to denote a sub-autonomous system. The private AS numbers available for use is 64512 – 65535.
In this example, we will configure R4 and R3 to be in one sub-autonomous system and R1 and R2 will be in their own sub-autonomous system.
The configuration steps for BGP confederations are very straightforward.
- Define the confederation ID (The real AS number)
- Define the confederation peer
- Define the neighbors
Bullet point number 2 deserves a little more clarification. Each router that is forming and intra-confederation eBGP session with a router in another sub-autonomous system must define that peers sub-autonomous system number in the bgp confederation peers statement. For example R1's configuration will have 2 BGP confederation peer statements. One for R2 and one for R3. This will become more evident when the configurations are examined.
R1
router bgp 65500
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65515 65534
neighbor 10.10.12.2 remote-as 65515
neighbor 10.10.13.3 remote-as 65534
no auto-summary
R2
router bgp 65515
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65500 65534
bgp scan-time 5
neighbor 10.10.12.1 remote-as 65500
neighbor 10.10.24.4 remote-as 65534
no auto-summary
R3
router bgp 65534
no synchronization
bgp router-id 3.3.3.3
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65500
bgp scan-time 5
neighbor 10.10.13.1 remote-as 65500
neighbor 10.10.34.4 remote-as 65534
no auto-summary
R4
router bgp 65534
no synchronization
bgp router-id 4.4.4.4
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65515
bgp scan-time 5
neighbor 10.10.24.2 remote-as 65515
neighbor 10.10.34.3 remote-as 65534
neighbor 10.10.34.3 next-hop-self
neighbor 77.56.10.1 remote-as 200
no auto-summary
Let's take a look at the output on the routers after the configuration has been applied. We will begin with R4.
R4#sh ip bgp | beg Or
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 13.10.10.0/24 77.56.10.1 0 0 200 i
*> 74.29.64.0/18 77.56.10.1 0 0 200 i
*> 133.12.0.0/19 77.56.10.1 0 0 200 i
When R4 receives the update from BB1, it will prepend the confederation AS number before it send the update to R2 and R3. We will be able to see this by examining the output of either R2 or R3.
R2#sh ip bgp | beg O
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 13.10.10.0/24 77.56.10. 0 100 0 (65534) 200 i
*> 74.29.64.0/18 77.56.10.1 0 100 0 (65534) 200 i
*> 133.12.0.0/19 77.56.10.1 0 100 0 (65534) 200 I
R2's output shows that each of the received routes has passed through sub-autonomous system 65534 with the next hop being BB1's S0/0 interface. Remember, we are only using one IGP through the AS.
When we look at how R1 sees the network, and the path it chooses to reach the external networks might be something you didn't expect. Please examine the following example output of R1's BGP table.
R1#sh ip bgp | b O
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>13.10.10.0/24 77.56.10.1 0 100 0 (65515 65534) 200 i
* 10.10.34.4 0 100 0 (65534) 200 i
*>74.29.64.0/18 77.56.10.1 0 100 0 (65515 65534) 200 i
* 10.10.34.4 0 100 0 (65534) 200 i
*>133.12.0.0/19 77.56.10.1 0 100 0 (65515 65534) 200 i
* 10.10.34.4 0 100 0 (65534) 200 I
Looking at R1's BGP table, we can see that R1 has multiple paths to reach the external networks, but it's seems to be choosing the longest AS path [(65515 65534) 200] instead of the shortest AS path.
RFC 5065 section 5.3 states the following:
5.3. AS_PATH and Path Selection
Path selection criteria for information received from members inside
a confederation MUST follow the same rules used for information
received from members inside the same autonomous system, as specified
in BGP-4.
In addition, the following rules SHALL be applied:
1) If the AS_PATH is internal to the local confederation (i.e., there
are only AS_CONFED_* segments), consider the neighbor AS to be the
local AS.
2) Otherwise, if the first segment in the path that is not an
AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider
the neighbor AS to be the leftmost AS_SEQUENCE AS.
3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and
CONFED_SETs SHOULD NOT be counted.
4) When comparing routes using the internal (IBGP learned) versus
external (EBGP learned) rules, treat a route that is learned from
a peer that is in the same confederation (not necessarily the same
Member-AS) as "internal".
The third point outlines why BGP is not choosing the
shortest confederation AS path. The AS path attribute is using the
AS_CONFED_SEQ portion of the AS path attribute for routing loop
control inside the confederation. However, it's not being used as
criteria for BGP path selection inside the confederation. So why did
R1 choose R2? Let's take a look.R1#sh ip bgp 13.10.10.0
BGP routing table entry for 13.10.10.0/24, version 23
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
(65515 65534) 200
77.56.10.1 from 10.10.12.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
(65534) 200
10.10.34.4 (metric 20) from 10.10.13.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-external
Since all of the other BGP attributes are identical, BGP chose the path it received from the router with the lowest BGP router ID. Since R2 has a lower router ID (2.2.2.2) than R3 (3.3.3.3), it chose the path through R2 as best.
In summary, this document briefly outline the purpose and configuration of BGP confederations. For additional resources, please refer to RFC 5065.
No comments:
Post a Comment