Observation and analysis of BGP behavior under stress
Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment
BGP Design and Implementation
Dynamics of hot-potato routing in IP networks
Proceedings of the joint international conference on Measurement and modeling of computer systems
FRTR: A Scalable Mechanism for Global Routing Table Consistency
DSN '04 Proceedings of the 2004 International Conference on Dependable Systems and Networks
Identifying BGP routing table transfers
Proceedings of the 2005 ACM SIGCOMM workshop on Mining network data
Finding a needle in a haystack: pinpointing significant BGP routing changes in an IP network
NSDI'05 Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2
Origin of route explosion in virtual private networks
CoNEXT '07 Proceedings of the 2007 ACM CoNEXT conference
Longitudinal study of BGP monitor session failures
ACM SIGCOMM Computer Communication Review
Route flap damping with assured reachability
Proceedings of the Sixth Asian Internet Engineering Conference
Identifying BGP routing table transfers
Computer Networks: The International Journal of Computer and Telecommunications Networking
Sequential aggregate signatures with lazy verification from trapdoor permutations
ASIACRYPT'12 Proceedings of the 18th international conference on The Theory and Application of Cryptology and Information Security
Hidden anomaly detection in telecommunication networks
Proceedings of the 8th International Conference on Network and Service Management
Hi-index | 0.00 |
Researchers and network operators often say that BGP table transfers are slow. Despite this common knowledge, the reasons for slow BGP transfers are not well understood. This paper explains BGP table transfer delays by combining BGP messages collected at a large VPN provider backbone and controlled experiments with routers of three different vendors as well as a software BGP speaker. Our results show that table transfers both in the provider network and in the controlled experiments contain gaps, i.e., periods in which both the sending and receiving routers are idle, but no BGP routes are exchanged. Gaps can represent more than 90% of the table transfer time. Our analysis of a software router and discussions with router vendors indicate that gaps happen because of the timer-driven implementation of sending of BGP updates. Hence, gaps represent an undocumented design choice that gives preference to more controlled router load over faster table transfers.