| 0 comments ]

Designing Scalable BGP Designs

Add a note hereBorder Gateway Protocol is commonly used in sites with multiple connections to the Internet. BGP is also frequently present in medium- to large-scale networks to provide a controlled interconnection between multiple routing domains running OSPF or EIGRP. Large-scale internal BGP networks are also becoming more prevalent as large enterprises implement internal Multiprotocol Label Switching (MPLS) VPNs for security segmentation, business unit or brand isolation, and similar purposes.

Add a note hereThis section discusses designing advanced routing solutions using BGP. It describes how to identify scaling issues in internal BGP designs and how to use techniques to alleviate these issues.

Add a note hereUpon mastering the content in this section, you will be able to describe and use various concepts to perform advanced routing design. This ability includes being able to meet these objectives:

  • Add a note hereIdentify the scaling issues with internal BGP requiring a full-mesh topology

  • Add a note hereDescribe scaling IBGP with route reflectors

  • Add a note hereDescribe scaling IBGP with confederations


Scaling BGP Designs

Add a note hereThis section discusses aspects of scaling in basic internal BGP (IBGP) design (see Figure 3-22).

Image from book
Add a note hereFigure 3-22: IBGP Full-Mesh Requirement

Add a note hereBGP can provide a controlled interconnection between multiple routing domains running OSPF or EIGRP and support internal MPLS VPNs. IBGP requires a full mesh of BGP peers.

Add a note hereThe full mesh of IBGP routers is needed because IBGP routers do not re-advertise routes learned via IBGP to other IBGP peers. This behavior is part of BGP protocol behavior that is used to prevent information from circulating between IBGP speaking routers in a routing information loop or cycle. External BGP (EBGP) relies on the autonomous system path to prevent loops. However, there is no way to tell whether a route advertised through several IBGP speakers is a loop. Because IBGP peers are in the same autonomous system, they do not add anything to the autonomous system path, and they do not re-advertise routes learned via IBGP.


Full-Mesh IBGP Scalability

Add a note here Because IBGP requires a full mesh of peers, scaling the full mesh is a concern. In general, for N peers in an IBGP full mesh, each would have N – 1 peers. There are N(N – 1) / 2 peering relationships. This means that each peer would need the CPU, memory, and bandwidth to handle updates and peer status for all the other routers. This is not a hierarchical design, and it would not be cost-effective to scale for large networks.

Add a note hereThere are two IBGP alternatives to scale IBGP:

  • Add a note hereRoute reflectors

  • Add a note hereConfederations

Add a note hereThe following sections explore the basic design and behavior of route reflectors and confederations and demonstrate how they can be used in a routing design.


Scaling IBGP with Route Reflectors

Add a note here A BGP route reflector is an IBGP speaker that reflects or repeats routes learned from IBGP peers to some of its other IBGP peers (see Figure 3-23).

Image from book
Add a note hereFigure 3-23: BGP Route Reflectors

Add a note hereTo prevent loops, a route reflector adds an originator ID and a cluster list to routes that it reflects between IBGP speakers. These attributes act similarly to the autonomous system path attribute to prevent routing information loops.

Add a note hereAll configuration of the route reflector is done on the route reflector itself. The configuration identifies which IBGP peers are route reflector clients.

Add a note hereImplementing route reflectors is fairly simple and can be done incrementally. Each client router needs to be configured as a client on the route reflector or on multiple route reflectors. Unnecessary peers can then be removed from the configuration on the client router. Often, route reflector clients peer only with the route reflectors. In a service provider network, route reflector clients might also be provider edge (PE) devices, which also peer with customers using EBGP.

Add a note hereTo avoid a single point of failure, redundant route reflectors are typically used.


BGP Route Reflector Definitions

Add a note hereA route reflector client (see Figure 3-24) is an IBGP router that receives and sends routes to most other IBGP speakers via the route reflector. The route reflector client needs no special configuration, other than removing peering with some or all neighbors other than the route reflector.

Image from book
Add a note hereFigure 3-24: BGP Route Reflector Definitions

Add a note hereA cluster is a route reflector together with its clients. The route reflector relieves the route reflector client routers of needing to be interconnected via an IBGP full mesh.

Add a note here Route reflector clusters may overlap.

Add a note hereA nonclient router (see Figure 3-25) is any route reflector IBGP peer that is not a route reflector client of that route reflector.

Click to collapse
Add a note hereFigure 3-25: Additional BGP Route Reflector Definitions

Add a note hereRoute reflectors are typically nonclients with regard to the other route reflectors in the network.

Add a note hereRoute reflectors must still be fully IBGP meshed with nonclients. Therefore, route reflectors reduce meshing within clusters, but all mesh links outside the cluster must be maintained on the route reflector. The route reflector clients will get information from IBGP speakers outside the cluster via the route reflector.

Add a note here If a route reflector receives a route from a nonclient, it reflects it to route reflector clients but not to other nonclients. The route reflector receives the routes if it has a direct peering relationship to the original nonclient. The route reflector would also send the route to EBGP peers, which is standard behavior. IBGP routes get repeated to all EBGP peers.


Route Reflector Basics

Add a note hereThis section provides a brief look at how route advertisement works with route reflectors (see Figure 3-26).

Image from book
Add a note hereFigure 3-26: Route Reflector Basics

Add a note hereIf a route reflector receives a route from an EBGP peer, it passes that route to all route reflector clients and nonclients, just as in normal IBGP peering behavior.

Add a note hereIf the route reflector receives a route from a route reflector client, it reflects the route to the other clients within the cluster, and nonclients. It also reflects the route to EBGP peers. Another way to think of this: The route reflector takes over the communication for the route reflector clients, passing along all the messages they would normally transmit directly via a peering session.


