Interdomain Traffic Engineering with BGP By Behzad Akbari Fall 2008 These slides are based on the slides of Tim. G. Griffin (AT&T) and Shivkumar (RPI)

Real World: Multiple Links Between Domains Middle of path 4 3 5 2 7 6 1 Web server Client

BGP Decision Process Lowest IGP cost to next hop Highest local preference Lowest AS path length Lowest ORIGIN type Lowest MED (with same next hop AS) I-BGP < E-BGP Lowest IGP cost to next hop Lowest router ID of BGP speaker

BGP Route Selection Process If NEXTHOP is inaccessible do not consider the route. Prefer largest LOCAL-PREF If same LOCAL-PREF prefer the shortest AS-PATH. If all paths are external prefer the lowest ORIGIN code (IGP<EGP<INCOMPLETE). If ORIGIN codes are the same prefer the lowest MED. If MED is same, prefer min-cost NEXT-HOP If routes learned from EBGP or IBGP, prefer paths learnt from EBGP Final tie-break: Prefer the route with I-BGP ID (IP address)

Route Selection Summary Highest Local Preference Enforce relationships Shortest ASPATH Lowest MED traffic engineering i-BGP < e-BGP Lowest IGP cost to BGP egress Lowest router ID

Hot-Potato Routing dest multiple egress points New York San Francisco 9 10 ISP network this and the next slide explain the problem. explain egress point link weights determine both intradomain path and selection of egress points Dallas All traffic from customer to peers All traffic to customer prefixes with multiple connections Hot-potato routing = route to closest egress point when there is more than one route to destination

Hot-Potato Routing Change dest 11 New York San Francisco 9 10 ISP network - failure - planned maintenance - traffic engineering 11 a typical BGP table has 150K routes. non-linearity in the system: small changes inside the network may cause many external routes to shift egress points. anecdote: performance impact for some application Routes to thousands of destinations switch egress points!!! Dallas Consequences: Transient forwarding instability Traffic shift Interdomain routing changes

Tuning BGP to control the outgoing traffic Principle To control its outgoing traffic, a domain must tune the BGP decision process on its own routers How to tune the BGP decision process ? Filter some routes learned from some peers local-pref usual method of enforcing economical relationships MED usually, MED value is set when sending a route but some routers allow to insert a MED in a received route allows to prefer routes over others with same AS Path length IGP cost to nexthop setting of IGP cost for intradomain traffic engineering several routes in forwarding table instead of one

Load-Balancing Knobs in BGP LOCAL-PREF: outbound traffic, local preference (box-level knob) MED: Inbound-traffic, typically from the same ISP (link-level knob) Local Preference AS1 AS2 MED

Local Preference Attribute Local to AS It is never advertised to an eBGP peer. Used to influence BGP path selection AS 3847 F E G C D 208.1.1.0/24 80 Default 100 Highest local-pref preferred For example, you can express the policy “prefer private connect” by making the “local_pref” be 150 and leaving all other peers at 100. 208.1.1.0/24 100 Preferred by all AS3847 routers A B 208.1.1.0/24 AS 6201

Controlling incoming traffic by outbound BGP routes Outbound BGP routes make traffic come in It’s a lot harder to control inbound traffic as other ASs’ policies complicate your life! If you are a stub AS with a single connection Not much you need to do except to filter out routes not in your AS If you are a multi-homed stub AS, Want to control through which link/provider that traffic to certain destinations in your AS may take, to load balance or for back-up If you are an ISP, you want to minimize transit cost, carry transit traffic from customers only ! use “hot-potato” routing to hand off traffic to peers/providers as soon as possible to load balance, or to ensure reliability with back-up routes

Why Inbound Traffic is Hard to Manage Other ASes decide how to send to you Destination-based routing Other ASes decide which path to take Based on their own policies 2 p 1 4 3 AS 2 doesn’t know how AS 1 will send traffic toward p

Tuning BGP to control the incoming traffic Principle To control its incoming traffic, a domain must tune the BGP advertisements sent by its own routers How to tune the BGP advertisements ? Do not announce some routes to from some peers advertise some prefixes only to some peers MED insert MED=IGP cost, usually requires bilateral agreement AS-Path artificially increase the length of AS-Path

AS Prepending Artificial increasing AS path length “3 4 5” “3 3 3 4 5” Prepend your own AS in the path E.g., turn “3 4 5” into “3 3 3 4 5” Hope to make the path less attractive “3 4 5” 1 3 “3 3 3 4 5”

ASPATH Padding: Shed inbound traffic provider 192.0.2.0/24 ASPATH = 2 2 2 192.0.2.0/24 ASPATH = 2 Padding will (usually) force inbound traffic from AS 1 to take primary link primary backup customer 192.0.2.0/24 AS 2

Padding May Not Shut Off All Traffic AS 1 AS 3 provider provider 192.0.2.0/24 ASPATH = 2 192.0.2.0/24 ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2 AS 3 will send traffic on “backup” link because it prefers customer routes and local preference is considered before ASPATH length! Padding in this way is often used as a form of load balancing primary backup customer 192.0.2.0/24 AS 2

Multiple Exit Discriminator (MED) Tell your neighbor what you want MED attribute to indicate receiver preference Decision process picks route with smallest MED Can use MED for “cold potato” routing But, have to get your neighbor to accept MEDs “3 4 5” with MED=1 1 3 “3 4 5” with MED=2

Hot Potato Routing: Closest Egress Point 192.44.78.0/24 egress 2 egress 1 IGP distances 56 15 This Router has two BGP routes to 192.44.78.0/24. Hot potato: get traffic off of your network as Soon as possible. Go for egress 1!

Getting Burned by the Hot Potato Heavy Content Web Farm 2865 High bandwidth Provider backbone 17 SFF NYC Low bandwidth customer backbone 56 15 San Diego tiny http request huge http reply

Cold Potato Routing with MEDs (Multi-Exit Discriminator Attribute) Heavy Content Web Farm Prefer lower MED values 2865 17 192.44.78.0/24 MED = 56 192.44.78.0/24 MED = 15 56 15 192.44.78.0/24 This means that MEDs must be considered BEFORE IGP distance! Note1 : some providers will not listen to MEDs Note2 : MEDs need not be tied to IGP distance

MEDs Can Export Internal Instability Heavy Content Web Farm 2865 17 FLAP FLAP 192.44.78.0/24 MED = 56 OR 10 192.44.78.0/24 MED = 15 10 FLAP FLAP 56 15 FLAP 192.44.78.0/24