A Measurement Framework for Pin-Pointing Routing Changes Renata Teixeira (UC San Diego) with Jennifer Rexford (AT&T) NetTs’04 – Portland, OR

NetTs’04 2 Why understand routing changes?  Routing changes cause service disruptions  Convergence delay  Traffic shift  Change in path properties RTT, available bandwidth, or lost connectivity  Operators need to know  Why: For diagnosing and fixing problems  Where: For accountability Need to guarantee service-level agreements

NetTs’04 3 What can be done with active measurements?  Active measurements: traceroute-like tools  Can’t probe in the past  Shows the effect, not the cause User (s) Web Server (d) AS 1 AS 2 AS 3 AS 4

NetTs’04 4 Can we use passive measurements?  Passive measurements: public BGP data Data Correlation BGP update feeds root cause Data Collection (RouteViews, RIPE)

NetTs’04 5 Why Public BGP Data is Not Enough? Myth: The BGP updates from a single router accurately represent the AS C AB D BGP data collection dst AS 1 AS 2 No change The measurement system needs to capture the BGP routing changes from all border routers

NetTs’04 6 Why Public BGP Data is Not Enough? C AB D BGP data collection dst AS 1 AS 2 Myth:Routing changes visible in eBGP have greater impact end-to-end impact than changes with local scope. The measurement system needs to capture internal changes inside an AS

NetTs’04 7 Why Public BGP Data is Not Enough? A BGP data collection Myth:BGP data from a router accurately represents changes on that router / /16 The measurement system needs to know all routes the router knows.

NetTs’04 8 Misleading BGP Changes BGP data collection Myth:The AS responsible for the change appears in the old or the new AS path Accurate troubleshooting may require measurement data from each AS old: 1,2,8,9,10 new: 1,4,5,6,7,10

NetTs’04 9 Misleading BGP Changes Myth:Looking at routing changes across prefixes resolves AB C BGP data collection 10 7 AS 1 AS 2 AS 3 d1d1 d2d2 d3d3 12 ASes involved in the change need to cooperate to pin-point the reason for the change Changes for d 2, but not for d 1 and d 3

NetTs’04 10 Strawman Proposal: Omni Server  Creating an AS-level view  BGP feeds from all border routers Inject all routes known in each router  Internal routing data  Archive log of routing changes  Responding to queries  Local cause: responds directly  No local change: query neighbor AS  Local change from downstream cause: query old and/or new neighbor AS

NetTs’04 11 Diagnosis with Omnis i j Omni 1 Omni 3 Omni 2 Omni 4 User (s) Web Server (d) (i,s,d,t) (j,s,d,t’) failure link (3,4) AS 1 AS 2 AS 3 AS 4

NetTs’04 12 Conclusion  Passive data  AS-level view  History (answers in the past)  Distributed  Active querying  Servers, not routers  See cause, not effect

NetTs’04 13 Future Directions  How often are the myths violated?  Measurement studies of ISP networks  Doesn’t Omni require lots of data?  ISPs already collect this kind of data  Routing protocols extensions to reveal reasons of routing changes  Will ASes really cooperate?  Pressure to provide service-level agreements  Small group of ASes that choose to cooperate  Won’t ASes cheat?  Need techniques to detect persistent lying