IBGP Scalability Issues in a Transit AS

This topic explains the need for BGP route reflectors by describing the scalability issues of BGP transit backbones.

Classic Internal Border Gateway Protocol (IBGP) split-horizon rules specify that updates that are received on an External Border Gateway Protocol (EBGP) session should be forwarded on all IBGP and EBGP sessions, but updates that are received on an IBGP session should be forwarded only to all EBGP sessions. This rule requires a BGP boundary router to be able to send routing updates to all other BGP-speaking routers in its own autonomous system (AS) directly through a separate IBGP session to each of them.

The primary reason for the IBGP split-horizon rule is to avoid routing information loops within the AS. If the information that is received through an IBGP session is forwarded on other IBGP sessions, the information might come back to the originator and be forwarded again in a never-ending loop. The originator would not detect the loop because no BGP attributes are changed on IBGP sessions.

The general design rule in classic IBGP is to have a full mesh of IBGP sessions. But a full mesh of IBGP sessions between n number of routers would require (n * (n - 1)) / 2 IBGP sessions. For example, a router with an AS that contains 10 routers would require (10 * (10 -1)) / 2 = 45 IBGP sessions. Imagine the number of sessions (and the associated router configuration) that would be required for a single AS containing 500 routers.

Every IBGP session uses a single TCP session to another IBGP peer. An update that must be sent to all IBGP peers must be sent on each of the individual TCP sessions. If a router is attached to the rest of the network over just a single link, this single link has to carry all TCP/IP packets for all IBGP sessions. This requirement results in multiplication of the update over the single link.

6-22

Configuring BGP on Cisco Routers (BGP) v3.2

Route reflectors are BGP scalability mechanisms that enable routing information to be redistributed to all routers within an AS while eliminating the need for a fully meshed topology within the AS. This feature reduces the number of TCP sessions that must be maintained, lowering network overhead and CPU and memory resource requirements.

Two different solutions are available to achieve greater scalability when you are faced with the full-mesh rules of IBGP autonomous systems:

■ Route reflectors modify the classic IBGP split-horizon rule and allow a particular router to forward incoming IBGP updates to an outgoing IBGP session under certain conditions. This router becomes a concentration router, or a route reflector.

■ BGP confederations (covered in a separate lesson) introduce the concept of a number of smaller autonomous systems within the original AS. The small autonomous systems exchange BGP updates between them using intra-confederation EBGP sessions.

© 2005, Cisco Systems, Inc. Scaling Service Provider Networks 6-23

Route Reflector Split-Horizon Rules

This topic explains how route reflectors modify traditional IBGP split-horizon rules.

Route Reflector Split-Horizon Rules

Classic IBGP: IBGP routes are not propagated to other IBGP peers.

Full mesh of IBGP peers is therefore required.

Route reflector can propagate IBGP routes to other IBGP peers.

Full mesh of IBGP peers is no longer required.

Classic IBGP: IBGP routes are not propagated to other IBGP peers.

Full mesh of IBGP peers is therefore required.

Route reflector can propagate IBGP routes to other IBGP peers.

Full mesh of IBGP peers is no longer required.

In classic IBGP, the BGP boundary router needs to forward the route that is received from an EBGP peer to every other router within its own AS using a dedicated IBGP session for each one. Also, the BGP boundary router forwards routes that are sourced by a router in the same way. To allow every router to update every other router, a full mesh of IBGP sessions is required.

The IBGP route reflector design relaxes the need for a full mesh. The router configured as a route reflector, under certain conditions, will relay updates that are received through an IBGP session to another IBGP session. This capability requires modifications of the classic IBGP split-horizon rules.

The route reflector concept introduces processing overhead on the concentration router and, if it is configured incorrectly, can cause routing loops and instability.

6-24 Configuring BGP on Cisco Routers (BGP) v3.2 © 2005, Cisco Systems, Inc.

Route Reflector Split-Horizon Rules (Cont.)

Bgp Route Reflector Rule

When you implement a route-reflector-based IBGP network, the BGP routers are divided into route reflectors (which implement modified split-horizon rules) and clients (which are behaving like traditional IBGP routers).

Route reflector clients are excluded from the full mesh. They can have any number of EBGP sessions but may have only one IBGP session, the session with their route reflector. Clients conform to the classic IBGP split-horizon rules and forward a received route from EBGP on their IBGP neighbor sessions. But the route reflector conforms to the route reflector split-horizon rules and recognizes that it has an IBGP session to a client. When the IBGP update is received from the client, the route reflector forwards the update to other IBGP neighbors, therefore alleviating the IBGP full-mesh requirement for its clients.

Similarly, when the route reflector receives an IBGP update from a neighbor that is not its client, it forwards the update to all of its clients.

Forwarding of an IBGP update in a route reflector does not change the next-hop attribute or any other common BGP attribute. This feature means that the client will use the optimum route by means of recursive routing, regardless of the way that it has received the BGP route.

© 2005, Cisco Systems, Inc. Scaling Service Provider Networks 6-25

Route Reflector Split-Horizon Rules (Cont.)

