Alternatives to Full Mesh IBGP

Presented by:Chandrika Duggirala

ECE 697F24th October 2000

Introduction

Border Gateway Protocol Designed for Inter AS Routing Each AS has BGP speakers for EBGP and

IBGPConfigured that all BGP speakers be

fully meshed For n speakers, n*(n-1)/2 unique BGP

TCP sessions

Full Mesh Routing

Some Alternatives

Several mechanisms being deployed: Route-Servers

Routers which would relay external routes with attributes between client routers

All routes are unmodified - virtual peering

Route Reflectors Confederations

Of these, Route Reflectors and Confederations are dominantly deployed

Papers being covered

With respect to Route Reflection and AS Confederations, we will be looking at 4 papers: BGP Route Reflection AS Confederations for BGP A Comparison of Scaling Techniques for

BGP BGP Scaling Techniques Revisited

Route Reflection

RFC 2796- BGP Route Reflection T.Bates ; R.Chandra

Based on the concept of a router forwarding routes to its peers.

Design Criteria: Simplicity Easy Migration Compatibility

Introduction to RRs

RTR B is allowed to reflect the route it receives from RTR A to RTR C

RTR B is the Route Reflector (RR)

Courtesy

Terminology

Route Reflector - Router that participates in route reflection

Client Peers-Internal peers of an RR that do not need to be fully meshed

Non Client Peers-Internal peers that need to be fully meshed

Cluster-An RR with its client peers forms a cluster

Another Model of RRs

Operation

Route from a Non-Client Peer: advertised to all clients Route from a client:advertised to all clients and non

client peers Hence,they need not be completely meshed

Route from an external BGP speaker: advertised to all clients and non client peers.

Backbone divided into Clusters. Each RR may be configured with other RRs as a client

or non client peer Conventional BGP speakers may be a part of a client

group or non client group

Configuration Commands

A cluster is identified by a ROUTER_ID

Multiple RRs in a single cluster may be used to avoid single point of failure

In case of multiple RRs in a cluster, RRs are configured with a CLUSTER_ID

Some Configuration Commands: neighbor ip-address | peer-group-name route-

reflector-client :Configures the local router as a BGP route reflector and the specified neighbor as a client.

bgp cluster-id cluster-id :Configures the cluster ID

no bgp client-to-client reflection: Disables client-to-client route reflection.

Configuration

Loop Avoidance

Mis-configurations may form loops To avoid and detect loops:

ORIGINATOR_ID: optional attribute;4 bytes Created by RR and carries the routerID of the originator of

the route CLUSTER_LIST: optional attribute

Sequence of of CLUSTER_ID values representing the reflection path of the route

RR appends its local Cluster_ID to Cluster_List while reflecting to non client peer

If Cluster_List is empty,a new one is created If local Cluster_ID found in the list,advertisement of route is

ignored

Loop Avoidance contd.

From the figure, Consider RR1,RR2,R1,R2 and

R3 to be the same AS and E1,F1 and E2 different ASs

IGP costs: RR1->R1/E1=RR1->R2 RR2->R3/E2=RR2-> R1/E1 &

R2/F1 RR1 chooses F1->low

routerID RR2 chooses E2->low

routerID But,in full mesh,F1 would be

the route used

Figure and Table are courtesy of the Internet Draft-Route Reflection Considered Harmful-Dube

Configuration & Deployment

Manual configuration to identify a client Decisions based on MED and IGP values may not

give the same route selection as full mesh To ensure same route selection:

RRs do not use the IGP values for routing Achieved by having full meshed clients

RR route selection not based on incomparable MED values

POP based Reflection may be used where each POP maintains its own RRs which are fully meshed and clients

Summary(1)

To avoid loops and able proper functioning of the network, topology must be carefully considered

Security issues have not been considered in the paper

AS Confederations

RFC 1965-Autonomous System Confederations for BGP P.Traina

Alternate technique to full mesh IBGP ASs can be very large:

Requires large intra domain BGP connections

Form Confederations Based on the concept of sub dividing ASs with large BGP

speakers into smaller domains Control routing policy information using AS_PATH

Collection of ASs under a common administration can be viewed as a single AS or entity

Terminology

AS Confederation-Collection of ASs advertised as a single entity

AS Confederation Identifier-Externally visible AS number identifying the whole entity

Member AS-AS contained in an AS confederation

Refresher about the AS_PATH attribute

AS_PATH is a path attribute of the UPDATE message of BGP inter-domain routing

List of ASs through which the UPDATE message has passed

Sequence of AS path segments Represented by:

path segment type/length and value The “type” field is 1 octet and can take the values:

1 - AS_SET 2 - AS_SEQUENCE

Configuration

AS_CONFED segment type extension of AS_PATH: Path segment type represented by 1-octet field:

AS_SET:unordered set of ASs in the route of an UPDATE message AS_SEQUENCE:ordered set in the same AS_CONFED_SET:unordered set of ASs in local confederation in

UPDATE message AS_CONFED_SEQUENCE :ordered set in the same

bgp confederation identifier autonomous -

system: Configures a BGP confederation

bgp confederation peers autonomous-system [autonomous-system ...] :Specifies the autonomous systems that belong to the confederation

