Investigating occurrence of duplicate updates in BGP announcements

1. Investigating occurrence of duplicate updates in BGP announcements Jong Han Park1, Dan Jen1, Mohit Lad2,ShaneAmante3, Danny McPherson4, Lixia Zhang1 (UCLA1, Thousand Eyes Network Solutions2, Level-3 Communications3, Arbor Networks4) Passive and Active Measurement Conference 2010 Zurich, Switzerland

2. Investigating occurrence of duplicate updates in BGP announcements Jong Han Park1, Dan Jen1, Mohit Lad2,ShaneAmante3, Danny McPherson4, Lixia Zhang1 (UCLA1, Thousand Eyes Network Solutions2, Level-3 Communications3, Arbor Networks4) Passive and Active Measurement Conference 2010 Zurich, Switzerland Duplicate!

3. Why this work • BGP should never generate duplicates • In reality, duplicates can take up to 86% of the total updates during router’s busiest times • Unnecessary overhead in router’s processing time • Wasting network bandwidth • No systematic study yet • How much duplicates do we observe? • What is the impact of duplicates? • What is the cause of duplicate generation?

4. Define BGP duplicates • BGP is the routing protocol used in the Internet today • BGP duplicates • Purely identical update received from the same peer in the same session for a given destination prefix p • BGP operates in two modes: eBGP and iBGP • In this work, we study eBGP duplicate announcements

5. Quantifying the amount of duplicates • Dataset • BGP data collected all monitors in RouteViews and RIPE • With full table • Available for the entire measurement period • The numbers of monitors from 2002 to 2009: 27, 37,54, 67, 79, 100, 109, and 90 respectively • We filtered BGP updates caused by session resets • Minimum Collection Time (MCT) algorithm ** The reason why we have less monitors in March 2009: - RRC01 was down from March 20-31, 2009 - RRC13 was down from March 14-31, 2009 - RRC14 was down from March 24-31, 2009

6. MAX MIN Looking over time • Duplicate updates are always observed at different times • March 2009, • Duplicate updates fluctuate together with the total number of updates • Duplicate updates are not associated with a particular routing event

7. Duplicates vs. Different types of network • Duplicate updates are observed from different types of networks • No strong correlation between network type and the amount of duplicates ** BGP data collected from RV and RIPE RIS during March 2009 ** Tier1 ISPs: AS7018, AS3549, AS2914, AS209,AS6453,AS701, AS3561, AS1299 ** # of monitors: Tier1 (8), Transit (55), Stub (27)

8. Duplicates are responsible for most traffic during busiest times AS1853 86.42% • “Busiest time”: the times which a monitor generates the most number of updates • 20% of the monitors have more than 50% of totalupdates as duplicates • For AS1853, 86.42% of the total updates during thebusiest 267 secsare duplicates 17,925 updates in total 17,492 (~97%) are duplicates

9. 85.249.120.0/23 Unreachable 85.249.120.0/23 Reachable 85.249.120.0/23 Reachable Narrowing down the problem scope • Case study settings: • AS1 and AS2 has a BGP session. • In both AS1 and AS2, we have a monitor. • AS1 sends AS2 BGP updates (A/W/A/W/…) • This update triggers internal routing dynamics • Internal routing dynamics generate duplicates in eBGP AS1 Duplicate! AS2 85.249.120.0/23 Reachable

10. Investigating the causes of duplicates • Duplicates are due to eBGP-iBGPinteractions? • Let’s verify • Measurement setting: one router providing botheBGP and iBGP data • MRAI timer set to 0

11. Sig(U1) Sig(U2) Sig(U3) Sig(U4) Sig(U5) eBGP Sig(u1) Sig(u2) Sig(u3) Sig(u4) Sig(u5) iBGP U1 U2 U3 U4 U5 5 min Time eBGP u1 u2 u3 u4 u5 iBGP 5 min Time Inferring the cause of duplicate generation by matching iBGP and eBGP • Match updates using the signature signature (u) = peer || ASN || prefix || AS-PATH || ORIGIN || COMMUNITY || AGG • Moving window of 5 minutes • For each duplicate eBGP update • Find the matching iBGP update Un • Look at the previous iBGP update Un-1 to find the difference Duplicates! Matching iBGP update What is the difference with the previous update?

12. The cause(s) • Main reason: internal CLUSTER-LIST attribute change • Our controlled experiments additionally show • iBGP updates with changes in NEXT-HOP, LOCAL-PREF, and MED generate eBGP duplicates** ** One may have different results depending on router vendor and software version

13. Example of a duplicate update occurrence From page 7, Duplicates! P AS1 AS2 • Path from which the announcement is delivered flaps between RRC2-RR1-RRC1 and RRC2-RR2-RRC1 • When sending the update to eBGP peers, CLIST field is striped off by RRC1 • More alternative paths within AS more internal path exploration  more duplicates P AS1 AS2 P AS2 C: RR1 RRC2 RR1 P AS2 P AS2 C: RR2 P AS2 RR2 AS1 P AS2 RRC1 AS2 prefix p Larger networks can generate more duplicates!

14. Duplicates exist in a different form • From our large ISP, internalnon-transitive attribute(cluster-list) valueoscillation is coupled withtransitive attribute (community) value changes • we conjecture that this is the case for AS2914 and AS3549,where MED and MED+comm are coupled with internal flapping

15. Summary • Today, we observe non-trivial amount of eBGP duplicate updates • Duplicate updates can be responsible for much of router processing during busiest times • Our results suggest that internal dynamics leaks to the outside in the form of duplicate updates • There exists other forms of noise in BGP, and our work is the first step to reduce such noise

16. Thank you!Jong Han Park (jpark@cs.ucla.edu)

17. Thank you once again!Jong Han Park (jpark@cs.ucla.edu) Potentially superfluous!