Settlements for problems in large scale BGP networks

Route summarization can reduce the routing table size on a large network, and allow BGP routers to advertise only summary routes.

The system supports both manual and automatic route summarization. Manual route summarization allows you to determine the attribute of a summary route and whether to advertise the route.

BGP route dampening solves the issue of route instability such as route flaps—a route comes up and disappears in the routing table frequently.

When a route flap occurs, the routing protocol sends an update to its neighbor, and then the neighbor must recalculate routes and modify the routing table. Frequent route flaps consume large bandwidth and CPU resources, which could affect network operation.

In most cases, BGP is used in complex networks, where route changes are more frequent. To solve the problem caused by route flaps, BGP route dampening is used to suppress unstable routes.

BGP route dampening, as shown in Figure 82, uses a penalty value to judge the stability of a route. The bigger the value, the less stable the route. Each time a route flap occurs, BGP adds a penalty value (1000, which is a fixed number and cannot be changed) to the route. When the penalty value of the route exceeds the suppress value, the route is suppressed from being added into the routing table or being advertised to other BGP peers.

The penalty value of the suppressed route will decrease to half of the suppress value after a period of time. This period is called "Half-life". When the value decreases to the reusable threshold value, the route is added into the routing table and advertised to other BGP peers.

You can organize BGP peers with the same attributes into a group to simplify their configurations.

When a peer joins the peer group, the peer obtains the same configuration as the peer group. If the configuration of the peer group is changed, the configuration of group members is changed.

When a peer is added into a peer group, the peer has the same route update policy as the peer group to improve route distribution efficiency.

If an option is configured for both a peer and its peer group, the last configuration takes effect.

A peer group provides each peer with the same policy. A community provides a group of BGP routers in several ASs with the same policy. Community is a path attribute advertised between BGP peers without being limited by AS.

A BGP router can modify the COMMUNITY attribute for a route before sending it to other peers.

Besides using well-known COMMUNITY attributes, you can define extended community attributes by using a community list to define a routing policy.

IBGP peers must be fully meshed to maintain connectivity. If n routers exist in an AS, the number of IBGP connections is n (n-1)/2, and large amounts of network and CPU resources are consumed.

Using route reflectors can resolve this issue. In an AS, a router acts as a route reflector, and other routers act as clients connecting to the route reflector. The route reflector forwards routing information between clients, so BGP sessions between clients need not be established.

A router that is neither a route reflector nor a client is a non-client, which, as shown in Figure 83, must establish BGP sessions to the route reflector and other non-clients.

The route reflector and clients form a cluster. In some cases, you can configure more than one route reflector in a cluster to improve network reliability and prevent a single point of failure, as shown in the following figure. The configured route reflectors must have the same Cluster_ID in order to avoid routing loops.

When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it consumes more bandwidth resources. You can use related commands to disable route reflection.

	NOTE: After route reflection is disabled between clients, routes can still be reflected between a client and a non-client.

Confederation is another method to manage growing IBGP connections in ASs. This method splits an AS into multiple sub-ASs. In each sub-AS, IBGP peers are fully meshed, and, as shown in Figure 85, intra-confederation EBGP connections are established between sub-ASs.

A non-confederation BGP speaker is not required to know sub-ASs in the confederation. The ID of the confederation is the number of the AS. In the above figure, AS 200 is the confederation ID.

The deficiency of confederation is as follows:

• When changing an AS into a confederation, you must reconfigure your routers.

• The topology is changed.

In large-scale BGP networks, both route reflector and confederation can be used.