Scaling iBGP

BGP

• iBGP– Internal BGP– BGP peering between routers in same AS– Goal: get routes from a border router to another

border router without losing detail• Communities, localpref, etc.

• eBGP– External BGP– BGP peering between routers in different ASes

AS1

External BGP

Internal BGP

1a

1b1c

1d

AS2

AS3

AS4

AS5

1a

1b

1c

1dAS2

AS3

AS4

AS5

Routes arriving from AS2will be redistributed via iBGPfrom 1b to 1a, 1c, 1d.

1a

1b

1c

1dAS2

AS3

AS4

AS5

1d will announce route learnedto AS4 if appropriate• BGP decision process

iBGP Requirement for Full Mesh

• An iBGP router will not further advertise a prefix with its own ASN in AS path– to prevent routing information loops

• Therefore iBGP has to be in full mesh for eBGP routes to propagate; (n * (n-1)) / 2

3 peers, 3 sessions 4 peers, 6 sessions 5 peers, 10 sessions

Scaling Issues

• 100 peers; 4950 sessions• 101 peers; 5050 sessions• Requires significant operator resource

whenever new router is added to network– operator has to manually setup n-1 iBGP

sessions each time a new eBGP router is added to AS

• Significant BGP protocol overhead for each router

Two Methods for Scaling iBGP

• Confederations– RFC 5065

• Route reflection– RFC 4456

• Both approaches break AS into hierarchy to reduce size of iBGP domain– logical hierarchy tends to follow physical

structure

Scaling iBGP: Confederations

iBGP

iBGP

iBGP

iBGP

iBGP

iBGP

iBGPiBGP

iBGP

eBGP

eBGPeBGP

AS 1

AS 64513 AS 64514

AS 64515

eBGP eBGP

eBGP

eBGPeBGP

eBGP

Scaling iBGP: Confederations

• full iBGP mesh within confederation• eBGP between confederations• eBGP to external ASes

• AS_CONFED_SEQUENCE• AS_CONFED_SET

• AS_CONFED numbers are removed from routes propagated outside parent AS

Scaling iBGP: Confederations

• Advantages– Easier to deal with smaller iBGP mesh when

new eBGP router is added– Reduces number of iBGP sessions

• Disadvantage– Requires network to be reconfigured; no

incremental deployment

Scaling iBGP: Route Reflectors

iBGP

iBGP

iBGP

AS 1

eBGP eBGP

eBGP

eBGPeBGP

eBGP

RRiBGPeBGPiBGP

cluster

non-client

iBGP

iBGP

iBGP

iBGPclient

iBGP

iBGP

Scaling iBGP: Route Reflectors

• Clients vs. non-clients– RR clients should not peer with routers

outside cluster– Non-clients of RR must be fully meshed– Easier to add new client to RR cluster than to

add non-client.

• RR will only advertise best paths learned

Scaling iBGP: Route Reflectors

• Advantage: Incremental deployment– Non-RR speakers continue with iBGP mesh– Though less iBGP sessions as they are a

non-client of RR

BGP RR attributes

• BGP-optional, non-transitive attributes– used in RR situation to prevent routing information loops

• ORIGINATOR_ID– 4 bytes, specifies the iBGP router that first announced the route– Router should ignore prefix with its own ORIGINTOR_ID in this

field

• CLUSTER_ID– 4 bytes, specifies a RR cluster the prefix came from

• CLUSTER_LIST– List of CLUSTER_ID fields– A router should ignore prefix with its own CLUSTER_ID in it

Scaling iBGP: Route Reflectors

• Need redundancy in RR cluster– If RR fails, clients become isolated.– Solution: multiple RR per cluster

RR

RR

Hierarchical Route ReflectionAS 1

RR

RR

RR

RR

RR

RR

Putting it all togetherAS 1

RR,P

RR,P

PE

PE

PE

PE

PE

PE

PE

PEPE

RR,P

RR,P

RR,PRR,P

Further Reading

• Chapter 8, Internet Routing Architectures (Bassam / Halabi)

• RFC 5065 - Autonomous System Confederations for BGP

• RFC 4456 - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)