iBGP Scalability Part II: Route Reflectors topologies - - PDF document

1/5/11 1

iBGP ¡Scalability ¡ Part ¡II: ¡Route ¡Reflectors ¡topologies ¡

Eduardo ¡Grampín ¡Castro ¡

Overview ¡of ¡Part ¡I ¡

• RelaBonships ¡Among ¡Networks ¡and ¡Interdomain ¡RouBng ¡

– Gao-­‑Rexford ¡

• ImplemenBng ¡Inter-­‑Network ¡RelaBonships ¡with ¡BGP ¡

– Policy-­‑based ¡rouBng ¡(which ¡metric ¡is ¡minimized?) ¡

• Not ¡Link-­‑State ¡nor ¡Distance-­‑Vector ¡
• Sessions ¡vs. ¡Flooding ¡

– Many ¡aSributes ¡

• AS_PATH: ¡loop ¡free ¡
• BGP: ¡a ¡bit ¡of ¡theory ¡

– BGP ¡is ¡not ¡safe: ¡convergence ¡is ¡not ¡guaranteed ¡aWer ¡a ¡failure ¡

• BGP ¡Scalability ¡

– RIB ¡size ¡-­‑> ¡TE ¡pracBces, ¡deaggregaBon ¡ – Churn: ¡mostly ¡“quiet”, ¡if ¡we ¡do ¡not ¡count ¡duplicates ¡(why ¡duplicates, ¡anyway?) ¡

• (Inter ¡+ ¡Intra)domain ¡RouBng ¡

4/5/11 ¡ 2 ¡ seMINArios ¡2011 ¡

1/5/11 2

Outline ¡

• (Inter ¡+ ¡Intra)domain ¡RouBng ¡
• Route ¡Reflectors ¡

– MulBple, ¡hierarchical ¡RRs ¡ – Known ¡issues ¡

• iBGP ¡Route ¡Reflectors ¡topologies ¡

– PracBcal ¡design ¡guidelines ¡ – Correct ¡and ¡scalable ¡proposals ¡ – Others ¡

• IETF ¡
• Centralized ¡soluBons ¡
• An ¡experiment ¡on ¡iBGP ¡scaling ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 3 ¡

(Inter ¡+ ¡Intra)domain ¡RouBng ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 4 ¡

1/5/11 3

BGP-­‑IGP ¡InteracBon ¡

• ASes ¡exchange ¡reachability ¡informaBon ¡using ¡(external) ¡BGP ¡
• Intradomain ¡rouBng: ¡IGP ¡
• PropagaBon ¡of ¡BGP ¡informaBon ¡intradomain: ¡(internal) ¡BGP ¡

IGP iBGP IGP iBGP IGP iBGP IGP iBGP eBGP eBGP eBGP

4/5/11 ¡ 5 ¡ seMINArios ¡2011 ¡

Remember: ¡NEXT_HOP ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 6 ¡

Forwarding Table Forwarding Table

AS 1 AS 2

192.0.2.1 135.207.0.0/16 10.10.10.1

EGP 192.0.2.1 135.207.0.0/16 destination next hop 10.10.10.10 192.0.2.0/30 destination next hop

135.207.0.0/16 Next Hop = 192.0.2.1

192.0.2.0/3

135.207.0.0/16 destination next hop 10.10.10.10

+

192.0.2.0/30 10.10.10.10

1/5/11 4

BGP-­‑IGP ¡interacBon ¡alternaBves ¡

• PropagaBon ¡of ¡BGP ¡InformaBon ¡via ¡the ¡IGP, ¡mulBcast ¡or ¡other ¡

efficient ¡flooding ¡mechanism ¡

– MenBoned ¡in ¡rfcs ¡1772 ¡& ¡1773, ¡implementaBon? ¡

• BGP ¡Scalable ¡Transport ¡
• RedistribuBon/tagged ¡IGP ¡

– Specified ¡in ¡rfcs ¡1403 ¡& ¡1745 ¡(moved ¡to ¡historical ¡status) ¡ – Route ¡tagging ¡implemented ¡in ¡cisco ¡& ¡juniper ¡routers ¡

• EncapsulaBon ¡

– MPLS ¡tunnels ¡among ¡eBGP ¡speakers ¡

• Pervasive ¡BGP ¡

4/5/11 ¡ 7 ¡ seMINArios ¡2011 ¡

Pervasive ¡Internal ¡BGP ¡(iBGP) ¡

• All ¡routers ¡in ¡an ¡AS ¡are ¡iBGP ¡speakers ¡
• IGP ¡is ¡only ¡used ¡for ¡rouBng ¡within ¡the ¡AS ¡

– No ¡BGP ¡routes ¡are ¡imported ¡into ¡the ¡IGP ¡

• RouBng ¡table ¡recursive ¡lookup ¡

– First ¡lookup ¡determine ¡BGP ¡next ¡hop ¡ ¡(exit ¡router) ¡ – Second ¡lookup ¡determine ¡the ¡IGP ¡path ¡to ¡the ¡exit ¡router ¡

• Need ¡to ¡make ¡sure ¡that ¡

– Internal ¡transport ¡of ¡BGP ¡info ¡is ¡loop-­‑free ¡(just ¡BGP ¡info!) ¡ – Internal ¡rouBng ¡is ¡coherent ¡(now, ¡loop-­‑freeness ¡for ¡data ¡plane ¡ forwarding) ¡

4/5/11 ¡ 8 ¡ seMINArios ¡2011 ¡

1/5/11 5

Internal ¡BGP ¡

• iBGP ¡and ¡eBGP ¡are ¡same ¡protocol ¡in ¡that ¡

– same ¡message ¡types ¡used ¡ – same ¡aSributes ¡used ¡ – same ¡state ¡machine ¡ – BUT ¡use ¡different ¡rules ¡for ¡readverBsing ¡prefixes ¡

• Rules ¡for ¡iBGP ¡

– #1: ¡prefixes ¡learned ¡from ¡an ¡eBGP ¡neighbor ¡can ¡be ¡ readverBsed ¡to ¡an ¡iBGP ¡neighbor, ¡and ¡vice ¡versa ¡ – #2: ¡prefixes ¡learned ¡from ¡an ¡iBGP ¡neighbor ¡cannot ¡be ¡ readverBsed ¡to ¡another ¡iBGP ¡neighbor ¡ ¡

4/5/11 ¡ 9 ¡ seMINArios ¡2011 ¡

Loop-­‑freeness ¡of ¡BGP ¡info ¡in ¡iBGP ¡

• Why ¡rule ¡#2? ¡To ¡prevent ¡BGP ¡announcements ¡from ¡looping ¡ ¡

– eBGP ¡detect ¡loops ¡via ¡AS-­‑PATH ¡ – AS-­‑PATH ¡not ¡changed ¡in ¡iBGP ¡

• ImplicaBon ¡of ¡rule: ¡a ¡full ¡mesh ¡of ¡iBGP ¡sessions ¡between ¡

