Shane Amante

BGP route reflection revisited

The original BGP design requires that all BGP speakers within an autonomous system be directly connected with each other to create a full mesh, and BGP update messages be propagated to directly connected neighbors only. This requirement leads to BGP session scalability problems in networks with large numbers of BGP routers. Route reflection was proposed as a quick fix to address this BGP session scalability problem and has been widely deployed in the operational Internet without a thorough analysis of its pros and cons. In this article, we first provide an overview of the route reflection design, summarize the discoveries from published literature, and discuss the trade-offs in using route reflection as compared to using a fully connected i-BGP mesh. Then we show that well engineered route reflector placement can overcome certain drawbacks, and that a few issues remain open for future study.

The great IPv4 land grab: resource certification for the IPv4 grey market

The era of free IPv4 address allocations has ended and the grey market in IPv4 addresses is now emerging. This paper argues that one cannot and should not try to regulate who sells addresses and at what price, but one does need to provide some proof of ownership in the form of resource certification. In this paper we identify key requirements of resource certification, gained from both theoretical analysis and operational history. We further argue these requirements can be achieved by making use of the existing reverse DNS hierarchy, enhanced with DNS Security. Our analysis compares reverse DNS entries and BGP routing tables and shows this is both feasible and achievable today; an essential requirement as the grey market is also emerging today and solutions are needed now, not years in the future.

Explaining BGP Slow Table Transfers

Although there have been a plethora of studies on TCP performance in supporting of various applications, relatively little is known about the interaction between TCP and BGP, which is a specific application running on top of TCP. This paper investigates BGPs slow route propagation by analyzing packet traces collected from a large ISP and Route Views Oregon collector. In particular we focus on the prolonged periods of BGP routing table transfers and examine in detail the interplay between TCP and BGP. In addition to the problems reported in previous literature, this study reveals a number of new TCP transport problems, that collectively induce significant delays. Furthermore, we develop a tool, named T-DAT, that can be deployed together with BGP data collectors to infer various factors behind the observed delay, including BGPs sending and receiving behavior, TCPs parameter settings, TCPs flow and congestion control, and network path limitation. Identifying these delay contributing factors makes an important step for ISPs and router vendors to diagnose and improve the BGP performance.

A comparative study of architectural impact on BGP next-hop diversity

Large ISPs have been growing rapidly in both the size and global connectivity. To scale with the sheer number of routers, many providers have replaced the flat full-mesh iBGP connectivity with a hierarchical architecture, using either Route-Reflection (RR) or AS confederation. Given that each intermediate iBGP router in the hierarchy selects and propagates only one best path per destination network, there is a common perception that, compared to full-mesh, a hierarchical iBGP connectivity is likely to lose sight of alternative paths to external destinations. To gauge the path diversity reduction in the operational networks, we performed a comparative study by using iBGP data collected from two global-scale ISPs, with full-mesh core and RR architecture respectively. Our results show that both ISPs suffer a significant reduction (up to 42%) in the overall path diversity. However the specifics of different iBGP architectures only made a minor impact (less than 2.9%) on this reduction. Rather, in both ISPs the majority of the alternative paths are eliminated by the first two criteria in BGP best path selection, i.e., LOCAL PREF and AS PATH length.