Onnowpurbo: Created page with "Managing Large-Scale BGP Peering The preceding section pointed out that when an AS becomes large, attempting to create fully meshed IBGP peers can be daunting. This is just on..."

2019-03-18T04:38:44Z

Created page with "Managing Large-Scale BGP Peering The preceding section pointed out that when an AS becomes large, attempting to create fully meshed IBGP peers can be daunting. This is just on..."

New page

Managing Large-Scale BGP Peering
The preceding section pointed out that when an AS becomes large, attempting to create fully meshed IBGP peers can be daunting.
This is just one of the problems that emerges when you attempt to work with BGP on a large scale. BGP features four tools that can
simplify the management of large numbers of BGP peers:
Peer groups
Communities
Route reflectors
Confederations
The first two tools help simplify the management of routing policies between multiple peers, either internal or external. The second two
tools simplify the management of IBGP among large numbers of peers.
Peer Groups
Often in large BGP internetworks, policies on a router apply to multiple peers. The same attributes might be set in the updates going
to several peers, for example, or the same filter might be used on routes coming from several peers. In such cases, you can simplify
configuration and management by adding peers that share common policies to a peer group.
A peer group is defined on a Cisco router with a name and a set of routing policies. Peers are then added to the peer group. Any
changes that must be made to the policies can then be made for the group rather than for each individual peer. Peer groups also
prove useful for improving performance on a router. Instead of repeatedly consulting the policy database for each update sent to each
peer, the router can consult the policy database once, create a single update, and then send copies of it to all the peers in the group.
At times, additional policies might apply to one or more members of a peer group. In such a case, you can apply the additional policies
to the appropriate neighbors in addition to the common policies of the group.
Communities
Whereas peer groups apply policies to a group of routers, communities apply policies to a group of routes. A router adds a route to a
preconfigured community by setting its COMMUNITY attribute to some value that identifies it as a member of the community.
Neighboring routers can then apply their policies, such as filtering or redistribution policies, to the routes based on the value of the
COMMUNITY attribute. The COMMUNITY attribute, which can be set to a well-known value or to some value defined by the network
administrator, is described more fully in the section "The COMMUNITY Attribute," earlier in this chapter.
You can set more than one COMMUNITY attribute for a single route. A router receiving a route with multiple COMMUNITY attributes
has the option of setting policies based on all those attributes or on some subset of the attributes. When routes containing
COMMUNITY attributes are aggregated, the aggregate inherits all the COMMUNITY attributes of all the routes.
Route Reflectors
Route reflectors are useful when an AS contains a large number of IBGP peers. (For more information, see RFC 1966 at
www.isuedu/in-notes/rfc1771.txt.) Unless EBGP routes are redistributed into the autonomous system's IGP, all IBGP peers must be
fully meshed. For every n routers, there will be n(n 1)/2 IBGP connections in the AS. For example, Figure 2-35 shows six fully
meshed IBGP routers, hardly a large number of routers; even here, however, 15 IBGP connections are needed.
Figure 2-35. Fully Meshed IBGP PeersRoute reflectors offer an alternative to fully meshed IBGP peers. A router is configured as a route reflector (RR), and other IBGP
routers, known as clients, peer with the RR only, rather than with every other IBGP router (see Figure 2-36). As a result, the number of
peering sessions is reduced from n(n 1)/2 to n 1. A router reflector and its clients are known collectively as a cluster.
Figure 2-36. IBGP Clients in a Route Reflection Cluster Peer Only with the Route Reflector, Reducing the
Number of Necessary IBGP Connections
Route reflectors work by relaxing the rule that IBGP peers cannot advertise routes learned from other IBGP peers. In the internetwork
of Figure 2-36, for example, the route reflector learns routes from each of its clients. Unlike other IBGP routers, the RR can advertise
these routes to its other clients and to nonclient peers. In other words, the routes from one IBGP client are reflected from the RR to the
other clients. To avoid possible routing loops or other routing errors, the route reflector cannot change the attributes of the routes it
receives from clients.
A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route
reflector in its cluster or other clients in the cluster. However, the RR itself can peer with both internal and external neighbors outside
of the cluster and can reflect their routes to its clients (see Figure 2-37).Figure 2-37. Route Reflection Cluster Peering Relationships
If an RR receives multiple routes to the same destination, it uses the normal BGP decision process to select the best path. RFC 1966
defines three rules that the RR uses to determine who the route is advertised to, depending on how the route was learned:
If the route was learned from a nonclient IBGP peer, it is reflected to clients only.
If the route was learned from a client, it is reflected to all nonclients and clients, except for the originating client.
If the route was learned from an EBGP peer, it is reflected to all clients and nonclients.
The route reflector functionality has to be supported only on the route reflector itself. From the clients' perspectives, they are merely
peering with an internal neighbor. This is an attractive feature of route reflectors, because routers with relatively basic BGP
implementations can still be clients in a route reflection cluster.
The concept of route reflectors is similar to that of route servers, discussed earlier in this chapter. The primary purpose of both devices
is to reduce the number of required peering sessions by providing a single peering point for multiple neighbors. The neighbors then
depend on the one device to learn their routes. The difference between route reflectors and route servers is that route reflectors are
also routers, whereas route servers are not.
A single RR, like a single route server, introduces a single point of failure into a system. If the RR fails, the clients lose their only
source of NLRI. Therefore, for redundancy, a cluster can have more than one RR (see Figure 2-38). The clients have physical
connections to each of the route reflectors, and they peer to each. If one of the RRs fails, the clients still have a connection to the
other RR and do not lose reachability information.
Figure 2-38. A Cluster Can Have Multiple Route Reflectors for RedundancyNOTE
Although it is possible for a client to have a physical link to only one RR and still peer to multiple RRs, this setup defeats the purpose
of having redundancy. The client is still vulnerable to the failure of the single RR to which it is physically connected.
An AS also can have multiple clusters. Figure 2-39 shows an AS with two clusters. Each cluster has redundant route reflectors, and
the clusters themselves are interconnected redundantly.
Figure 2-39. Multiple Route Reflection Clusters Can Be Created Within a Single Autonomous System
Because clients do not know they are clients, a route reflector can itself be a client of another route reflector. As a result, you can build
"nested" route reflection clusters (see Figure 2-40).
Figure 2-40. A Route Reflector Can Be the Client of Another Route ReflectorAlthough clients cannot peer with routers outside of their own cluster, they can peer with each other. As a result, a route reflection
cluster can be fully meshed (see Figure 2-41). When the clients are fully meshed, the route reflector is configured so that it does not
reflect routes from one client to another. Instead, it reflects only routes from clients to its nonclient peers, and routes from nonclient
peers to clients.
Figure 2-41. A Route Reflection Cluster Can Be Fully MeshedRecall from the discussion in the section "IBGP and IGP Synchronization" that BGP cannot forward a route learned from one internal
peer to another internal peer, because the AS_PATH attribute does not change within an AS, and routing loops could result. Note,
however, that a route reflector is a BGP router in which this rule has been relaxed. To prevent routing loops, route reflectors use two
BGP path attributes: ORIGINATOR_ID and CLUSTER_LIST.
ORIGINATOR_ID is an optional, nontransitive attribute that is created by the route reflector. The ORIGINATOR_ID is the router ID of
the originator of a route within the local AS. A route reflector does not advertise a route back to the originator of the route;
nonetheless, if the originator receives an update with its own RID, the update is ignored.
Each cluster within an AS must be identified with a unique 4-octet cluster ID. If the cluster contains a single route reflector, the cluster
ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a
cluster ID.
CLUSTER_LIST is an optional, nontransitive attribute that tracks cluster IDs the same way that the AS_PATH attribute tracks AS
numbers. When an RR reflects a route from a client to a nonclient, it appends its cluster ID to the CLUSTER_LIST. If the
CLUSTER_LIST is empty, the RR creates one. When an RR receives an update, it checks the CLUSTER_LIST. If it sees its own
cluster ID in the list, it knows that a routing loop has occurred and ignores the update.
Confederations
Confederations are another way to control large numbers of IBGP peers. A confederation is an AS that has been subdivided into a
group of subautonomous systems, known as member autonomous systems (see Figure 2-42). The BGP speakers within the
confederation speak IBGP to peers in the same member AS and EBGP to peers in other member autonomous systems. The
confederation is assigned a confederation ID, which is represented to peers outside of the confederation as the AS number of the
entire confederation. External peers do not see the internal structure of the confederation; rather, they see a single AS. In Figure 2-42,
AS 9184 is the confederation ID.
Figure 2-42. A Typical Confederation
You are very familiar with the concept of subdividing entities for better manageability. IP subnets are subdivisions of IP networks, and
VLSM subdivides subnets. Similarly, autonomous systems are subdivisions of large internetworks (such as the Internet).
Confederations are subdivisions of autonomous systems.
The section "AS_SET" described two types of AS_PATH attributes: AS_SEQUENCE and AS_SET. Confederations add two more
types to the AS_PATH:AS_CONFED_SEQUENCE This is an ordered list of AS numbers along a path to a destination. It is used in exactly the same
way as the AS_SEQUENCE, except that the AS numbers in the list belong to autonomous systems within the local
confederation.
AS_CONFED_SET This is an unordered list of AS numbers along a path to a destination. It is used in exactly the same way as
the AS_SET, except that the AS numbers in the list belong to autonomous systems within the local confederation.
Because the AS_PATH attribute is used in updates between the member autonomous systems, loop avoidance is preserved. From
the perspective of a BGP router within a member AS, all peers in other member autonomous systems are external neighbors.
When an update is sent to a peer external to the confederation, the AS_CONFED_SEQUENCE and AS_CONFED_SET information is
stripped from the AS_PATH attribute, and the confederation ID is prepended to the AS_PATH. Because of this, external peers see the
confederation as a single AS rather than as a collection of autonomous systems. As Figure 2-42 shows, it is common practice to use
AS numbers from the reserved range 64512 to 65535 to number the member autonomous systems within a confederation.
When choosing a route, the BGP decision process remains the same, with one addition: EBGP routes external to the confederation
are preferred over EBGP routes to member autonomous systems, which are preferred over IBGP routes. Another difference between
confederations and standard autonomous systems is the way in which some attributes are handled. Attributes such as NEXT_HOP
and MED can be advertised unchanged to EBGP peers in another member AS within the confederation, and the LOCAL_PREF
attribute also can be sent.
Unlike route reflector environments in which only the route reflector itself has to support route reflection, all routers within a
confederation must support the confederation functionality. This support is necessary because all routers must be able to recognize
the AS_CONFED_SEQUENCE and AS_CONFED_SET types in the AS_PATH attribute. Because these AS_PATH types are removed
from routes advertised out of the confederation, however, routers in other autonomous systems do not have to support
confederations.
In very large autonomous systems, you can use confederations and route reflectors together. You can configure one or more RR
clusters within one or more member autonomous systems for even more optimal control of IBGP peers.

==Pranala Menarik==

* [[IPv6: Advanced Routing]]

IPV6: BGP Managing Large Scale BGP Peer - Revision history

Onnowpurbo: Created page with "Managing Large-Scale BGP Peering The preceding section pointed out that when an AS becomes large, attempting to create fully meshed IBGP peers can be daunting. This is just on..."