3.7e Implement and Troubleshoot Scalability
The iBGP full-mesh requirement (BGP split-horizon rule) does not scale well when there is a large number of iBGP speakers. For n iBGP speakers, n(n-1)/2 sessions must be maintained. Two methods have been developed to solve this scaling problem: BGP route reflectors and BGP confederations.
3.7e(i) Route Reflector, Cluster
Route reflectors enable routing information to be redistributed to all routers within an AS while eliminating the need for a fully meshed topology. Route reflectors reduce the number of TCP sessions that must be maintained - lowering network overhead, and also CPU and memory resource requirements. BGP route reflectors operate similarly to OSPF DR/BDR or IS-IS DIS.In a route-reflector-based iBGP network, BGP routers are divided into route reflectors (implement modified BGP split horizon rules) and clients (behave like traditional iBGP routers). A client has only one iBGP connection - to the route reflector. Further, the route reflector breaks the BGP split horizon rule. When an iBGP update is received from a client, the route reflector forwards the update to other iBGP neighbors - alleviating the iBGP full-mesh requirement for the clients. Similarly, when the route reflector receives an update from a non-client, it forwards the update to all of its clients. Any of the common BGP attributes are not changed.
IBGP peers of the route reflector fall under two categories: clients and non-clients. The route reflector and its clients form a cluster. All iBGP peers of the route reflector that are not part of the cluster are non-clients.
Clients may have any number of eBGP peers but may have only one iBGP session with the route reflector(s). One route reflector is a single point of failure. If the route reflector fails, its clients can no longer send BGP updates or receive them from the rest of the AS. Therefore, the route reflector functionality must be redundant (two route reflectors).
Route reflector clusters prevent iBGP routing loops in redundant route reflector designs. A design requirement is to properly identify which route reflectors and their clients form a cluster. A unique cluster-ID (within the AS) must be configured on the route reflectors. A route reflector can reflect routes only within a single cluster. A route reflector can participate in another cluster, but only as a client. A client can function as a client only to a route reflector belonging to the same cluster.
When a route is reflected, the route reflector creates the CLUSTER_LIST attribute and attaches it to the route if it does not already exist. It then sets the cluster-ID in the CLUSTER_LIST or adds its cluster-ID to an already existing CLUSTER_LIST attribute. If the route is ever reflected back to the same reflector, it recognizes its cluster-ID and does not forward the route. The first route reflector that reflects a route also sets an additional BGP attribute, called ORIGINATOR_ID, which carries the BGP router-ID of the iBGP router that sent the route. As a loop prevention mechanism, any router that receives an iBGP update with the ORIGINATOR_ID attribute set to its own BGP router-ID or with its cluster-ID already in the CLUSTER_LIST, ignores that update. Both CLUSTER_LIST and ORIGINATOR_ID are optional non-transitive BGP attributes.
The BGP best path selection process is modified when a router receives both reflected and non-reflected routes. The traditional BGP best path selection parameters - such as WEIGHT, LOCAL_PREF, ORIGIN, and MED - are compared first. If equal, the routes received from eBGP neighbors are preferred over routes received from iBGP neighbors. If reflected and non-reflected (no ORIGINATOR_ID) are available, the non-reflected routes are preferred. Reflected routes with shorter CLUSTER_LISTs are preferred. Finally, if the route-reflector-specific selection criteria does not yield a decision, the rest of the traditional BGP path selection rules are followed.
The route reflection BGP best path selection process as a summary:
- Traditional BGP best path parameters (WEIGHT, LOCAL_PREFERENCE, ORIGIN, MED, and so on).
- eBGP over iBGP.
- Non-reflected routes over reflected routes.
- A route with a shorter CLUSTER_LIST is preferred.
- The rest of the traditional BGP path selection process.
NOTE: BGP route reflectors are a control plane mechanism. The route reflectors don't have to, and often do not, exist in the data path between the networks. However, if the route reflectors fail, BGP communication will eventually stop even if the underlying network is up and running.
3.7e(i) Configuration Example
RR stands for route reflector. All iBGP routers are configured with Lo0: 150.x.x.x/32, which is used as the source IP address for the BGP sessions. In addition, route reflector clients have Lox: x.x.x.x/24, where x is the number of the router, that is advertised via BGP. OSPF is enabled in AS 12 for full IP connectivity. Finally, RR2 is operating as a route reflector client for RR1.
Including only relevant BGP configuration.
RR1#
router bgp 12
no synchronization
bgp router-id 150.1.1.1
bgp cluster-id 1.1.1.1
bgp log-neighbor-changes
neighbor RR-CLIENT peer-group
neighbor RR-CLIENT remote-as 12
neighbor RR-CLIENT update-source Loopback0
neighbor RR-CLIENT route-reflector-client
neighbor 150.2.2.2 peer-group RR-CLIENT
neighbor 150.3.3.3 peer-group RR-CLIENT
neighbor 150.4.4.4 peer-group RR-CLIENT
no auto-summary
RR2#
router bgp 12
no synchronization
bgp router-id 150.2.2.2
bgp cluster-id 2.2.2.2
bgp log-neighbor-changes
neighbor RR-CLIENT peer-group
neighbor RR-CLIENT remote-as 12
neighbor RR-CLIENT update-source Loopback0
neighbor RR-CLIENT route-reflector-client
neighbor 150.1.1.1 remote-as 12
neighbor 150.1.1.1 update-source Loopback0
neighbor 150.5.5.5 peer-group RR-CLIENT
neighbor 150.6.6.6 peer-group RR-CLIENT
no auto-summary
A sample configuration for the route reflector clients (R6). The rest of the route reflector clients have identical configuration with the exception of the advertised network or RR1/RR2 neighbor address.
R6#
router bgp 12
no synchronization
bgp log-neighbor-changes
network 6.6.6.0 mask 255.255.255.0
neighbor 150.2.2.2 remote-as 12
neighbor 150.2.2.2 update-source Loopback0
no auto-summary
R3 is also peered with external BGP routers R7 and R8.
R3#
router bgp 12
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 10.1.37.7 remote-as 78
neighbor 10.1.38.8 remote-as 78
neighbor 150.1.1.1 remote-as 12
neighbor 150.1.1.1 update-source Loopback0
no auto-summary
R6 is learning all Loopback0 networks.
R6#show ip bgp
BGP table version is 7, local router ID is 150.6.6.6
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
*>i3.3.3.0/24 150.3.3.3 0 100 0 i
*>i4.4.4.0/24 150.4.4.4 0 100 0 i
*>i5.5.5.0/24 150.5.5.5 0 100 0 i
*> 6.6.6.0/24 0.0.0.0 0 32768 i
*>i7.7.7.0/24 10.1.37.7 0 100 0 78 i
*>i8.8.8.0/24 10.1.38.8 0 100 0 78 i
Let's look at a specific route entry for 4.4.4.0/24. Note that the CLUSTER_LIST includes both cluster-IDs through which the update has traversed (2.2.2.2, 1.1.1.1). The router-ID of the iBGP peer from which the route has been received is copied into the ORIGINATOR_ID attribute.
R6#show ip bgp 4.4.4.0/24
BGP routing table entry for 4.4.4.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
150.4.4.4 (metric 31) from 150.2.2.2 (150.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 150.4.4.4, Cluster list: 2.2.2.2, 1.1.1.1
For comparison, see the route for 8.8.8.0/24. Pay specific attention to the ORIGINATOR_ID, which is now 150.3.3.3 (R3) - the iBGP peer that advertised the route the route reflector (RR1).
R6#show ip bgp 8.8.8.0/24
BGP routing table entry for 8.8.8.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
78
10.1.38.8 (metric 30) from 150.2.2.2 (150.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 150.1.3.3, Cluster list: 2.2.2.2, 1.1.1.1
Bonus: The metric is derived from the OSPF route.
R6#show ip route 150.4.4.4
Routing entry for 150.4.4.4/32
Known via "ospf 1", distance 110, metric 31, type intra area
Last update from 10.2.56.5 on FastEthernet0/0.56, 00:49:56 ago
Routing Descriptor Blocks:
* 10.2.56.5, from 150.4.4.4, 00:49:56 ago, via FastEthernet0/0.56
Route metric is 31, traffic share count is 1
No comments:
Post a Comment