On the correctness of IBGP configuration
Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications
Preventing persistent oscillations and loops in IBGP configuration with route reflection
Computer Networks: The International Journal of Computer and Telecommunications Networking
Design and implementation of a routing control platform
NSDI'05 Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2
Intra-domain routing convergence with centralized control
Computer Networks: The International Journal of Computer and Telecommunications Networking
Quantifying the BGP routes diversity inside a tier-1 network
NETWORKING'06 Proceedings of the 5th international IFIP-TC6 conference on Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications Systems
Hi-index | 0.00 |
The Internet is organized as a collection of administrative domains, known as Autonomous Systems (ASes). These ASes interact through the Border Gateway Protocol (BGP) that allows them to share reachability information. Adjacent routers in distinct ASes use external BGP (eBGP), whereas in a given AS routes are propagated over internal BGP (iBGP) sessions between any pair of routers. In large ASes where a logical full-mesh is not possible, confederations or route reflectors (RRs) are used. However, these somewhat scalable alternatives have introduced their own set of unpredictable effects (persistent routing oscillations and forwarding loops causing an increase of the convergence time) addressed in the literature [1]. The solution we propose to these issues consists of a structured routing overlay holding a comprehensive view of the routes. We describe the design of a distributed entity that performs BGP route pre-computation for its clients inside a large backbone network and propagates the paths to the routers. Compared to the current iBGP routing, the advantage of the overlay approach is the separation between the responsibility of the control plane (route storage and best path computation) and the forwarding of the packets. One of the major improvements we bring is the divided routing table tackling the scalability concerns and allowing for parallel computation of paths.