each ¡pair ¡of ¡routers ¡in ¡an ¡AS ¡is ¡required ¡

• Example ¡of ¡rule ¡#1: ¡

AS 4

163.1.0.0/16 AS 336 95

4/5/11 ¡ 10 ¡ seMINArios ¡2011 ¡

1/5/11 6

iBGP ¡full-­‑mesh ¡scalability ¡ ¡

• n*(n ¡-­‑ ¡1)/2 ¡iBGP ¡sessions ¡
• ConfiguraBon ¡management ¡

– Each ¡router ¡must ¡have ¡n-­‑1 ¡iBGP ¡sessions ¡configured ¡ – The ¡addiBon ¡a ¡single ¡iBGP ¡speaker ¡requires ¡ configuraBon ¡changes ¡to ¡all ¡other ¡iBGP ¡speakers ¡ – E.g. ¡if ¡we ¡have ¡200 ¡routers ¡in ¡our ¡network ¡that ¡would ¡ give ¡us ¡19900 ¡BGP ¡sessions! ¡

4/5/11 ¡ 11 ¡ seMINArios ¡2011 ¡

iBGP ¡full-­‑mesh ¡scalability ¡

• RouBng ¡state ¡

– Many ¡Adj-­‑RIBs ¡: ¡most ¡routes ¡are ¡not ¡ used ¡ – Size ¡of ¡iBGP ¡rouBng ¡table ¡can ¡be ¡order ¡ n ¡larger ¡than ¡number ¡of ¡best ¡routes ¡ (remember ¡alternate ¡routes!) ¡ – Each ¡router ¡has ¡to ¡listen ¡to ¡update ¡ noise ¡from ¡each ¡neighbor ¡ – CPU ¡and ¡memory ¡resources ¡-­‑> ¡large ¡ routers ¡needed! ¡

• SoluBons ¡

– Route ¡Reflectors ¡ – ConfederaBons ¡

eBGP update iBGP updates

4/5/11 ¡ 12 ¡ seMINArios ¡2011 ¡

1/5/11 7

Route ¡Reflectors ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 13 ¡

Route ¡Reflectors ¡

• Avoiding ¡the ¡virtual ¡full ¡mesh ¡of ¡iBGP ¡

sessions: ¡

• group ¡routers ¡into ¡clusters ¡
• Assign ¡a ¡leader ¡to ¡each ¡cluster, ¡called ¡a ¡

route ¡reflector ¡(RR) ¡

• Members ¡of ¡a ¡cluster ¡are ¡called ¡clients ¡of ¡

the ¡RR ¡

• The ¡clients ¡do ¡not ¡know ¡they ¡are ¡clients ¡

and ¡are ¡configured ¡as ¡normal ¡iBGP ¡peers ¡

• Only ¡the ¡best ¡route ¡to ¡a ¡desBnaBon ¡is ¡

sent ¡from ¡a ¡RR ¡to ¡a ¡client ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 14 ¡

clients RR A B C clusters RR RR

1/5/11 8

Route ¡Reflectors: ¡announcements ¡

• If ¡received ¡from ¡RR, ¡reflect ¡to ¡clients ¡
• If ¡received ¡from ¡a ¡client, ¡reflect ¡to ¡RRs ¡and ¡clients ¡
• If ¡received ¡from ¡eBGP, ¡reflect ¡to ¡all: ¡RRs ¡and ¡clients ¡
• RRs ¡reflect ¡only ¡the ¡best ¡route ¡to ¡a ¡given ¡prefix, ¡not ¡all ¡

announcements ¡they ¡receive ¡ ¡

– helps ¡size ¡of ¡rouBng ¡table ¡ – someBmes ¡clients ¡don’t ¡need ¡to ¡carry ¡full ¡table ¡

• RR ¡should ¡not ¡change ¡the ¡aSributes ¡

– NEXT_HOP ¡ – AS_PATH ¡ – LOCAL_PREF ¡ – MED ¡

4/5/11 ¡ 15 ¡ seMINArios ¡2011 ¡

Avoiding ¡Loops ¡with ¡Route ¡Reflectors ¡

• Loops ¡cannot ¡be ¡detected ¡by ¡tradiBonal ¡approach ¡using ¡AS_PATH ¡

because ¡AS_PATH ¡not ¡modified ¡within ¡an ¡AS ¡

• Announcements ¡could ¡leave ¡a ¡cluster ¡and ¡re-­‑enter ¡it ¡
• Two ¡new ¡aSributes ¡added ¡by ¡RR ¡if ¡a ¡route ¡is ¡reflected ¡

– ORIGINATOR_ID: ¡Router ¡ID ¡of ¡route’s ¡originator ¡in ¡AS ¡ rule: ¡announcement ¡discarded ¡if ¡returns ¡to ¡originator ¡ – CLUSTER_LIST: ¡a ¡sequence ¡of ¡Cluster ¡Ids, ¡set ¡by ¡RRs ¡ rule: ¡if ¡an ¡RR ¡receives ¡an ¡update ¡and ¡the ¡cluster ¡list ¡contains ¡its ¡Cluster ¡ID, ¡ then ¡update ¡is ¡discarded ¡

• Both ¡are ¡opBonal, ¡nontransiBve ¡(dont ¡propagate ¡to ¡eBGP) ¡

4/5/11 ¡ 16 ¡ seMINArios ¡2011 ¡

1/5/11 9

MulBple ¡route ¡reflectors ¡

• For ¡redundancy, ¡is ¡possible ¡to ¡

have ¡more ¡than ¡one ¡route ¡ reflector ¡in ¡a ¡cluster ¡

– Otherwise, ¡the ¡RR ¡is ¡a ¡'single-­‑point-­‑

• f-­‑failure' ¡
• RRs ¡in ¡a ¡cluster ¡may ¡have ¡the ¡

same ¡cluster ¡ID ¡

– …or ¡different ¡cluster ¡IDs ¡ – Let’s ¡discuss ¡alterna6ves ¡over ¡this ¡ sample ¡topology ¡ ¡

Source: Practical BGP

4/5/11 ¡ 17 ¡ seMINArios ¡2011 ¡

MulBple ¡route ¡reflectors ¡

• Different ¡Cluster ¡IDs: ¡

– C ¡receives ¡some ¡route ¡p ¡from ¡F. ¡It ¡adverBses ¡p ¡to ¡A ¡and ¡B ¡ – A ¡creates ¡a ¡new ¡Cluster ¡List ¡aSribute ¡and ¡inserts ¡its ¡router ¡ ID, ¡and ¡sets ¡the ¡originator ¡ID ¡to ¡C. ¡A ¡adverBses ¡p ¡to ¡B, ¡D, ¡ and ¡E ¡ – B ¡receives ¡this ¡update, ¡and ¡discovers ¡that ¡its ¡cluster ¡ID ¡ ¡is ¡ not ¡in ¡the ¡Cluster ¡List. ¡It ¡accepts ¡the ¡adverBsement ¡and ¡ prepends ¡its ¡cluster ¡ID ¡to ¡the ¡Cluster ¡List ¡ – B ¡also ¡receives ¡the ¡update ¡from ¡C, ¡creates ¡a ¡new ¡Cluster ¡ List ¡aSribute, ¡and ¡inserts ¡its ¡cluster ¡ID. ¡Also ¡sets ¡the ¡

