Identifying BGP Routing Table Transfer. !Machu Picchu!

Transcription

1 Identifying BGP Routing Table Transfer Beichuan Zhang (Univ. Of Arizona) Vamsi Kambhampati (Colorado State Univ.) Daniel Massey (Colorado State Univ.) Mohit Lad (Univ. Of California, LA) Lixia Zhang (Univ. Of California, LA) Tool URL: Picchu!

2 BGP Table Transfers Session Resets & Table Transfers Monitored Peer BGP Session Break-Down BGP Data Collector R RIBR RIB_In RIBR TCP session breakdown Loss of KeepAlive messages Router internal errors Throw away whatever is learned from R

3 Session Resets & Table Transfers Monitored Peer BGP Session Establishment BGP Data Collector R RIBR RIBR RIB_In RIBR R send it s RIB table Collector enters RIBR into it s RIB_In Why Identify Table Transfers? Remove Data Collection Artifacts Table Transfers don t reflect routing dynamics First stage of most BGP analysis Understand How Often Resets Occur Nearly 15-20% of updates due to table transfers! Optimize BGP differently if problem is frequent resets instead of frequent incremental updates Prior approaches relied on ad-hoc techniques Delete updates if # of update > 1000 in 30 seconds Delete all duplicate announcements Our approach is show to be accurate

4 Table Transfer Problem Objective: Detect all table transfers For each table transfer, identify: starting time: timestamp of first table transfer update duration: how long the transfer lasted Minimum Collection Time Algorithm

5 Collection Time For an update received at time t, define it s collection time, s(t), as the time it takes for all (unique) prefixes to be announced session down session up p3 p1 p2 p1 p2 p3 p4 p5 p3 downtime time s(10) = 15 s(14) = 11 s(17) = 8 s(21) = 4 s(22) =! local minimum Update Stream and Collection Time Basic Approach Sample s(t) ~ t Basic MCT Algorithm: 1. For each update at time t, calculate its collection time, s(t) 2. Find all local minima of s(t) 3. Each local minimum is considered as a table transfer. 1. starting time is t (timestamp) 2. duration is s(t) (collection time)

6 Practical Tune-Ups Expected Table Size Estimation Conflicting Table Transfers Other practical tune-ups in paper Expected Table Size Get Table Size from latest RIB snapshot RIB as close as possible to updates Table Size may vary during downtime! Incremental updates change table size too.. Don t count all prefixes from table size Instead, use a fraction N of last know table size Where N = 0.99 (99%)

7 Conflicting Table Transfers Monotonicity breaks due to update timing! [10, 14] [15, 12] [14, 10] [21, 6] s(14), s(21) are two conflicting local minima! A table transfer started (at t=21) when another table transfer is in progress (from t=14, to = 24) Assume table transfers take short duration to complete S(14) = 10 > 2(21) = 6, throw away s(14) and keep s(21) Results Validation using RIPE Session Reset logs Detection Accuracy Does our approach find the exact starting time? Table Transfers in RouteViews Data Note: RouteViews does not provide session state logs Tool Download URL:

8 Validation Using RIPE Data 495, Resets with Table Transfers 15, Resets w/o Table Transfers 29, Table Transfers w/o Resets Session Resets Resets with Table Transfers Transfers w/o Resets resets w/o transfers perfect transfers w/o resets Detection Accuracy Inaccuracy (Offset) Difference of: Detected transfer start time First update after reset log Zero Offset for 90% of Table Transfers For those with Non-Zero Offset 50% are below 30 seconds 50% have only 1 update (within offset time)

9 Table Transfers in RV Data Data Collector Instability Monitored Peer Instability Comparison With Prior Approaches Duplicate removal approach Remove all duplicate announcements 30 sec bin based approach Remove if # of updates > 1000 in 30 seconds Both remove table transfer updates But.. both remove a lot of valid updates! Our Approach identifies table transfers accurately

10 Conclusion & Future Work Download our tool and see for yourself Future Work: Identify table transfers due to remote resets Questions?