Managing a Large-Scale AS

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.

Configuring a Confederation

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

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

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

  • Use to establish a router as a member of the specified BGP confederation.
  • To routers outside the confederation, the confederation appears as an autonomous system with an AS number the same as the confederation identifier.
  • The new confederation identifier is used in open messages and in the AS path in update messages that are sent after you issue the command.

    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.

  • Use the no version to remove the sub-AS from the confederation.
  • See bgp confederation identifier.

bgp confederation peers

  • Use to enable EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref, MED, and next-hop attributes.
  • You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers.
  • If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the filter list, then the peer is treated as being in the same confederation.
  • This command takes effect immediately and bounces only those sessions whose peer type changed as a result of issuing the command.
  • Use the no version to remove individually specified sub-ASs, all sub-ASs specified by the filter list, or all sub-ASs from the confederation.
  • See bgp confederation peers.

ip bgp-confed-as-set new-format

  • Use to specify that AS-confed-sets are displayed enclosed within square brackets rather than parentheses, and that the AS paths in the set are delimited by commas rather than spaces.
  • Example
    host1(config)#ip bgp-confed-as-set new-format
  • Use the no version to restore the default display within parentheses and with space-delimited ASs.
  • See ip bgp-confed-as-set new-format.

Configuring Route Reflectors

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

Simple Route Reflection

Route Reflection and Redundancy

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

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

Route Reflection: Physical and Logical
Redundancy

Route Reflection and Looping

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

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

  • Use to reenable the reflector to reflect routes among all clients.
  • Client-to-client reflection is enabled by default. If the route reflector’s clients are fully meshed, you can disable reflection because it is not necessary.
  • If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
  • Example
    host1(config-router)#no bgp client-to-client reflection
  • Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
  • Use the no version to disable route reflection; use only if the route reflector’s clients are fully meshed.
  • See bgp client-to-client reflection.

bgp cluster-id

  • Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one route reflector. For clusters with a single reflector, the cluster ID is the reflector’s router ID and does not have to be configured.
  • You specify a cluster ID number or an IP address of a router acting as a route reflector.
  • The new cluster ID is used in update messages sent after you issue the command. To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp command to perform a hard clear or a soft clear.
  • Use the no version to cause BGP to use the router ID as the cluster ID.
  • See bgp cluster-id.

neighbor route-reflector-client

  • Use to configure the local router as the route reflector and the specified neighbor as one of its clients. The reflector and its clients constitute a cluster. BGP neighbors that are not specified as clients are nonclients.
  • Route reflectors pass routes among the client routers.
  • Route reflection eliminates the need for all IBPG peers to be fully meshed. The members of a cluster do not have to be fully meshed, but BGP speakers outside the cluster must be fully meshed.
  • If client-to-client reflection is enabled (the default), clients of a route reflector cannot be members of a peer group.
  • If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override this inheritance for a peer group member.
  • Changes apply automatically to any routes received after you issue the command. To advertise or withdraw routes that are already present in the BGP routing table, you must use the clear ip bgp command to issue a hard clear or an outbound soft clear.
  • Use the no version to indicate that the neighbor is no longer a client. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
  • See neighbor route-reflector-client.