• riginator ¡ID ¡to ¡C. ¡B ¡then ¡runs ¡the ¡best ¡path ¡algorithm ¡and ¡

selects ¡the ¡direct ¡path ¡via ¡C ¡and ¡adverBses ¡this ¡update ¡to ¡ D, ¡E ¡and ¡A ¡ – Since ¡A ¡and ¡B ¡are ¡using ¡different ¡Cluster ¡IDs, ¡D ¡and ¡E ¡each ¡ receive ¡two ¡copies ¡of ¡the ¡update ¡

Source: Practical BGP

4/5/11 ¡ 18 ¡ seMINArios ¡2011 ¡

1/5/11 10

MulBple ¡route ¡reflectors ¡

• Same ¡cluster ¡IDs: ¡

– C ¡receives ¡some ¡route ¡p ¡from ¡F. ¡It ¡adverBses ¡p ¡to ¡A ¡and ¡B ¡ – A ¡creates ¡a ¡new ¡Cluster ¡List ¡aSribute, ¡inserts ¡its ¡cluster ¡ID ¡ (the ¡same ¡as ¡B), ¡and ¡sets ¡the ¡originator ¡ID ¡to ¡C. ¡Router ¡A ¡ then ¡adverBses ¡p ¡to ¡B, ¡D, ¡and ¡E. ¡ – B ¡receives ¡this ¡update ¡and ¡discards ¡it, ¡because ¡its ¡locally ¡ defined ¡cluster ¡ID ¡is ¡already ¡in ¡the ¡Cluster ¡List ¡ – B ¡also ¡receives ¡the ¡update ¡from ¡C, ¡adds ¡a ¡Cluster ¡List ¡ aSribute, ¡inserts ¡its ¡cluster ¡ID, ¡and ¡sets ¡the ¡originator ¡ID ¡to ¡

• C. ¡B ¡adverBses ¡this ¡update ¡to ¡D, ¡E ¡and ¡A ¡

– When ¡A ¡receives ¡the ¡update ¡from ¡B, ¡it ¡discards ¡it ¡because ¡ the ¡cluster ¡list ¡contains ¡the ¡locally ¡configured ¡cluster ¡ID ¡ – Now ¡routers ¡A ¡and ¡B ¡are ¡only ¡required ¡to ¡store ¡one ¡copy ¡of ¡ the ¡route ¡

Source: Practical BGP

4/5/11 ¡ 19 ¡ seMINArios ¡2011 ¡

MulBple ¡route ¡reflectors ¡

• A ¡and ¡D ¡receive ¡an ¡

adverBsement ¡for ¡10.1.1.0/24 ¡ from ¡an ¡external ¡BGP ¡peer ¡

• B ¡will ¡prefer ¡D ¡and ¡C ¡will ¡prefer ¡

A ¡=> ¡rouBng ¡loop! ¡

:-( :-)

Source: Practical BGP

Route reflectors: follow the physical topology

4/5/11 ¡ 20 ¡ seMINArios ¡2011 ¡

1/5/11 11

Route ¡reflectors: ¡subopBmal ¡route ¡ selecBon ¡

• First ¡design: ¡full ¡mesh ¡iBGP ¡

– Next ¡hop ¡selecBon ¡follow ¡IGP ¡

• Using ¡A ¡as ¡RR ¡

– Supose ¡A ¡chooses ¡C ¡ – What ¡happens? ¡

Source: Practical BGP

Obs: ignore LOCAL_PREF and MED

4/5/11 ¡ 21 ¡ seMINArios ¡2011 ¡

Hierarchical ¡Route ¡Reflectors ¡

• Example ¡with ¡three ¡route ¡

reflecBon ¡clusters ¡

– Root ¡cluster: ¡A ¡and ¡B ¡are ¡route ¡ reflectors, ¡while ¡D, ¡C, ¡E, ¡and ¡F ¡ are ¡clients. ¡ ¡ – Two ¡lower-­‑level ¡clusters: ¡C ¡and ¡ D, ¡E ¡and ¡F ¡are ¡route ¡reflectors, ¡

• respecBvely. ¡
• Remember: ¡RR ¡topology ¡

should ¡follow ¡the ¡physical ¡ topology ¡of ¡the ¡ interconnected ¡iBGP ¡

• speakers. ¡ ¡

– Avoiding ¡forwarding ¡loops ¡

Source: Practical BGP

4/5/11 ¡ 22 ¡ seMINArios ¡2011 ¡

1/5/11 12

MED ¡oscillaBon ¡

• RFC ¡3345 ¡

– Bad ¡news: ¡

• “In ¡certain ¡topologies ¡involving ¡either ¡route ¡reflectors ¡or ¡confederaBons, ¡the ¡

parBal ¡visibility ¡of ¡the ¡available ¡exit ¡points ¡into ¡a ¡neighboring ¡AS ¡may ¡result ¡in ¡ an ¡inconsistent ¡best ¡path ¡selecBon ¡decision ¡as ¡the ¡routers ¡don't ¡have ¡all ¡the ¡ relevant ¡informaBon. ¡ ¡If ¡the ¡inconsistencies ¡span ¡more ¡than ¡one ¡peering ¡ router, ¡they ¡may ¡result ¡in ¡a ¡persistent ¡route ¡oscillaBon” ¡

– (RelaBve) ¡good ¡news ¡

• “The ¡persistent ¡route ¡oscillaBon ¡behavior ¡is ¡determinisBc ¡and ¡can ¡be ¡avoided ¡

by ¡employing ¡some ¡rudimentary ¡BGP ¡network ¡design ¡principles ¡unBl ¡protocol ¡ enhancements ¡resolve ¡the ¡problem” ¡

4/5/11 ¡ 23 ¡ seMINArios ¡2011 ¡

MED ¡oscillaBon ¡

• RR/confederaBon ¡hides ¡some ¡informaBon ¡

– RR/confederaBon ¡sends ¡best ¡path ¡only ¡ – not ¡all ¡routers ¡know ¡all ¡best ¡paths ¡

• ¡MED ¡(MulB ¡Exit ¡Discriminator) ¡vs ¡IGP ¡cost ¡to ¡the ¡

neighbor… ¡

• Seen ¡on ¡a ¡RR/confederaBon ¡border: ¡

#show ip bgp 10.0.0.0 | include best # Paths: (3 available, best #3) #show ip bgp 10.0.0.0 | include best # Paths: (3 available, best #2) #show ip bgp 10.0.0.0 | include best # Paths: (3 available, best #3)

...

4/5/11 ¡ 24 ¡ seMINArios ¡2011 ¡

1/5/11 13

MED ¡oscillaBon ¡

A D E

AS Y MED 0 AS X AS Y MED 1

B C

Cluster 1 Cluster 2