Configuration

Operation AS uses Confed ID for routing with members of other

confederations AS uses its routing domain ID (internally visible AS #) with

members of the same AS AS Modification Rules: A BGP speaker may propagate routes,modification of the

AS_PATH depends on the forwarding of the route: When a BGP speaker advertises a route to a speaker in its own

AS,the AS_PATH attribute is not modified When a BGP speaker advertises route to a neighboring AS of

the same confederation: If the first segment is AS_CONFED_SEQUENCE,the local AS

prepends its own AS number If not,the AS prepends a new path segment of

AS_CONFED_SEQUENCE and includes its confed number

Operation contd.

When a BGP speaker advertises a route to a BGP speaker of another confederation,the advertising BGP speaker does the update:

If the first segment is of type AS_CONFED_SEQUENCE, that segment and any immediate segments of type AS_CONFED_SET are removed

If the first segment is AS_SEQUENCE,the local speaker prepends its confed ID to the AS_PATH

If there are no path segments following the removal of AS_CONFED_SET/SEQUENCE, or if the first segment is of type AS_SET, the local speaker prepends the AS_SEQUENCE to the AS_PATH and its own confed ID

Operation contd.

When a BGP speaker originates a route:

Includes an empty AS_PATH attribute to all UPDATE messages to speakers of the same AS

Includes its own AS number in the AS_CONFED_SEQUENCE in UPDATE messages to speakers of neighboring ASs of the same confed

Includes own confed ID in the AS_SEQUENCE in UPDATE messages to speakers/ASs of other confederations

Deployment and Compatibility

A BGP speaker can advertise an unchanged NEXT_HOP and MULTI_EXIT_DISCRIMINATOR attribute to peers of the same AS

It can also advertise the LOCAL_PREFERENCE attribute to peers of the same confederation

Path selection criteria for information received from members of a confederation follows the same rules as information received from within an AS

All speakers participating in a confederation must recognize the AS_PATH attributes specific to confederations

Summary(2)

Confederations may increase complexity of routing

Increases maintenance overheadIncreases the AS_PATH segment lengthRequires that all members be aware of the AS

ConfederationsDecreases the number of BGP sessions required

Comparison

A Comparison of Scaling Techniques for BGP

Scaling techniques RevisitedRohit Dube

Route Reflection AS Confederations

Looked at : Deployment Problems and Scalability

Comparison

Route Reflection and AS Confederations avoid full mesh IBGP

Similar to the Hub and Spoke topology Route Reflection:

Works by changing the behavior of IBGP sessions

AS Confederations: Works by changing the behavior of EBGP sessions

Comparison

RRs : Break the “don’t propagate IBGP routes” rule Typically arranged in a 2 level hierarchy where

the RR servers are full meshed Servers are physically located in a POP

facility,in pairs for redundancy

AS Conferations: Consists of sub-ASs, each with full mesh IBGP

sessions The boundary between 2 sub ASs runs CBGP

Deployment

RR: Requires s/w upgrade only on routers designated as

servers.Clients are unaffected Accommodates conventional BGP speakers that do not

participate in RR

AS Confederations: Requires all routers to be able to process segment type

extensions All routers require a s/w upgrade Hence,a more unlikely option as compared to RR

Problems Persistent Loop: Occurs in RRs and AS

Confederations RR:

RR1 and RR2- RRs RR1&R4 and RR2&R3 form

clusters E1andE2-separate AS with RR1

and RR2 peers respectively If E1 and E2 advertise same

prefix, RR1->R4&RR2->R3 R3 and R4 end up pointing to

each other AS confederations:

RR1 and R4 & RR2 and R3 form 2 sub ASs

R3 and R4 have CBGP sessions

Problems contd.

Sub Optimal Routing: Can occur in AS

confederations R1,R2,R3 belong to a

confederation and different sub-ASs

E advertises N to R1 R1 advertises to R2 and

R3 and they redadvertise it to each other

R3 may choose a route to N through R2,the sub optimal route

Scalability

Route Reflector: Hub and Spoke

network of 400 routers

20 POPs with 2 servers and 18 clients

Each server sees 18+1+19*2=57 IBGP sessions

Scalability contd.

AS Confederations:Network of 399 routers and 20 sub-ASs One hub of 19 routers and 19 spokes of 20

routers eachEach spoke has 2 border routers, each

peering with 2 routers of the central sub-AS

Number of CBGP sessions: 19*2*2=76

Session Degree

Number of BGP sessions in confederations is fewer

In a 3 level hierarchy,by similar calculations,it can be shown that the RR topology can be deployed using fewer sessions

But 3-level hierarchy is not used: To maintain simplicity in the network To reduce latency in propagation of routing

updates

Conclusions

RR and AS confederations provide a good alternative to full mesh IBGP

RR and AS Confederations are identical in terms of scaling properties

RR is backward compatible and can be incrementally deployed

Confederations decrease the number of BGP peering sessions better for lower levels of hierarchy

Both support multiple levels of hierarchy

Figures are courtesy of the papers from the reading schedule

Future Work

How much time would be required for convergence in the face of failures for IBGP?

Affect of the mechanisms on stability of the network