Scaling IBGP with Confederations

Add a note here BGP confederations are another way of scaling IBGP. Their behavior is defined in RFC 3065. Confederations insert information using the autonomous system path into BGP routes to prevent loops within an autonomous system. The basic idea with confederations is to divide a normal BGP autonomous system into multiple sub-autonomous systems. The outer or containing autonomous system is called the confederation autonomous system. This is all that is visible to the outside world.

Add a note hereEach of the inner autonomous systems is a smaller sub-autonomous system that uses a different autonomous system number, typically chosen from the private autonomous system number range of 64,512 through 65,534.


BGP Confederation Definitions

Add a note hereThis topic defines terms used with confederations (see Figure 3-27).

Click to collapse
Add a note hereFigure 3-27: Confederation Definitions

Add a note herePeers within the same sub-autonomous system are confederation internal peers.

Add a note hereIBGP peers that are in a different sub-autonomous system are confederation external peers.

Add a note here As IBGP information is passed around within a confederation autonomous system, the sub-autonomous system numbers are put into a confederation sequence, which works like an autonomous system path.


Confederation Basics

Add a note hereRoute advertisement with confederations works similarly to that of route reflectors in the following ways:

  • Add a note hereA route learned from an EBGP peer is advertised to all confederation external and internal peers.

  • Add a note hereA route learned from a confederation internal peer is advertised to all confederation external peers, and also to EBGP peers.

  • Add a note hereA route learned from a confederation external peer is advertised to all confederation internal peers, and to EBGP peers.

Add a note hereAnother way to understand this is that IBGP between sub-autonomous systems acts like EBGP. Private autonomous system numbers are used internally within the confederation autonomous system and removed from updates sent outside the confederation.


Confederations Reduce Meshing

Add a note hereLike route reflectors, confederations are used to reduce the amount of IBGP meshing needed. Without route reflectors or confederation, IBGP requires a full mesh of peering relationships, as illustrated in Figure 3-28.

Image from book
Add a note hereFigure 3-28: IBGP Full-Mesh Peering

Note

Add a note hereNote that the IBGP does not require peers to be directly connected.

Add a note hereHowever, confederations can reduce meshing requirements, as shown in Figure 3-29.

Image from book
Add a note hereFigure 3-29: Confederations Reduce the Number of IBGP Peers

Add a note hereRouters in different sub-autonomous systems do not peer with each other, except at sub-autonomous system borders. It is generally recommended to use two or three links between sub-autonomous system borders. More links just consume CPU and memory in the border routers.

Add a note hereWhen you use sub-autonomous systems for confederations, the meshing is restricted to within the sub-autonomous systems, with some additional peering between sub-autonomous system border routers.

Add a note hereRoute reflectors can be used within confederations to further reduce network complexity. Historically, service providers have not done this, but they are now starting to. Using route reflectors alleviates the need to fully mesh within a sub-autonomous system.


Deploying Confederations

Add a note here In Figure 3-30, router B could be configured to set the BGP next hop to itself for advertisement to routers C and D. This is not normally done by IBGP routers. This would impose the constraint that routers C and D would need to have routes to the new next hop, router B.

Click to collapse
Add a note hereFigure 3-30: Deploying Confederations

Add a note hereUsing this configuration breaks the confederation up from a next-hop perspective from both the IGP and BGP point of view. This scenario allows for more flexibility and scaling in very large networks. This deployment might make sense for very large organizations that support separate entities such as government organizations that have distinct branches or divisions.

Add a note hereUsing confederation sub-autonomous systems has other advantages. The IBGP policies can differ internally within and between the sub-autonomous systems. In particular, multi-exit discriminator (MED) acceptance or stripping, local preference settings, route dampening, and so on can vary between sub-autonomous systems. In addition, policy controls can be used on peerings between sub-autonomous systems.

Add a note hereThis highlights some advantages of confederations. Confederations can ease the transition in an acquisition or merger. The new network can be treated as another sub-autonomous system and keep its IGP. It can also keep its EBGP policies with its customers.

Add a note hereA disadvantage of confederations is that there is no graceful way to migrate from full mesh to using confederations. The migration may well require downtime.

Add a note here Table 3-1 compares how confederations and route reflectors provide various IBGP scaling features.

Add a note here Table 3-1: Comparing Confederations to Route Reflectors
Open table as spreadsheet

Add a note hereConfederation

Add a note hereRoute Reflector

Add a note hereLoop prevention

Add a note hereAS confederation set

Add a note hereOriginator or set cluster ID

Add a note hereBreak up a single AS

Add a note hereSubautonomous systems

Add a note hereClusters

Add a note hereRedundancy

Add a note hereMultiple connections between subautonomous systems

Add a note hereClient connects to several reflectors

Add a note hereExternal connections

Add a note hereAnywhere in the network

Add a note hereAnywhere in the network

Add a note hereMultilevel hierarchy

Add a note hereReflectors within subautonomous systems

Add a note hereClusters within clusters

Add a note herePolicy control

Add a note hereAlong outside borders and outside subautonomous systems

Add a note hereAlong outside borders

Add a note hereScalability

Add a note hereMedium; still requires full IBGP within each sub-AS

Add a note hereVery high

Add a note hereMigration

Add a note hereVery difficult

Add a note hereModerately easy (impossible in some situations)

Add a note hereIn general, route reflectors are simpler to migrate to and relatively simple to use, whereas confederations are more flexible as to IGP and policy.


0 comments

Post a Comment