How to Construct a Correct and Scalable iBGP Configuration Mythili Vutukuru Joint work with Paul Valiant, Swastik Kopparty and Hari Balakrishnan

BGP R R R R eBGP iBGP R Border routers/ Egress Internal routers A B C D F E Autonomous System (AS) BGP routers eBGP and iBGP Route

Our contribution  Status quo in configuring iBGP  Full-mesh (not scalable)  Route reflection (no correctness guarantees)  Problems with both approaches  New approach to configure iBGP that is both correct and scalable  Uses elegant results from graph theory

Outline of the talk  More background  What is the status quo?  What are the problems with it?  Problem statement  Our solution

Background - iBGP  iBGP sessions run on TCP  Overlay over the intra- domain routing protocol (IGP) like OSPF  Routing messages and data packets forwarded via IGP within AS  Routes from iBGP session not propagated to another iBGP session iBGP A B C D F E IGP R Route

Approach#1: Full-mesh iBGP R R R R R  Every router has an iBGP session to every border router  Not scalable A B C D E F Route iBGP session

Approach#2: Route reflection R  “Reflects” routes to and from client iBGP sessions  Avoids full-mesh  Hierarchy of reflectors Route reflector A B C D E F Route Client iBGP session

Problems with route reflection: #1  Problem #1: Routers may not choose best route  Why? Route reflector reflects only its best route  B chooses the sub-optimal route through C  In full-mesh B would have chosen route through A R A B C D E F Lower cost to egress Route Client session Data packets

Problem#2: Forwarding loops A B C D R1 R2 R R R: goto A R: goto D To: R IGP Route Client iBGP session Data packets IGP link

iBGP configurationCorrectnessScalability Full-mesh √ × Route reflection× √ We need √√ Background - Summary

Outline of the talk  More background  What is the status quo?  What are the problems with it?  Problem statement  Our solution

Problem Statement  Input: IGP (IP-level connectivity) graph  Output: iBGP configuration  Route reflectors and clients  iBGP sessions  Constraints  Emulate full-mesh  More scalable than full-mesh  Previous work [GW02] – how to check for correctness, not how to construct correct configurations [GW02] T. Griffin and G. Wilfong, “On the Correctness of iBGP Configuration”, In Proc. ACM SIGCOMM 2002, Pittsburg, PA, August 2002.

Outline of the talk  More background  What is the status quo?  What are the problems with it?  Problem statement  Our solution

Key insight for emulating full-mesh  For every router P, every egress E  P and E have iBGP session, OR  P should be the client of a route reflector on the shortest path between P and E A B C D R1 R2 R R R: goto D R: goto A To: R Route Client iBGP session Data packets IGP link

Our solution  S is graph separator  Nodes in graph separator S are route reflectors  u in G 1 or G 2, v in S: u is a client of v  Full-mesh in G 1, G 2  Recurse on G 1, G 2 G1G1 G2G2 S R R A B D ?

Evaluation  2.5 to 5X fewer iBGP sessions on ISP topologies [Source: Rocketfuel]

Conclusion  First algorithm to construct correct iBGP configurations with route reflection.  Efficient implementation  2.5 to 10X fewer iBGP sessions compared to full-mesh iBGP

Questions?

Best route selection  BGP best route selection rules  Local Pref  AS path length  MED  IGP cost to egress  Best route selected by route reflector might not be the best route for the client

Route reflection  2 types of iBGP sessions  Client iBGP session  Normal (“peer”) iBGP session  Route from client → all clients and peers  Route from peer → all clients  Multiple route reflectors  Hierarchy of route reflectors

Problems with route reflection  Lack of complete visibility: every router is not guaranteed to see its best available route.  Forwarding loops  Some router along the forwarding path chooses a different egress  Packets do not make progress towards egress and loop forever  Not robust to IGP changes  IGP link failures trigger forwarding loops  Full-mesh iBGP has none of these problems