2 3 10 1 = Withdrawal

= Advertisement

Step 1 – B selects Y0 – C selects Y1

= Route Reflector = Client

B C X 3 Y 1 2 * * Y

AS_PATH MED IGP

10

4/5/11 ¡ 25 ¡ seMINArios ¡2011 ¡

MED ¡oscillaBon ¡

A D E

AS Y MED 0 AS X AS Y MED 1

B C

Cluster 1 Cluster 2

2 3 10 1 = Withdrawal

= Advertisement

Step 2 – C selects X

= Route Reflector = Client

B C * X 3 Y 1 2 * Y

AS_PATH MED IGP

Y 10 11 Y 1 3

4/5/11 ¡ 26 ¡ seMINArios ¡2011 ¡

1/5/11 14

MED ¡oscillaBon ¡

A D E

AS Y MED 0 AS X AS Y MED 1

B C

Cluster 1 Cluster 2

2 3 10 1 = Withdrawal

= Advertisement

Step 3 – B selects X

= Route Reflector = Client

B C * X 3 Y 1 2 Y

AS_PATH MED IGP

Y 10 11 * X 4

4/5/11 ¡ 27 ¡ seMINArios ¡2011 ¡

MED ¡oscillaBon ¡

A D E

AS Y MED 0 AS X AS Y MED 1

B C

Cluster 1 Cluster 2

2 3 10 1 = Withdrawal

= Advertisement

Step 4 – C selects Y1

= Route Reflector = Client

B C X 3 * Y 1 2 Y

AS_PATH MED IGP

10 * X 4

4/5/11 ¡ 28 ¡ seMINArios ¡2011 ¡

1/5/11 15

MED ¡oscillaBon ¡

A D E

AS Y MED 0 AS X AS Y MED 1

B C

Cluster 1 Cluster 2

2 3 10 1 = Withdrawal

= Advertisement

Step 5 – B selects Y0 = Step 1!!

= Route Reflector = Client

B C X 3 * Y 1 2 * Y

AS_PATH MED IGP

10

4/5/11 ¡ 29 ¡ seMINArios ¡2011 ¡

MED ¡oscillaBon: ¡workarounds ¡

• Use ¡full ¡mesh ¡iBGP ¡

– Scalability… ¡

• Do ¡not ¡listen ¡to ¡the ¡MED ¡(or ¡only ¡with ¡stub-­‑AS) ¡

– set metric 0 ¡on ¡all ¡prefixes ¡

• bgp always-compare-med

– Inconsistent! ¡-­‑> ¡remember ¡MEDs ¡is ¡per-­‑AS ¡aSribute ¡

• Use ¡local-­‑pref ¡to ¡force ¡decision ¡

– exit ¡no ¡longer ¡chosen ¡by ¡peer ¡= ¡more ¡work ¡:( ¡

• Allow ¡peer ¡to ¡set ¡local-­‑pref ¡using ¡community ¡
• Protocol ¡improvement? ¡

4/5/11 ¡ 30 ¡ seMINArios ¡2011 ¡

1/5/11 16

iBGP ¡Scalability: ¡summary ¡

• iBGP ¡is ¡necessary ¡for ¡core ¡routers ¡in ¡a ¡transit ¡

network ¡

• BGP ¡loop ¡detecBon ¡mechanism ¡is ¡based ¡on ¡

AS_PATH-­‑> ¡IBGP ¡peering ¡must ¡be ¡fully ¡meshed ¡

• This ¡leads ¡to ¡scaling ¡problems ¡
• SoluBons: ¡

– Route ¡reflectors ¡ – AS ¡confederaBons ¡

4/5/11 ¡ 31 ¡ seMINArios ¡2011 ¡

iBGP ¡Scalability: ¡summary ¡

• Known ¡issues ¡

– RouBng ¡loops ¡ – Divergence ¡and/or ¡non-­‑determinisBc ¡update ¡process ¡

• MED ¡oscilaBon ¡

– SubopBmal ¡intra-­‑domain ¡rouBng ¡ – Route ¡deflecBon ¡

• Re-­‑route ¡at ¡exit ¡point! ¡

4/5/11 ¡ 32 ¡ seMINArios ¡2011 ¡

1/5/11 17

References ¡

1. Prac6cal ¡BGP, ¡by ¡Russ ¡White, ¡Danny ¡McPherson, ¡Sangli ¡Srihari ¡ 2. IBGP ¡scaling: ¡Route ¡reflectors ¡and ¡confedera6ons, ¡Olof ¡Hagsand, ¡Lecture ¡at ¡ KTH ¡/CSC ¡ 3. BGP ¡Oscilla6on, ¡Fabien ¡Berger, ¡PresentaBon ¡at ¡Swiss ¡Network ¡Operators ¡Group ¡

• ­‑ ¡SwiNOG ¡3, ¡19 ¡September ¡2001 ¡ ¡

4. RFC ¡1772, ¡“ApplicaBon ¡of ¡the ¡Border ¡Gateway ¡Protocol ¡in ¡the ¡Internet”, ¡March ¡

• 1995. ¡

5.

• T. ¡Bates, ¡E. ¡Chen, ¡R. ¡Chandra, ¡BGP ¡Route ¡Reflec6on: ¡An ¡Alterna6ve ¡to ¡Full ¡Mesh ¡

Internal ¡BGP ¡(IBGP). ¡IETF ¡RFC ¡4456 ¡(Obsoletes: ¡2796, ¡1966), ¡April ¡2006. ¡ 6.

• P. ¡Traina, ¡D. ¡McPherson, ¡J. ¡Scudder, ¡Autonomous ¡System ¡Confedera6ons ¡for ¡
• BGP. ¡IETF ¡RRFC ¡5065 ¡(Obsoletes: ¡3065), ¡August ¡2007. ¡

7.

• D. ¡McPherson, ¡V. ¡Gill, ¡D. ¡Walton, ¡A. ¡Retana, ¡Border ¡Gateway ¡Protocol ¡(BGP) ¡

Persistent ¡Route ¡Oscilla6on ¡Condi6on. ¡IETF ¡RFC ¡3345, ¡August ¡2002. ¡

4/5/11 ¡ 33 ¡ seMINArios ¡2011 ¡

iBGP ¡Route ¡Reflectors ¡topologies ¡

4/5/11 ¡ 34 ¡ seMINArios ¡2011 ¡

1/5/11 18

PracBcal ¡design ¡guidelines ¡

• Bates ¡[RFC ¡4456] ¡
• Zhang ¡[BGPDesign] ¡

4/5/11 ¡ 35 ¡ seMINArios ¡2011 ¡

Bates ¡

• “Bates1” ¡

– The ¡most ¡connected ¡router ¡in ¡each ¡PoP ¡is ¡selected ¡to ¡be ¡the ¡RR ¡ – Each ¡router ¡is ¡a ¡client ¡of ¡the ¡RR ¡in ¡its ¡PoP ¡ – A ¡full-­‑mesh ¡of ¡iBGP ¡sessions ¡is ¡established ¡between ¡the ¡RRs ¡ – Finally, ¡there ¡is ¡a ¡full-­‑mesh ¡of ¡iBGP ¡sessions ¡between ¡all ¡the ¡routers ¡in ¡a ¡PoP ¡

• “Bates2” ¡

– The ¡two ¡ ¡most ¡connected ¡routers ¡in ¡the ¡PoP ¡are ¡selected ¡as ¡RRs ¡ ¡for ¡redundancy ¡ purposes ¡ – All ¡the ¡routers ¡in ¡a ¡PoP ¡are ¡iBGP ¡clients ¡of ¡the ¡two ¡RRs ¡in ¡the ¡PoP ¡ – Moreover, ¡a ¡full-­‑mesh ¡of ¡iBGP ¡sessions ¡is ¡configured ¡between ¡the ¡RRs ¡

• Both ¡designs ¡follow ¡the ¡recomendaBon ¡in ¡RFC ¡4456 ¡[PelsserCN2010] ¡

4/5/11 ¡ 36 ¡ seMINArios ¡2011 ¡

1/5/11 19

Zhang ¡

• “Zhang” ¡iBGP ¡design ¡

– Define ¡guidelines ¡for ¡hierarchical ¡route-­‑reflecBon ¡in ¡large ¡Service ¡Provider ¡ networks ¡

• RecommendaBons ¡

– RRs ¡at ¡the ¡top-­‑level ¡must ¡be ¡fully ¡meshed ¡ – Mesh ¡is ¡not ¡required ¡for ¡RRs ¡at ¡lower ¡levels ¡ – Typically ¡there ¡are ¡two ¡levels ¡of ¡RRs ¡(maybe ¡more) ¡ – At ¡the ¡lowest ¡level, ¡the ¡routers ¡of ¡a ¡PoP ¡are ¡clients ¡of ¡the ¡most ¡connected ¡ routers ¡of ¡the ¡PoP ¡(as ¡in ¡“Bates2”) ¡ – In ¡turn, ¡these ¡RRs ¡are ¡clients ¡of ¡two ¡RRs ¡at ¡the ¡top-­‑level ¡ – Finally, ¡a ¡full-­‑mesh ¡of ¡iBGP ¡sessions ¡is ¡configured ¡between ¡the ¡top-­‑level ¡RRs ¡

4/5/11 ¡ 37 ¡ seMINArios ¡2011 ¡

Bates ¡& ¡Zhang ¡characterisBcs ¡

• Guidelines ¡

– Follow ¡physical ¡topology ¡ – Session ¡between ¡an ¡RR ¡and ¡a ¡nonclient ¡ should ¡not ¡traverse ¡a ¡client ¡ – Session ¡between ¡an ¡RR ¡and ¡its ¡client ¡ should ¡not ¡traverse ¡a ¡nonclient ¡

Source: BGP Design and Implementation

4/5/11 ¡ 38 ¡ seMINArios ¡2011 ¡

1/5/11 20

iBGP ¡Correctness ¡[GW02]

¡

• Path ¡symmetry: ¡in ¡eBGP ¡signalling ¡and ¡forwarding ¡traffic ¡flow ¡along ¡the ¡same ¡

path ¡(usually ¡peering ¡over ¡directly ¡connected ¡link) ¡

• iBGP ¡is ¡routed, ¡therefore ¡path ¡symmetry ¡is ¡not ¡guaranteed ¡
• iBGP ¡configuraBon ¡correctness: ¡stable, ¡anomaly ¡free ¡rouBng ¡(in ¡parBcular, ¡loop-­‑

free) ¡

• Checking ¡the ¡correctness ¡of ¡an ¡iBGP ¡graph ¡is ¡NP-­‑complete ¡
• Two ¡condiBons ¡ensure ¡a ¡correct ¡(loop-­‑free) ¡iBGP ¡graph: ¡ ¡

– 1) ¡route-­‑reflectors ¡should ¡prefer ¡client ¡routes ¡to ¡non-­‑client ¡routes ¡ – 2) ¡every ¡shortest ¡path ¡should ¡be ¡a ¡valid ¡signaling ¡path ¡

