3.7e Implement and Troubleshoot Scalability
3.7e(ii) Confederations
BGP confederations introduce the concept of creating a number of smaller autonomous systems within an original autonomous system. The sub-ASs exchange BGP update between them using intra-confederation eBGP sessions.With BGP confederations, member-ASs are never visible from outside the confederation. This allows private AS numbers (64512 to 65535) to be used inside the confederation. BGP routers inside the member-AS must still maintain a full mesh of iBGP sessions. EBGP sessions are established between member-ASs. These eBGP sessions behave slightly differently from classic or real eBGP sessions (referred to as intra-confederation eBGP sessions to differentiate them from true eBGP sessions).
When a router sends a BGP update over an intra-confederation eBGP session, it prepends the member-AS number to the AS_PATH attribute. This information is maintained by the routers within the confederation. When a router sends a BGP update over a true eBGP session, it removes the part of the AS_PATH that describes the member-AS numbers and prepends the official AS number to the AS_PATH. As a result, the confederation appears as one single AS to the outside world.
When a router sends an update over an intra-confederation eBGP, it prepends the member-AS number in parenthesis. Routers do not modify the AS_PATH when transmitting over an iBGP session. When advertising the route to a true eBGP peer, the router removes the parenthesized information and replaces it with the official AS number of the confederation.
All else being equal, the BGP best path decision process chooses normal eBGP routes over confederation eBGP over iBGP routes.
A router that does not support BGP confederations cannot operate inside a BGP confederation. A router not supporting BGP confederations will reject an AS_PATH with unknown segement type.
Although intra-confederation eBGP sessions have eBGP-like properties, they still run inside a real AS and therefore share some properties with iBGP sessions to achieve the same results. Similar to iBGP, the BGP attributes of local preference, MED, and next-hop are not changed across intra-confederation eBGP sessions. All routers in all member-ASs inside the confederation consequently see the same next-hop address when doing recursive routing. The entire confederation should then use the same IGP to resolve the BGP next-hop address.
As a summary, the route reflectors modify the BGP split horizon rule and confederations modify AS_PATH processing. Intra-confederation eBGP sessions act like eBGP sessions from a session establishment perspective, and they act like iBGP sessions from the BGP attribute-propagation perspective.
Configuration Example
R1#
router bgp 65001
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 12
bgp confederation peers 65002
network 1.1.1.0 mask 255.255.255.0
neighbor CONFED-PEER peer-group
neighbor CONFED-PEER remote-as 65001
neighbor CONFED-PEER update-source Loopback0
neighbor 10.1.17.7 remote-as 78
neighbor 10.1.18.8 remote-as 78
neighbor 150.1.2.2 remote-as 65002
neighbor 150.1.2.2 ebgp-multihop 2
neighbor 150.1.2.2 update-source Loopback0
neighbor 150.1.3.3 peer-group CONFED-PEER
neighbor 150.1.4.4 peer-group CONFED-PEER
no auto-summary
R2#
router bgp 65002
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 12
bgp confederation peers 65001
network 2.2.2.0 mask 255.255.255.0
neighbor CONFED-PEER peer-group
neighbor CONFED-PEER remote-as 65002
neighbor CONFED-PEER update-source Loopback0
neighbor 150.1.1.1 remote-as 65001
neighbor 150.1.1.1 ebgp-multihop 2
neighbor 150.1.1.1 update-source Loopback0
neighbor 150.1.5.5 peer-group CONFED-PEER
neighbor 150.1.6.6 peer-group CONFED-PEER
no auto-summary
R8#
router bgp 78
no synchronization
bgp log-neighbor-changes
network 8.8.8.0 mask 255.255.255.0
neighbor 10.1.18.1 remote-as 12
no auto-summary
Let's see what the routers (R5) inside the sub-AS are learning.
R5#show ip bgp
BGP table version is 9, local router ID is 150.1.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.0/24 150.1.1.1 0 100 0 (65001) i
*>i2.2.2.0/24 150.1.2.2 0 100 0 i
*>i3.3.3.0/24 150.1.3.3 0 100 0 (65001) i
*>i4.4.4.0/24 150.1.4.4 0 100 0 (65001) i
*> 5.5.5.0/24 0.0.0.0 0 32768 i
*>i6.6.6.0/24 150.1.6.6 0 100 0 i
*>i7.7.7.0/24 10.1.17.7 0 100 0 (65001) 78 i
*>i8.8.8.0/24 10.1.18.8 0 100 0 (65001) 78 i
Note that the next-hop and local preference values are retained across confederation-EBGP peering (example route 8.8.8.0/24 from R8). The AS number inside the parenthesis signifies that the route has traversed through a confederation sub-AS.
R5#show ip bgp 8.8.8.0/24
BGP routing table entry for 8.8.8.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
(65001) 78
10.1.18.8 (metric 30) from 150.1.2.2 (150.1.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
According to BGP confederation rules, true eBGP peers should not see the sub-AS numbers. They don't. From R8's perspective, the routes originated from AS 12.
R8#show ip bgp
BGP table version is 8, local router ID is 150.1.8.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 10.1.18.1 0 0 12 i
*> 2.2.2.0/24 10.1.18.1 0 12 i
*> 3.3.3.0/24 10.1.18.1 0 12 i
*> 4.4.4.0/24 10.1.18.1 0 12 i
*> 5.5.5.0/24 10.1.18.1 0 12 i
*> 6.6.6.0/24 10.1.18.1 0 12 i
*> 8.8.8.0/24 0.0.0.0 0 32768 i
No comments:
Post a Comment