One way to reduce the internal BGP (iBGP) mesh is to divide an autonomous system into multiple subautonomous systems and group them into a single confederation. To the outside world, the confederation looks like a single autonomous system. Each autonomous system is fully meshed within itself, and has a few connections to other autonomous systems in the same confederation. Even though the peers in different autonomous systems have external BGP (eBGP) sessions, they exchange routing information as if they were iBGP peers. Specifically, the next hop, Multi_Exit_Discriminator (MED) attribute, and local preference information is preserved. This feature allows the you to retain a single Interior Gateway Protocol (IGP) for all of the autonomous systems.

To configure a BGP confederation, you must specify a confederation identifier. To the outside world, the group of autonomous systems will look like a single autonomous system with the confederation identifier as the autonomous system number.

BGP requires that all iBGP speakers be fully meshed. However, this requirement does not scale well when there are many iBGP speakers. Instead of configuring a confederation, another way to reduce the iBGP mesh is to configure a route reflector.

The figure below illustrates a simple iBGP configuration with three iBGP speakers (Routers A, B, and C). Without route reflectors, when Router A receives a route from an external neighbor, it must advertise it to both routers B and C. Routers B and C do not readvertise the iBGP learned route to other iBGP speakers because the routers do not pass on routes learned from internal neighbors to other internal neighbors, thus preventing a routing information loop.

Figure 1

Three Fully Meshed iBGP Speakers

With route reflectors, all iBGP speakers need not be fully meshed because there is a method to pass learned routes to neighbors. In this model, an iBGP peer is configured to be a route reflector responsible for passing iBGP learned routes to a set of iBGP neighbors. In the figure below, Router B is configured as a route reflector. When the route reflector receives routes advertised from Router A, it advertises them to Router C, and vice versa. This scheme eliminates the need for the iBGP session between Routers A and C.

Figure 2

Simple BGP Model with a Route Reflector

The internal peers of the route reflector are divided into two groups: client peers and all the other routers in the autonomous system (nonclient peers). A route reflector reflects routes between these two groups. The route reflector and its client peers form a cluster. The nonclient peers must be fully meshed with each other, but the client peers need not be fully meshed. The clients in the cluster do not communicate with iBGP speakers outside their cluster.

The figure below illustrates a more complex route reflector scheme. Router A is the route reflector in a cluster with routers B, C, and D. Routers E, F, and G are fully meshed, nonclient routers.

Figure 3

More Complex BGP Route Reflector Model

When the route reflector receives an advertised route, depending on the neighbor, it takes the following actions:

• A route from an external BGP speaker is advertised to all clients and nonclient peers.
• A route from a nonclient peer is advertised to all clients.
• A route from a client is advertised to all clients and nonclient peers. Hence, the clients need not be fully meshed.

Along with route reflector-aware BGP speakers, it is possible to have BGP speakers that do not understand the concept of route reflectors. They can be members of either client or nonclient groups allowing an easy and gradual migration from the old BGP model to the route reflector model. Initially, you could create a single cluster with a route reflector and a few clients. All the other iBGP speakers could be nonclient peers to the route reflector and then more clusters could be created gradually.

An autonomous system can have multiple route reflectors. A route reflector treats other route reflectors just like other iBGP speakers. A route reflector can be configured to have other route reflectors in a client group or nonclient group. In a simple configuration, the backbone could be divided into many clusters. Each route reflector would be configured with other route reflectors as nonclient peers (thus, all the route reflectors will be fully meshed). The clients are configured to maintain iBGP sessions with only the route reflector in their cluster.

Usually a cluster of clients will have a single route reflector. In that case, the cluster is identified by the router ID of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more than one route reflector. In this case, all route reflectors in the cluster must be configured with the 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster. All the route reflectors serving a cluster should be fully meshed and all of them should have identical sets of client and nonclient peers.

• Route Reflector Mechanisms to Avoid Routing Loops
  

The BGP Outbound Route Map on Route Reflector to Set IP Next Hop feature allows a route reflector to modify the next hop attribute for a reflected route.

The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, most set clauses of outbound route maps are ignored for routes reflected to iBGP peers. The only set clause of an outbound route map on a route reflector (RR) that is acted upon is the set ip next-hop clause. The set ip next-hop clause is applied to reflected routes.

Configuring an RR with an outbound route map allows a network administrator to modify the next hop attribute for a reflected route. By configuring a route map with the set ip next-hop clause, the administrator puts the RR into the forwarding path, and can configure iBGP multipath load sharing to achieve load balancing. That is, the RR can distribute outgoing packets among multiple egress points. See the "Configuring iBGP Multipath Load Sharing" module.