4/5/11 ¡ 39 ¡ seMINArios ¡2011 ¡

Correct ¡and ¡scalable ¡proposals ¡

• BGPSep ¡[Vutukuru2006how] ¡
• OpBmal ¡iBGP ¡topologies ¡[BuobUM2008] ¡

– fm-­‑opBmality ¡

• Skeleton ¡[SarakbiM2010] ¡

4/5/11 ¡ 40 ¡ seMINArios ¡2011 ¡

1/5/11 21

References ¡

1. [RFC ¡4456] ¡T. ¡Bates, ¡E. ¡Chen, ¡R. ¡Chandra, ¡BGP ¡route ¡reflec6on ¡-­‑ ¡an ¡alterna6ve ¡to ¡ full ¡mesh ¡internal ¡BGP ¡(IBGP), ¡RFC ¡4456 ¡(April ¡2006). ¡ 2. [PelsserCN2010] ¡C. ¡Pelsser, ¡B. ¡QuoiBn, ¡S. ¡Uhlig, ¡T. ¡Takeda, ¡and ¡K. ¡Shiomoto. ¡ Providing ¡scalable ¡NH-­‑diverse ¡iBGP ¡route ¡redistribu6on ¡to ¡achieve ¡sub-­‑second ¡ switch-­‑over ¡6me. ¡To ¡appear ¡in ¡Computer ¡Networks ¡journal, ¡2010. ¡ 3. [BGPDesign] ¡R. ¡Zhang, ¡M. ¡Bartell, ¡BGP ¡Design ¡and ¡Implementa6on, ¡1st ¡EdiBon, ¡ Cisco ¡Press, ¡2003. ¡

4/5/11 ¡ 41 ¡ seMINArios ¡2011 ¡

References ¡

4. [GW02] ¡Griffin, ¡T.G.,Wilfong, ¡G.: ¡On ¡the ¡correctness ¡of ¡iBGP ¡configura6on. ¡In: ¡

• Proc. ¡of ¡ACM ¡SIGCOMM ¡(August ¡2002). ¡

5. [Vutukuru2006how] ¡How ¡to ¡Construct ¡a ¡Correct ¡and ¡Scalable ¡iBGP ¡ Configura6on, ¡Mythili ¡Vutukuru, ¡Paul ¡Valiant, ¡SwasBk ¡Kopparty, ¡and ¡Hari ¡

• Balakrishnan. ¡IEEE ¡INFOCOM ¡2006. ¡

6. [SarakbiM2010] ¡BGP ¡Skeleton ¡-­‑An ¡Alterna6ve ¡to ¡iBGP ¡Route ¡Reflec6on, ¡Bakr ¡ SARAKBI, ¡Stephane ¡MAAG. ¡IEEE ¡INFOCOM ¡2010. ¡ 7. [BuobUM2008] ¡M.-­‑O. ¡Buob, ¡S. ¡Uhlig, ¡M. ¡Meulle, ¡Designing ¡op6mal ¡iBGP ¡Route-­‑ Reflec6on ¡topologies. ¡IFIP ¡Networking ¡2008. ¡

