Longitudinal study of BGP monitor session failures

Abstract

BGP routing data collected by RouteViews and RIPE RIS have become an essential asset to both the network research and operation communities. However, it has long been speculated that the BGP monitoring sessions between operational routers and the data collectors fail from time to time. Such session failures lead to missing update messages as well as duplicate updates during session re-establishment, making analysis results derived from such data inaccurate. Since there is no complete record of these monitoring session failures, data users either have to sanitize the data discretionarily with respect to their specific needs or, more commonly, assume that session failures are infrequent enough and simply ignore them. In this paper, we present the first systematic assessment and documentary on BGP session failures of RouteViews and RIPE data collectors over the past eight years. Our results show that monitoring session failures are rather frequent, more than 30% of BGP monitoring sessions experienced at least one failure every month. Furthermore, we observed failures that happen to multiple peer sessions on the same collector around the same time, suggesting that the collector's local problems are a major factor in the session instability. We also developed a web site as a community resource to publish all session failures detected for RouteViews and RIPE RIS data collectors to help users select and clean up BGP data before performing their analysis.

Explaining BGP Slow Table Transfers

“…This imposes much stress on itself and is likely to become the bottleneck of table transfer performance. In Figure 8(c), we observe that RouteViews table transfers have more spread-out delay ratios, which could be due to the fact that, compare to ISP A , RouteViews monitors are from 8 includes 3038 table transfers 9 that is, whether a transfer is due to a failure of the TCP sender or receiver Empirically, we say that the sender-side factors (as well as the receiver-side and network factors) are major if they collectively accounts for more than 30% of the table transfer duration (i.e., delay ratio > 0.3). The 0.3 threshold is an engineering choice to allow more than one major factors been selected for a table transfer, which is rather common based on our observations.…”

“…Compared to previous works that only use BGP data [8,19,24,28], we seek to collect and Stretch of table transfers analyze the corresponding TCP packet traces, with the goal to reveal distinct transport protocol issues. We collected BGP data at a large ISP (ISP A ) and the RouteViews [2] project.…”

“…Also marked in the figure is a sample table transfer bounded by the network factors. To understand the overall trend in more detail, we infer whether a table transfer is triggered by a sender or receiver 9 using the method in [8], further marked as the solid square points. Figure 8 (a) and (b) suggest that the triggering end could account more on the table transfer delay.…”

“…Typically neighboring BGP routers are connected by high speed lines, and thus, the BGP routing update exchanges are expected to be very fast in general. However, both the research and operation communities have reported alarmingly long delays (i.e., up to tens of minutes) in BGP table transfers, the particular massive BGP updates triggered by BGP session resets [8,10,24,25,28]. It remains unclear, given only the BGP level information, what causes these slow table transfers or how to fix them.…”

Measuring BGP AS path looping (BAPL) and private AS number leaking (PANL)

“…Several studies have been conducted on routing loops, but few of them have focused on BAPL behavior or on the relationship between BAPL and forwarding looping. 24 Tsinghua Science and Technology, February 2018, 23(1): [22][23][24][25][26][27][28][29][30][31][32][33][34] Some studies have focused on forwarding AS path loops or forwarding routing loops. For example, Paxson has studied routing loops using end-to-end traceroute measurements collected in 1994 and 1995 [15] .…”