Caution

Incorrectly setting BGP attributes for reflected routes can cause inconsistent routing, routing loops, or a loss of connectivity. Setting BGP attributes for reflected routes should only be attempted by someone who has a good understanding of the design implications.

In Cisco IOS Release 12.2(33)SRE, BGP VPLS Autodiscovery Support on Route Reflector was introduced. On the Cisco 7600 and Cisco 7200 series routers, BGP Route Reflector was enhanced to be able to reflect BGP VPLS prefixes without having VPLS explicitly configured on the route reflector. The route reflector reflects the VPLS prefixes to other provider edge (PE) routers so that the PEs do not need to have a full mesh of BGP sessions. The network administrator configures only the BGP VPLS address family on the route reflector.

For an example of a route reflector configuration that can reflect VPLS prefixes, see the Example BGP VPLS Autodiscovery Support on Route Reflector. For more information about VPLS Autodiscovery, see the VPLS Autodiscovery:BGP Based chapter in the Cisco IOS MPLS Configuration Guide .

Route dampening is a BGP feature designed to minimize the propagation of flapping routes across an internetwork. A route is considered to be flapping when its availability alternates repeatedly.

For example, consider a network with three BGP autonomous systems: autonomous system 1, autonomous system 2, and autonomous system 3. Suppose the route to network A in autonomous system 1 flaps (it becomes unavailable). Under circumstances without route dampening, the eBGP neighbor of autonomous system 1 to autonomous system 2 sends a withdraw message to autonomous system 2. The border router in autonomous system 2, in turn, propagates the withdraw message to autonomous system 3. When the route to network A reappears, autonomous system 1 sends an advertisement message to autonomous system 2, which sends it to autonomous system 3. If the route to network A repeatedly becomes unavailable, then available, many withdrawal and advertisement messages are sent. This is a problem in an internetwork connected to the Internet because a route flap in the Internet backbone usually involves many routes.

Note	No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset withdraws the route, no penalty is applied in this instance, even if route flap dampening is enabled.

• Route Dampening Minimizes Route Flapping
  
• BGP Route Dampening Terms
  

To configure a BGP confederation, you must specify a confederation identifier. To the outside world, the group of autonomous systems will look like a single autonomous system with the confederation identifier as the autonomous system number. To configure a BGP confederation identifier, use the following command in router configuration mode:

Router(config-router)# bgp confederation identifier  as-number

In order to treat the neighbors from other autonomous systems within the confederation as special eBGP peers, use the following command in router configuration mode:

Router(config-router)# bgp confederation peers  as-number [as-number]

For an alternative way to reduce the iBGP mesh, see "Configuring a Route Reflector."

To configure a route reflector and its clients, use the following command in router configuration mode:

Router(config-router)# neighbor {ip-address | peer-group-name} route-reflector-client

If the cluster has more than one route reflector, configure the cluster ID by using the following command in router configuration mode:

Router(config-router)# bgp cluster-id  cluster-id 

Use the show ip bgp command to display the originator ID and the cluster-list attributes.

By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are reflected to other clients. However, if the clients are fully meshed, the route reflector need not reflect routes to clients.

To disable client-to-client route reflection, use the no bgp client-to-client reflection command in router configuration mode:

Router(config-router)# no bgp client-to-client reflection

Perform this task on an RR to set a next hop for an iBGP peer. One reason to perform this task is when you want to make the RR the next hop for routes, so that you can configure iBGP load sharing. Create a route map that sets the next hop to be the RR’s address, which will be advertised to the RR clients. The route map is applied only to outbound routes from the router to which the route map is applied.

Caution

Incorrectly setting BGP attributes for reflected routes can cause inconsistent routing, routing loops, or a loss of connectivity. Setting BGP attributes for reflected routes should only be attempted by someone who has a good understanding of the design implications.

Note

Do not use the neighbor next-hop-self command to modify the next hop attribute for an RR. Using the neighbor next-hop-self command on the RR will modify next hop attributes only for non-reflected routes and not the intended routes that are being reflected from the RR clients. To modify the next hop attribute when reflecting a route, use an outbound route map.

This task configures the RR (Router 2) in the scenario illustrated in the figure below. In this case, Router 1 is the iBGP peer whose routes’ next hop is being set. Without a route map, outbound routes from Router 1 would go to next hop Router 3. Instead, setting the next hop to the RR’s address will cause routes from Router 1 to go to the RR, and thus allow the RR to perform load balancing among Routers 3, 4, and 5.