4/5/11 ¡ 42 ¡ seMINArios ¡2011 ¡

1/5/11 22

Recent ¡IETF ¡proposals ¡

• Best-­‑external ¡[BE-­‑02] ¡
• Add-­‑Path ¡[AP-­‑04] ¡
• N-­‑plane ¡Route ¡Reflectors ¡[NRR-­‑02] ¡

4/5/11 ¡ 43 ¡ seMINArios ¡2011 ¡

Centralized ¡soluBons ¡

• Morpheus ¡[MJSAC09] ¡ ¡
• Others: ¡

– Route ¡Control ¡Pla~rom ¡[RCP] ¡ ¡ – iBGP ¡Route ¡Server ¡Architecture ¡[iBGPRS09] ¡

4/5/11 ¡ 44 ¡ seMINArios ¡2011 ¡

1/5/11 23

Design ¡for ¡Configurability: ¡Rethinking ¡ Interdomain ¡RouBng ¡Policies ¡from ¡the ¡ Ground ¡Up ¡

• IEEE ¡Journal ¡on ¡Selected ¡Areas ¡in ¡CommunicaBons, ¡

April ¡2009 ¡

– Yi ¡Wang, ¡Ioannis ¡Avramopoulos, ¡and ¡Jennifer ¡Rexford ¡

4/5/11 ¡ 45 ¡ seMINArios ¡2011 ¡

• Large ¡ISPs ¡usually ¡have ¡mulBple ¡paths ¡to ¡reach ¡the ¡

same ¡desBnaBon ¡

• Different ¡paths ¡have ¡different ¡properBes ¡
• Different ¡neighbors ¡may ¡prefer ¡different ¡routes ¡

Bank ¡ VoIP ¡ provider ¡ School ¡ Most ¡secure ¡ Shortest ¡latency ¡ Lowest ¡cost ¡

A ¡Case ¡For ¡Customized ¡Route ¡SelecBon ¡

4/5/11 ¡ 46 ¡ seMINArios ¡2011 ¡

1/5/11 24

Exploit ¡Path ¡Diversity ¡

• Large ¡ISPs ¡Have ¡Rich ¡Path ¡Diversity ¡

– Top ¡2% ¡ASes ¡have ¡10 ¡or ¡more ¡AS ¡paths ¡for ¡certain ¡desBnaBons ¡

• Paths ¡May ¡Differ ¡Significantly ¡

– Security ¡

• Prefix ¡/ ¡sub-­‑prefix ¡hijacking ¡is ¡a ¡real ¡threat ¡
• Avoiding ¡an ¡undesirable ¡AS ¡along ¡the ¡path ¡
• Large ¡ASes ¡are ¡likely ¡to ¡have ¡at ¡least ¡one ¡valid/desirable ¡route ¡for ¡most ¡

prefixes ¡

– Performance ¡

• AlternaBve ¡BGP ¡paths ¡oWen ¡have ¡beSer ¡performance ¡than ¡the ¡default ¡path ¡
• Path ¡diversity ¡gives ¡large ¡ISPs ¡plenty ¡of ¡choices ¡

4/5/11 ¡ 47 ¡ seMINArios ¡2011 ¡

• Flexibility ¡Is ¡Infeasible ¡Today ¡

– BGP: ¡The ¡rouBng ¡protocol ¡(“glue”) ¡of ¡the ¡Internet ¡

• An ¡ISP ¡configures ¡BGP ¡to ¡realize ¡its ¡rouBng ¡policies ¡

– BGP ¡uses ¡a ¡restricBve, ¡“one-­‑route-­‑fits-­‑all” ¡model ¡

• Every ¡router ¡selects ¡one ¡best ¡route ¡(per ¡desBnaBon) ¡for ¡all ¡neighbors ¡ ¡

Exploit ¡Path ¡Diversity ¡

4/5/11 ¡ 48 ¡ seMINArios ¡2011 ¡

1/5/11 25

Morpheus: ¡Enable ¡Flexible ¡Path ¡ SelecBon ¡

• A ¡rou6ng ¡control ¡plaTorm ¡

that ¡enables ¡a ¡single ¡ISP ¡ to ¡flexibly ¡pick ¡paths ¡for ¡ customers ¡

• Two ¡components ¡

– Support ¡from ¡intra-­‑AS ¡ rouBng ¡architecture ¡ – Morpheus ¡servers ¡with ¡ flexible ¡path ¡selecBon ¡ processes ¡

4/5/11 ¡ 49 ¡ seMINArios ¡2011 ¡

• Support ¡for ¡mulBple ¡paths ¡already ¡available ¡

– “Virtual ¡rouBng ¡and ¡forwarding ¡(VRF)” ¡(Cisco) ¡ ¡ – “Virtual ¡router” ¡(Juniper) ¡ D: ¡(red ¡path): ¡R6 ¡ D: ¡(blue ¡path): ¡R7 ¡ R3’s ¡forwarding ¡table ¡(FIB) ¡entries ¡

Flexible ¡Route ¡Assignment ¡

4/5/11 ¡ 50 ¡ seMINArios ¡2011 ¡

1/5/11 26

Inside ¡Morpheus ¡Server: ¡Policy ¡ ObjecBves ¡As ¡Independent ¡Modules ¡

• Each ¡module ¡tags ¡routes ¡in ¡separate ¡spaces ¡
• Easy ¡to ¡add ¡side ¡informaBon ¡
• Different ¡modules ¡can ¡be ¡implemented ¡independently ¡(e.g., ¡by ¡

third-­‑parBes) ¡– ¡evolvability ¡

4/5/11 ¡ 51 ¡ seMINArios ¡2011 ¡

Policies ¡

• Current ¡BGP ¡ImplementaBons ¡strictly ¡rank ¡one ¡aSribute ¡over ¡

another ¡(not ¡possible ¡to ¡make ¡trade-­‑offs ¡between ¡policy ¡objecBves) ¡

• E.g., ¡a ¡policy ¡with ¡trade-­‑off ¡between ¡business ¡relaBonships ¡and ¡

stability ¡

• Infeasible ¡today ¡

“If all paths are somewhat unstable, pick the most stable path (of any length) Otherwise, pick the shortest path through a customer”

4/5/11 ¡ 52 ¡ seMINArios ¡2011 ¡

1/5/11 27

• Every ¡route ¡r ¡gets ¡a ¡value ¡ai(r) ¡of ¡each ¡criterion ¡(policy ¡objecBve) ¡ci ¡(assigned ¡

by ¡classifiers) ¡

• Each ¡criterion ¡ci ¡is ¡assigned ¡a ¡weight ¡wi
• Every ¡route ¡r ¡has ¡a ¡final ¡score ¡S(r) ¡: ¡
• The ¡route ¡with ¡highest ¡S(r) ¡is ¡selected ¡as ¡best: ¡