The figure shows how an AS with nine routers running BGP reduces the required number of IBGP TCP sessions from 36 to 11 by using route reflectors.

The table presents detailed IBGP split-horizon rules as modified by the introduction of BGP route reflectors. For purposes of definition, a "route reflector" is a BGP speaker that can advertise IBGP learned routers to another IBGP peer and, hence, can reflect routes. IBGP peers of the route reflector fall under two categories: "clients" and "nonclients." The route reflector and its clients form a "cluster." All IBGP peers of the route reflector that are not part of the cluster are nonclients. A "classic" IBGP router is a router that does not support route reflector functionality.

Type of Router

Incoming Update From

Is Forwarded To

Classic

EBGP peer

All peers (IBGP and EBGP)

IBGP peer

EBGP peers

Route reflector

EBGP peer

All peers (IBGP and EBGP)

Nonclient IBGP peer

EBGP peers and clients

Client IBGP peer

All peers but the sender

Client

EBGP peer

All peers (IBGP and EBGP)

IBGP peer

EBGP peers

6-26 Configuring BGP on Cisco Routers (BGP) v3.2 © 2005, Cisco Systems, Inc.

Redundant Route Reflectors

This topic explains the benefits of deploying redundant route reflectors.

Redundant Route Reflectors

Clients may have any number of EBGP peers but may have IBGP sessions only with their route reflector or reflectors. If the reflector fails, its client can no longer send BGP updates to, or receive them from, the rest of the AS. The route reflector is, therefore, a single point of failure.

To avoid introducing a single point of failure into the network, the route reflector functionality must be as redundant as the physical network. If a client will still be physically attached to the network after its route reflector has failed, the client should have a redundant route reflector. Thus, in all highly available networks, route reflectors must be redundant.

© 2005, Cisco Systems, Inc. Scaling Service Provider Networks 6-27

Redundant Route Reflectors (Cont.)

A client may have IBGP sessions to more than one route reflector to avoid a single point of failure. Each client will receive the same route from both of its reflectors. Both route reflectors will receive the same IBGP update from their client, and they will both reflect the update to the rest of the clients. Additionally, both route reflectors will get updated from the full mesh and reflect those updates to their clients. As a result, each client will get two copies of all routes. Under certain circumstances (particularly when you use weights on IBGP sessions to influence BGP route selection), improper route reflection can result in an IBGP routing loop that is impossible to detect. Additional BGP attributes are thus necessary to prevent these routing loops.

6-28 Configuring BGP on Cisco Routers (BGP) v3.2 © 2005, Cisco Systems, Inc.

Route Reflector Clusters

This topic explains how route reflector clusters prevent loops in the deployment of route reflectors in redundant configurations.

A router that is acting as a route reflector client does not require any specific configuration. It simply has fewer IBGP sessions than it would have if it were part of the full mesh. But improperly configuring the client to also be a reflector could easily cause a loop. An IBGP route coming in from one of the real reflectors to the client could be forwarded by the client, erroneously acting as reflector, to the other reflector.

Route reflector clusters prevent IBGP routing loops in redundant route reflector designs.

The role of the network designer is to properly identify which route reflectors and their clients will form a cluster. The designer assigns to the cluster a cluster-ID number that is unique within the AS.

Note The cluster-ID number must be configured in the route reflectors. The clients should not be configured with this information.

A route reflector router can reflect routes only within a single cluster. A route reflector can, however, participate in another cluster but only as a client. A client can function as a client only to a route reflector belonging to the same cluster.

When a route is reflected, the reflector creates the cluster-list attribute and attaches it to the route if it does not already exist. It then sets its cluster-ID number in the cluster-list or adds its cluster-ID number to an already existing cluster-list attribute. If the route, for any reason, is ever reflected back to the same reflector, it will recognize its cluster-ID number in the cluster-list and not forward it again. The first route reflector that reflects the route also sets an additional BGP attribute, called "originator-ID," and adds it to the BGP router-ID of its client.

© 2005, Cisco Systems, Inc. Scaling Service Provider Networks 6-29

Note

The cluster-list and originator-ID attributes are nontransitive optional BGP attributes, allowing routers that do not support route reflector functionality to coexist with route reflectors and their clients in the same AS.

Based on cluster-list and originator-ID attributes, routers can implement two loop-prevention mechanisms:

■ Any router that receives an IBGP update with the originator-ID attribute set to its own BGP router-ID will ignore that update.

■ Any route reflector that receives an IBGP update with its cluster-ID already in the cluster-list will ignore that update.

6-30 Configuring BGP on Cisco Routers (BGP) v3.2 © 2005, Cisco Systems, Inc.

Was this article helpful?

+1 0
Search Engine Optimization Overview

Search Engine Optimization Overview

This is the 2nd volume of a 9 volume series called the Webmasters Toolbox package. Search engines are the number one way that internet users find websites. In most cases, a listing in a search engine is free. So, it's no surprise that Search Engine Optimization SEO is often the first priority when marketing a website.

Get My Free Ebook


Post a comment