Pinpointing delay and forwarding anomalies using large-scale traceroute measurements

Abstract

Understanding data plane health is essential to improving Internet reliability and usability. For instance, detecting disruptions in peer and provider networks can identify repairable connectivity problems. Currently this task is time consuming as it involves a fair amount of manual observation, as an operator has poor visibility beyond their network's border. In this paper we leverage existing public RIPE Atlas measurement data to monitor and analyze network conditions; creating no new measurements. We demonstrate a set of complementary methods to detect network disruptions using traceroute measurements, and to report problems in near real time. A novel method of detecting changes in delay is used to identify congested links, and a packet forwarding model is employed to predict traffic paths and to identify faulty routers and links in cases of packet loss. In addition, aggregating results from each method allows us to easily monitor a network and correlate related reports of significant network disruptions, reducing uninteresting alarms. Our contributions consist of a statistical approach to providing robust estimation of Internet delays and the study of hundreds of thousands link delays. We present three cases demonstrating that the proposed methods detect real disruptions and provide valuable insights, as well as surprising findings, on the location and impact of the identified events. arXiv:1605.04784v2 [cs.NI] 15 May 2017 (4,307 IPv6 probes) connected within the eight studied months.As our study relies solely on traceroute results the scope and terminology of this paper are constrained to the IP layer. That is, a link refers to a pair of IP addresses rather than a physical cable.Consequently, the proposed methods suffer from common limitations faced by traceroute data [29,40,28]. Traceroute visibility is limited to the IP space, hence, changes at lower layers that are not visible at the IP layer can be misinterpreted. For example, the RIPE Atlas data reports MPLS information if routers support RFC4950. But for routers not supporting RFC4950, the reconfiguration of an MPLS tunnel is not visible with traceroutes while being likely to impact observed delays. The RTT values reported by traceroute include both network delays and routers' slow path delay [28]. Therefore, the delay changes found using traceroute data are not to be taken as actual delay increases experienced by TCP/UDP traffic, though they are good for detecting network damage. CHALLENGES AND RELATED WORKMonitoring network performance with traceroute raises three key challenges. In this section, we present these challenges, discuss how they were tackled in previous (a) Round-trip to router B (blue) and C (red).(b) Difference of the two round-trips (∆ P BC ).

Chocolatine: Outage Detection for Internet Background Radiation

“…Disco [27] detects surge of Atlas probe disconnections using a burst modeling algorithm. Using also Atlas data, authors of [12] rely on the central limit theorem to model usual Internet delays and identify network disruptions.…”

Large-Scale Characterization and Segmentation of Internet Path Delays With Infinite HMMs

“…To validate the ability of our method to detect events, we analyze two events which have been discussed in the literature (as this provides some groundtruth against which we can compare our results): AMS-IX outage in May 2015 [4,17,21], and DE-CIX Frankfurt outage in April 2018 [5] [4], on the 13th of May 2015, AMS-IX experienced a partial outage due to a switch interface generating looped traffic on the peering LAN. The event lasted for seven minutes and two seconds, from 10:22:12 to 10:29:14 (UTC time) before the switch interface was disconnected.…”

Detecting Network Disruptions At Colocation Facilities

“…In [14] a technique is proposed to address these challenges when a link is observed by a sufficient number of probes with different return paths. That technique monitors the shifts in the distribution of the median differential RTT(RT T Dif f ) and distinguishes strong alarms.…”

“…Note that multiple routers of colo A and colo B may be involved in this grouping. Like in [14], we calculate confidence intervals for both the observed and the reference RT T Dif f to detect significant statistical changes. If those confidence intervals stop to ovelap we report an alarm like those of Fig.…”