S(r) = wi ⋅ ai (r)

ci ∈C

∑

r* = argmax

r∈R

( wci ⋅ aci

ci ∈C

∑

)

Use ¡Weighted ¡Sum ¡Instead ¡of ¡Strict ¡Ranking ¡

4/5/11 ¡ 53 ¡ seMINArios ¡2011 ¡

• MulBple ¡decision ¡processes ¡running ¡in ¡parallel ¡
• Each ¡realizes ¡a ¡different ¡policy ¡with ¡a ¡different ¡set ¡of ¡weights ¡of ¡

policy ¡objecBves, ¡selecBng ¡potenBally ¡different ¡best ¡routes ¡

MulBple ¡Decision ¡Processes ¡

4/5/11 ¡ 54 ¡ seMINArios ¡2011 ¡

1/5/11 28

• Implemented ¡as ¡an ¡extension ¡to ¡XORP ¡

– Four ¡new ¡classifier ¡modules ¡(as ¡a ¡pipeline) ¡ – New ¡decision ¡processes ¡that ¡run ¡in ¡parallel ¡

• EvaluaBon ¡

– Classifiers ¡work ¡very ¡efficiently ¡ – Morpheus ¡is ¡faster ¡than ¡the ¡standard ¡BGP ¡decision ¡process ¡(w/ ¡mulBple ¡ alternaBve ¡routes ¡for ¡a ¡prefix) ¡ – Throughput: ¡unopBmized ¡prototype ¡can ¡support ¡a ¡large ¡number ¡of ¡decision ¡ processes ¡

Prototype ¡ImplementaBon ¡

4/5/11 ¡ 55 ¡ seMINArios ¡2011 ¡

iBGP ¡Scalability ¡and ¡Topology ¡Design: ¡ Summary ¡

• iBGP ¡full ¡mesh: ¡scaling ¡problems ¡
• SoluBons: ¡

– Route ¡reflectors ¡ – AS ¡confederaBons ¡

• Problem: ¡correctness ¡

– Griffin: ¡Checking ¡the ¡correctness ¡of ¡an ¡iBGP ¡graph ¡is ¡NP-­‑complete, ¡but ¡two ¡condiBons

¡ ensure ¡a ¡correct ¡(loop-­‑free) ¡iBGP ¡graph: ¡ ¡

• 1) ¡route-­‑reflectors ¡should ¡prefer ¡client ¡routes ¡to ¡non-­‑client ¡routes ¡
• 2) ¡every ¡shortest ¡path ¡should ¡be ¡a ¡valid ¡signaling ¡path ¡
• SoluBons: ¡

– iBGP ¡Topology ¡Design ¡Problem: ¡correctness ¡and ¡scalabilty ¡

• BGPSep ¡
• Fm-­‑opBmal ¡
• Skeleton ¡

4/5/11 ¡ 56 ¡ seMINArios ¡2011 ¡

1/5/11 29

iBGP ¡Scalability ¡and ¡Topology ¡Design: ¡ Summary ¡

• IETF: ¡ongoing ¡proposals ¡

– Improve ¡route ¡diversity ¡

• Add-­‑Paths ¡
• Best-­‑External ¡
• N-­‑Plane ¡RRs ¡
• Centralized ¡soluBons ¡

– Improve ¡route ¡diversity ¡and ¡choice ¡capabiliBes ¡using ¡an ¡“omniscient” ¡ pla~orm: ¡separa6ng ¡rou6ng ¡from ¡routers ¡ – Need ¡help ¡from ¡rouBng ¡architecture, ¡e.g. ¡MPLS ¡tunnels ¡from ¡ingress ¡to ¡ egress ¡ ¡

4/5/11 ¡ 57 ¡ seMINArios ¡2011 ¡

References ¡

1. [BE-­‑02] ¡P. ¡Marques, ¡R. ¡Fernando, ¡E. ¡Chen, ¡P. ¡Mohapatra, ¡Adver6sement ¡of ¡the ¡ best ¡external ¡route ¡in ¡BGP. ¡Internet ¡DraW ¡<draW-­‑ie~-­‑idr-­‑best-­‑external-­‑02.txt>. ¡ Expires: ¡February ¡8, ¡2011 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 2. [AP-­‑04] ¡D. ¡Walton, ¡A. ¡Retana, ¡E. ¡Chen, ¡ ¡J. ¡Scudder, ¡Adver6sement ¡of ¡Mul6ple ¡ Paths ¡in ¡BGP. ¡Internet ¡DraW ¡<draW-­‑ie~-­‑idr-­‑add-­‑paths-­‑04.txt>. ¡ExpiraBon ¡Date: ¡ February ¡2011 ¡ 3. [NRR-­‑02] ¡R. ¡Raszuk ¡(Ed), ¡R. ¡Fernando, ¡K. ¡Patel, ¡D. ¡McPherson, ¡K. ¡Kumaki, ¡ Distribu6on ¡of ¡diverse ¡BGP ¡paths. ¡Internet ¡DraW ¡<draW-­‑ie~-­‑grow-­‑diverse-­‑bgp-­‑ path-­‑dist-­‑02>. ¡Expires: ¡January ¡9, ¡2011 ¡ 4. [BST03] ¡Kedar ¡Poduri, ¡Cengiz ¡Alaeƒnoglu, ¡Van ¡Jacobson, ¡BST ¡-­‑ ¡BGP ¡Scalable ¡

• Transport. ¡NANOG ¡27, ¡2003 ¡

4/5/11 ¡ 58 ¡ seMINArios ¡2011 ¡

1/5/11 30

References ¡

5. [MJSAC09] ¡Yi ¡Wang, ¡Ioannis ¡Avramopoulos, ¡and ¡Jennifer ¡Rexford, ¡Design ¡for ¡ Configurability: ¡Rethinking ¡Interdomain ¡Rou6ng ¡Policies ¡from ¡the ¡Ground ¡Up. ¡ IEEE ¡Journal ¡on ¡Selected ¡Areas ¡in ¡CommunicaBons, ¡April ¡2009 ¡ 6. [RCP] ¡Nick ¡Feamster, ¡Hari ¡Balakrishnan, ¡Jennifer ¡Rexford, ¡Aman ¡Shaikh, ¡Jacobus ¡ van ¡der ¡Merwe, ¡The ¡case ¡for ¡separa6ng ¡rou6ng ¡from ¡routers. ¡In ¡Proceedings ¡ FDNA ¡'04, ¡ACM ¡SIGCOMM ¡workshop ¡on ¡Future ¡direcBons ¡in ¡network ¡ architecture ¡ 7. [iBGPRS09] ¡Uli ¡Bornhauser, ¡Peter ¡MarBni, ¡MarBn ¡Horneffer, ¡An ¡Inherently ¡ Anomaly-­‑free ¡iBGP ¡Architecture. ¡IEEE ¡34th ¡Conference ¡on ¡Local ¡Computer ¡ Networks ¡(LCN ¡2009). ¡Zürich, ¡Switzerland; ¡20-­‑23 ¡October ¡2009 ¡