Figure 4

Route Reflector Using a Route Map to Set Next Hop for an iBGP Peer

1.    enable

2.    configure terminal

3.    route-map map-tag

4.    set ip next-hop ip-address

5.    exit

6.    router bgp as-number

7.    address-family ipv4

8.    maximum-paths ibgp number

9.    neighbor ip-address remote-as as-number

10.    neighbor ip-address activate

11.    neighbor ip-address route-reflector-client

12.    neighbor ip-address route-map map-name out

13.    Repeat Steps 12 through 14 for the other RR clients.

14.    end

15.    show ip bgp neighbors

BGP uses certain timers to control periodic activities such as the sending of keepalive messages and the interval after not receiving a keepalive message after which the Cisco IOS software declares a peer dead. By default, the keepalive timer is 60 seconds, and the hold-time timer is 180 seconds.You can adjust these timers. When a connection is started, BGP will negotiate the hold time with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time and the configured keepalive time.

To adjust BGP timers for all neighbors, use the following command in router configuration mode:

Router(config-router)# timers bgp  keepalive holdtime

To adjust BGP keepalive and hold-time timers for a specific neighbor, use the following command in router configuration mode:

Router(config-router)# neighbor [ip-address | peer-group-name] timers  keepalive holdtime 

Note	The timers configured for a specific neighbor or peer group override the timers configured for all BGP neighbors using the timers bgp router configuration command.

To clear the timers for a BGP neighbor or peer group, use the no form of the neighbor timers command.

To configure the router to consider a path with a missing MED attribute as the worst path, use the following command in router configuration mode:

Router(config-router)# bgp bestpath med missing-as-worst

To configure the router to consider the MED value in choosing a path, use the following command in router configuration mode:

Router(config-router)# bgp bestpath med confed

The comparison between MEDs is made only if there are no external autonomous systems in the path (an external autonomous system is an autonomous system that is not within the confederation). If there is an external autonomous system in the path, then the external MED is passed transparently through the confederation, and the comparison is not made.

The following example compares route A with these paths:

path= 65000 65004, med=2
path= 65001 65004, med=3
path= 65002 65004, med=4
path= 65003 1, med=1

In this case, path 1 would be chosen if the bgp bestpath med confed router configurationcommand is enabled. The fourth path has a lower MED, but it is not involved in the MED comparison because there is an external autonomous system is in this path.

To configure the router to use the MED to choose the best path from among paths advertised by a single subautonomous system within a confederation, use the following command in router configuration mode:

Router(config-router)# bgp deterministic med

Note	If the bgp always-compare-med router configuration command is enabled, all paths are fully comparable, including those from other autonomous systems in the confederation, even if the bgp deterministic med command is also enabled.

To enable BGP route dampening, use the following command in address family or router configuration mode:

Router(config-router)# bgp dampening

To change the default values of various dampening factors, use the following command in address family or router configuration mode:

Router(config-router)# bgp dampening  half-life reuse suppress max-suppress [route-map  map-name]

You can monitor the flaps of all the paths that are flapping. The statistics will be deleted once the route is not suppressed and is stable for at least one half-life. To display flap statistics, use the following commands as needed:

Router# show ip bgp flap-statistics

Router# show ip bgp flap-statistics regexp  regexp

Router# show ip bgp flap-statistics filter-list access- list

Router# show ip bgp flap-statistics  ip-address mask

Router# show ip bgp flap-statistics  ip-address mask longer-prefix

To clear BGP flap statistics (thus making it less likely that the route will be dampened), use the following commands as needed:

Router# clear ip bgp flap-statistics 

Router# clear ip bgp flap-statistics regexp regexp

Router# clear ip bgp flap-statistics filter-list  list

Router# clear ip bgp flap-statistics  ip-address mask

Router# clear ip bgp  ip-address  flap-statistics

Note	The flap statistics for a route are also cleared when a BGP peer is reset. Although the reset withdraws the route, there is no penalty applied in this instance, even if route flap dampening is enabled.

Once a route is dampened, you can display BGP route dampening information, including the time remaining before the dampened routes will be unsuppressed. To display the information, use the following command:

Router# show ip bgp dampened-paths

You can clear BGP route dampening information and unsuppress any suppressed routes by using the following command:

Router# clear ip bgp dampening [ip-address network-mask]