BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of peers increases. The number of IBGP sessions increases rapidly with the number of routers:
For example, in an AS with 9 BGP peers, the peers can conduct 36 sessions:
BGP provides the following two alternative configuration strategies to reduce the number of fully meshed peers:
Both of these strategies are complex and can create their own problems. Neither strategy is typically used unless the mesh of IBGP peers approaches 100 sessions per peer.
IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the point that each router has about 100 peering sessions.
Figure 41 shows a simpler topology. AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown). Border router Salem has an EBGP session with a neighbor in AS 325. Border router Boston has an EBGP session with a neighbor in AS 413.
Figure 41: A Fully Meshed Autonomous System
Figure 42 illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of peering sessions. According to common practice, use a number from the private range of AS numbers—from 64512 to 65535—to identify each sub-AS. AS 29 is now a confederation of three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers. A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries. To the external neighbors, AS 29 appears the same as it ever was.
Figure 42: A Confederation of Subautonomous Systems
The following commands partially configure router Salem:
- host1(config)#router bgp 64720
- host1(config-router)#bgp confederation identifier
29
- host1(config-router)#bgp confederation peers
64721 64722
- host1(config-router)#neighbor 10.2.25.4 remote-as
64720
- host1(config-router)#neighbor 10.2.25.8 remote-as
64721
- host1(config-router)#neighbor 10.2.25.2 remote-as
325
The bgp confederation identifier command establishes router Salem as a member of Confederation 29. The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members of the same confederation as the sub-AS that includes router Salem. The neighbor remote-as commands specify the IBGP connection with a neighbor in sub-AS 64720 and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325.
Similarly, the following commands partially configure router Harvard:
- host2(config)#router bgp 64721
- host2(config-router)#bgp confederation identifier
29
- host2(config-router)#bgp confederation peers
64720 64722
- host2(config-router)#neighbor 10.2.25.7 remote-as
64720
From router Newport’s perspective, router Salem is simply a member of AS 29:
- host3(config)#router bgp 325
- host3(config-router)#neighbor 10.2.25.6 remote-as
29
From router Mason’s perspective, router Boston is simply a member of AS 29:
- host4(config)#router bgp 413
- host4(config-router)#neighbor 10.3.3.2 remote-as
29
bgp confederation identifier
To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear.
bgp confederation peers
ip bgp-confed-as-set new-format
- host1(config)#ip bgp-confed-as-set new-format
Router reflection is an alternative to confederations as a strategy to reduce IBGP meshing. BGP specifies that a BGP speaker cannot advertise routes to an IBGP neighbor if the speaker learned the route from a different IBGP neighbor. A route reflector is a BGP speaker that advertises routes learned from each of its IBGP neighbors to its other IBGP neighbors; routes are reflected among IBGP routers that are not meshed. The route reflector’s neighbors are called route reflector clients. The clients are neighbors only to the route reflector, not to each other. Each route reflector client depends on the route reflector to advertise its routes within the AS; each client also depends on the route reflector to pass routes to the client.
A route reflector and its clients are collectively referred to as a cluster. Clients peer only with a route reflector and do not peer outside their cluster. Route reflectors peer with clients and other route reflectors within the cluster; outside the cluster they peer with other reflectors and other routers that are neither clients nor reflectors. Route reflectors and nonclient routers must be fully meshed.
Clients and nonclients have no knowledge of route reflection; they operate as standard BGP peers and require no configuration. You simply configure the route reflectors.
Route reflectors advertise routes learned from:
Figure 43 illustrates a simple route reflection setup. Configured as a route reflector, Router Harvard reflects routes among its clients within Cluster 23: Routers Plymouth, Westford, and Acton. These route reflector clients see router Harvard and each other simply as IBGP neighbors. Router Newport in AS 325 and router Mason in AS 413 see router Harvard simply as an EBGP neighbor in AS 29.
Figure 43: Simple Route Reflection
Reliability and redundancy are important issues when using route reflection because the members of a cluster are not fully meshed. For example, if router Harvard in Figure 43 goes down, all of its clients are isolated from networks outside the cluster. Having one or more redundant route reflectors in a cluster protects against such an occurrence.
However, you cannot rely on logical redundancy alone. Consider the cluster shown in Figure 44. The operator has attempted to provide redundancy in Cluster 9 by configuring two route reflectors, router Acton and router Westford. Unfortunately, router Harvard is physically isolated if its link to router Acton goes down, or if router Acton itself goes down. Similarly, router Plymouth is isolated if any problems develop with router Westford.
Figure 44: Route Reflection: Logical Redundancy
In Figure 45, the operator has added physical redundancy to the cluster configuration. Now, loss of either one of the route reflectors does not isolate the reflector clients.
Figure 45: Route Reflection: Physical and Logical Redundancy
BGP prevents looping between ASs by evaluating the AS-path attribute to determine a route’s origin. Border routers reject routes they receive from external neighbors if the AS path indicates that the route originated within the border router’s AS.
Route reflection creates the possibility of looping within an AS. Routes that originate within a cluster might be forwarded back to the cluster. Because this happens within a given AS, the AS-path attribute is of no use in detecting a loop.
Route reflectors add an originator ID to each route that identifies the originator of the route within the local AS by its router ID. If a router receives a route having the originator ID set to its own router ID, it rejects the route.
You can also use a cluster list to prevent looping. Each cluster has an identifying number, the cluster ID. For clusters with a single route reflector, the cluster ID is the router ID of the route reflector; otherwise you configure the cluster ID. The cluster list records the cluster ID of each cluster traversed by a route. When a route reflector passes a route from a client to a nonclient router outside the cluster, the reflector appends the cluster ID to the list. When a route reflector receives a route from a nonclient, it rejects the route if the list contains the local cluster ID.
What about routes that a client forwards out of the cluster? No cluster ID is needed, because clients can forward routes only to EBGP peers, that is, to peers outside the AS. Looping between ASs is prevented by the AS-path list.
The following commands configure the route reflectors for the network topology shown in Figure 46. You configure the other routers, whether nonclients or route reflector clients, as usual for IBGP and EBGP peers.
To configure router Salem as a route reflector:
- host1(config)#router bgp 29
- host1(config-router)#neighbor 10.2.5.5 remote-as
29
- host1(config-router)#neighbor 10.2.5.5 route-reflector-client
- host1(config-router)#neighbor 10.2.5.6 remote-as
29
- host1(config-router)#neighbor 10.2.5.6 route-reflector-client
- host1(config-router)#neighbor 10.2.5.7 remote-as
29
- host1(config-router)#neighbor 10.2.5.8 remote-as
29
- host1(config-router)#neighbor 10.2.25.5 remote-as
325
You do not configure a cluster ID, because router Salem is the only route reflector in this cluster.
Figure 46: BGP Route Reflection
To configure router Concord as a route reflector:
- host2(config)#router bgp 29
- host2(config-router)#neighbor 10.7.1.3 remote-as
29
- host2(config-router)#neighbor 10.7.1.3 route-reflector-client
- host2(config-router)#neighbor 10.7.1.4 remote-as
29
- host2(config-router)#neighbor 10.7.1.4 route-reflector-client
- host2(config-router)#neighbor 10.7.6.2 remote-as
29
You do not configure a cluster ID, because router Concord is the only route reflector in this cluster.
To configure router Acton as a route reflector:
- host3(config)#router bgp 29
- host3(config)#bgp cluster-id 23
- host3(config-router)#neighbor 10.3.1.1 remote-as
29
- host3(config-router)#neighbor 10.3.1.1 route-reflector-client
- host3(config-router)#neighbor 10.1.2.3 remote-as
29
- host3(config-router)#neighbor 10.1.2.3 route-reflector-client
- host3(config-router)#neighbor 10.3.3.4 remote-as
29
- host3(config-router)#neighbor 10.2.5.1 remote-as
29
You must configure a cluster ID, because router Acton and router Harvard are both route reflectors in this cluster.
To configure router Harvard as a route reflector:
- host4(config)#router bgp 29
- host4(config)#bgp cluster-id 23
- host4(config-router)#neighbor 10.3.1.2 remote-as
29
- host4(config-router)#neighbor 10.3.1.2 route-reflector-client
- host4(config-router)#neighbor 10.1.2.1 remote-as
29
- host4(config-router)#neighbor 10.1.2.1 route-reflector-client
- host4(config-router)#neighbor 10.3.3.2 remote-as
29
- host4(config-router)#neighbor 10.2.5.2 remote-as
29
You must configure a cluster ID, because router Harvard and router Acton are both route reflectors in this cluster.
bgp client-to-client reflection
- host1(config-router)#no bgp client-to-client
reflection
bgp cluster-id
neighbor route-reflector-client
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |