1. Yaping Zhu yapingz@cs.princeton.edu with: Jennifer Rexford (Princeton University) Aman Shaikh and Subhabrata Sen (ATT Research) Route Oracle: Where Have All the Packets Gone?

2. Yaping Zhu, Princeton University 2 Route Oracle: Network Management Tool Useful for many different applications Src: A Dest: B IP Packet

3. Case 1: Historical Traceroute Yaping Zhu, Princeton University 3 Network troubleshooting –Diagnose reachability or performance problems Traceroute –Lists of hops along the path to the destination –Popular active measurement tool –Limitation: sending IP packets in real time Wouldn’t it be nice to run traceroute in the past?

4. Case 1: Historical Traceroute Historical Traceroute by Route Oracle Requirement: answer queries at any time Yaping Zhu, Princeton University 4 Src: A Dest: B

5. Case 2: Analysis of Routing Disruptions React quickly to large network disruptions –E.g. Mediterranean Cable Break What happened? Yaping Zhu, Princeton University 5

6. Case 2: Analysis of Routing Disruptions Yaping Zhu, Princeton University 6 Characterization by Route Oracle –Percent of IPs unreachable? –How was the traffic rerouted? Help network operators –Respond to customer complaints –Redirect traffic Requirement: answer queries at scale

7. Page 7 AT&T Sprint Internet AT&T CDN Server Atlanta users Router in Atlanta Egress in Atlanta Egress in Washington DC Case 3: Service Quality Management CDN Throughput Drop caused by Egress Change Case Study from AT&T Intelligent Content Distribution Service

8. Application-layer monitoring is not enough –Correlate with network-layer changes: routing changes, network congestion –Joint analysis with Route Oracle Requirement: answer queries at scale and in real time Yaping Zhu, Princeton University 8 Case 3: Service Quality Management

9. Yaping Zhu, Princeton University 9 Route Oracle: System Interfaces Route Oracle Query Input: vantage point router, query time period, list of IPs or prefixes Output: route changes for each query (prefix match, egress router, AS path) Input Data Feeds: periodic dumps of routing table continuous feed of updates

10. Challenges Changes in the longest prefix match (LPM) Scalability Real time Yaping Zhu, Princeton University 10

11. Yaping Zhu, Princeton University 11 BGP Background Src: A Dest: B IP Packet Ingress Router Egress Router AS Path AS (Autonomous System)

12. BGP Background BGP updates are based on prefixes An IP address can be covered by multiple prefixes Longest prefix-match (LPM) determines forwarding LPM may change over time Yaping Zhu, Princeton University 12 Routing Table: 128.112.0.0 / 16 128.112.0.0 / 24 IP Packet Longest Prefix Match

13. Yaping Zhu, Princeton University 13 Track LPM Changes: Example Track LPM changes for IPs from 12.0.0.0 to 12.255.255.255 Suppose in the routing table, we have prefix: –12.0.0.0/8 –12.0.0.0/16 12.0.0.012.255.255.255 /8 /16 12.0.255.25512.1.0.0 /8 /16 LPM IPs

14. Yaping Zhu, Princeton University 14 Track LPM Changes: Example BGP route announcement: 12.0.0.0/24 /24 More specific unchanged 12.0.255.255 12.0.0.012.255.255.255 /8 /16 12.0.255.25512.1.0.0 /8 /16 LPM IPs 12.0.0.0 unchanged

15. Yaping Zhu, Princeton University 15 Track LPM Changes: Example BGP route withdrawal: 12.0.0.0/16 /24 unchanged Less specific 12.0.255.255 12.0.0.012.255.255.255 /8 /16 12.0.255.25512.1.0.0 /8 LPM IPs 12.0.0.0 unchanged

16. Yaping Zhu, Princeton University 16 Track LPM Changes: at Scale Definitions –Prefix set: all matching prefixes for a given IP address –Address range: contiguous addresses that have the same prefix set /24 12.0.255.255 12.0.0.012.255.255.255 /8 12.0.255.25512.1.0.0 /8 /16 LPM IPs 12.0.0.0 /16

17. Yaping Zhu, Princeton University 17 Track LPM Changes: in Real Time Definitions –Prefix set –Address range Real-time algorithm –For each update: Update address ranges Update prefix set for affected address ranges

18. Yaping Zhu, Princeton University 18 Route Oracle: System Components Precomputation Query Input Input Data Feeds Query Processing Snapshot of routes for address ranges Output Incremental route updates for address ranges

19. Query Processing: Optimizations Amortize the cost of reading address range records across al queried IP addresses Parallelize the processing of the address range files on multi-core machines Yaping Zhu, Princeton University 19

20. Performance Evaluation Goals –Pre-processing module: handle updates stream in real time? –Query module: query processing time Experiment on SMP server –two quad-core Xeon X5460 Processors –Each CPU: 3.16 GHz and 6 MB cache –16 GB of RAM Yaping Zhu, Princeton University 20

21. Evaluation: Pre-processing Time Experiment design –BGP updates received over fixed time-intervals –Compute the pre-processing time for each batch of updates Results –99% of the updates received in 5 mins interval could be processed within 2 seconds –The maximum time to process the BGP updates received in 20 mins intervals is about 5 seconds Yaping Zhu, Princeton University 21

22. Evaluation: Query Processing Time 22

23. Evaluation: Query Parallelization 23

24. Prototype Deployment Deployed since Sep 2009 (AT&T) –Process BGP updates from 25 vantage points at PoPs Systems interfaces –Both GUI and command-line interfaces Services –Network troubleshooting –ICDS (Intelligent Content Distribution Services) Performance optimizations based on user feedback Yaping Zhu, Princeton University 24

25. Conclusion Route Oracle provides simple functionality –Crucial for many network management tasks Definition of address ranges –Track route changes at scale and in real time Design, implementation, evaluation, deployment –Systems optimizations to improve performance Yaping Zhu, Princeton University 25

26. Thanks! Questions & Comments? yapingz@cs.princeton.edu http://www.cs.princeton.edu/~yapingz/links/per09.pdf Yaping Zhu, Princeton University 26

27. Evaluation: Pre-processing Time 27