4/5/11 ¡ 59 ¡ seMINArios ¡2011 ¡

An ¡experiment ¡on ¡iBGP ¡scaling ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 60 ¡

1/5/11 31

Experiment ¡goal ¡

• Scalability ¡is ¡generally ¡referred ¡to ¡the ¡number ¡of ¡iBGP ¡

sessions ¡

– AlternaBves ¡to ¡Full-­‑Mesh ¡

• Route ¡Reflectors ¡
• ConfederaBons ¡
• Etc… ¡
• We ¡want ¡to ¡understand ¡another ¡dimension: ¡

– The ¡interacBon ¡between ¡external ¡and ¡internal ¡BGP ¡ – In ¡parBcular, ¡the ¡influence ¡of ¡external ¡BGP ¡churn ¡over ¡intra-­‑ domain ¡”iBGP ¡churn”, ¡i.e. ¡the ¡intra-­‑domain ¡signalling ¡noise ¡ cause ¡by ¡eBGP ¡updates ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 61 ¡

Related ¡work ¡

• eBGP ¡duplicates ¡caused ¡by ¡unintended ¡eBGP-­‑iBGP ¡

interacBon ¡[ParkJLAMZ10] ¡

– Changes ¡in ¡non-­‑transiBve ¡aSributes ¡such ¡as ¡cluster-list

• Route ¡Reflectors ¡influence ¡on ¡iBGP ¡signaling ¡and ¡rouBng ¡

state ¡[McPhersonRIPE58] ¡

• PrevenBng ¡the ¡Unnecessary ¡PropagaBon ¡of ¡BGP ¡

Withdraws ¡[VandenSFPO09] ¡ ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 62 ¡

1/5/11 32

Experiment ¡definiBon ¡

• ObjecBve: ¡
• Determine ¡”transfer ¡funcBon” ¡for ¡different ¡iBGP ¡

topologies ¡

• For ¡the ¡Bme ¡being, ¡only ¡looking ¡at ¡the ¡total ¡of ¡generated ¡

updates ¡

• Use ¡the ¡same ¡data ¡to ¡feed ¡different ¡iBGP ¡topologies: ¡Full-­‑

Mesh ¡(baseline), ¡Bates, ¡Zhang, ¡Skeleton, ¡BGPSep, ¡Op6mal ¡ ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 63 ¡

IBGP topology eBGP Updates iBGP Updates

Experiment ¡definiBon ¡

• Topology ¡

– Stub ¡AS, ¡receiving ¡only ¡BGP ¡updates ¡ – SyntheBc ¡topologies ¡using ¡Igen ¡

• 25 ¡routers, ¡5 ¡ASBRs ¡
• IGP ¡uses ¡distance ¡metric ¡ ¡
• Data ¡

– RIPE-­‑RIS ¡RIBS ¡& ¡1 ¡hour ¡BGP ¡updates ¡ ¡

• 95 ¡percenBle ¡May ¡2006-­‑2010 ¡

– cbgp ¡simulaBon ¡engine ¡

• Load ¡RIB, ¡run ¡updates ¡traces, ¡obtain ¡logfile ¡with ¡messages ¡

exchanged ¡among ¡iBGP ¡routers ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 64 ¡

1/5/11 33

Basic ¡topology ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 65 ¡

1 10 11 12 13 14 15 16 17 18 19 2 20 21 22 23 24 3 4 5 6 7 8 9

Bates ¡RR ¡topology ¡

• POPs ¡RRs ¡

– 9,11 ¡

• Clients: ¡22 ¡

– 0,20 ¡

• Clients: ¡2,12,17,18 ¡

– 21,3 ¡

• Clients: ¡1,23 ¡

– 7,24 ¡

• Clients: ¡8,10,19 ¡

– 14,16 ¡

• 5 ¡
• Full-­‑mesh ¡of ¡RRs ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 66 ¡

1/5/11 34

Zhang ¡RR ¡topology ¡

• POPs ¡RRs: ¡same ¡as ¡Bates ¡
• Top ¡level ¡RRs: ¡4,6,13,15 ¡

– 9,11: ¡clients ¡of ¡4 ¡ – 14,16: ¡clients ¡of ¡4,6 ¡ – 0,20: ¡clients ¡of ¡4,6 ¡ – 21: ¡client ¡of ¡13,6 ¡ – 3: ¡client ¡of ¡13,15 ¡ – 7,24: ¡clients ¡of ¡13,15 ¡

• Full-­‑mesh ¡of ¡top ¡level ¡RRs ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 67 ¡

Early ¡results ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 68 ¡

!""# !""$ !""% !""& !"'" " !""""" (""""" #""""" %""""" '"""""" '!""""" '("""""

)*+,-./01,2,3

456372/308.,7-390-.0):;<:=0

):; >+??0@39A ;2,39 BA2./

C327 56372/3048.,7-39

1/5/11 35

Early ¡results ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 69 ¡

!""# !""$ !""% !""& !"'" " '" !" (" )" *" #" $"

+,-./01123014.567689:;768.<28=>

?6@@./01A +2801 BA2;3 C02D E=+,-./01123019E0+,-./0112301

Comments ¡

• Counter-­‑intuiBve ¡results ¡

– Both ¡for ¡Updates ¡and ¡RouBng ¡State ¡

• Find ¡theoreBcal ¡background ¡for ¡such ¡results ¡
• Further ¡experiment ¡

– Explore ¡“topology ¡space” ¡ – Is ¡this ¡topology ¡close ¡to ¡reality? ¡ – Get ¡some ¡real ¡data? ¡

• What ¡about ¡policies? ¡

4/5/11 ¡ seMINArios ¡2011 ¡ 70 ¡

1/5/11 36

References ¡

1. [ParkJLAMZ10] ¡InvesBgaBng ¡Occurrence ¡of ¡Duplicate ¡Updates ¡in ¡BGP ¡ Announcements, ¡Jong ¡Han ¡Park, ¡Dan ¡Jen, ¡Mohit ¡Lad, ¡Shane ¡Amante, ¡Danny ¡ McPherson ¡and ¡Lixia ¡Zhang. ¡PAM ¡2010, ¡Zurich, ¡April ¡2010. ¡ 2. [McPhersonRIPE58] ¡The ¡Intra-­‑domain ¡BGP ¡Scaling ¡Problem, ¡Danny ¡McPherson, ¡ Shane ¡Amante. ¡RIPE ¡58, ¡Amsterdam, ¡May ¡2009. ¡ 3. [VandenSFPO09] ¡Virginie ¡Van ¡den ¡Schrieck, ¡Pierre ¡Francois, ¡Cristel ¡Pelsser ¡and ¡ Olivier ¡Bonaventure. ¡PrevenBng ¡the ¡Unnecessary ¡PropagaBon ¡of ¡BGP ¡

• Withdraws. ¡Proceedings ¡of ¡IFIP ¡Networking, ¡2009. ¡

4/5/11 ¡ 71 ¡ seMINArios ¡2011 ¡