An incremental algorithm for a generalization of the shortest-path problem
Journal of Algorithms
OSPF: Anatomy of an Internet Routing Protocol
OSPF: Anatomy of an Internet Routing Protocol
A case study of OSPF behavior in a large enterprise network
Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment
Inferring link weights using end-to-end measurements
Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment
A Case Study in Understanding OSPF and BGP Interactions Using Efficient Experiment Design
Proceedings of the 20th Workshop on Principles of Advanced and Distributed Simulation
Virtual routers on the move: live router migration as a network-management primitive
Proceedings of the ACM SIGCOMM 2008 conference on Data communication
Seamless BGP migration with router grafting
NSDI'10 Proceedings of the 7th USENIX conference on Networked systems design and implementation
Seamless network-wide IGP migrations
Proceedings of the ACM SIGCOMM 2011 conference
Lossless migrations of link-state IGPs
IEEE/ACM Transactions on Networking (TON)
| Hi-index | 0.00 |
Many recent router architectures decouple the routing engine from the forwarding engine, allowing packet forwarding to continue even when the routing process is not active. This opens up the possibility of using the forwarding capability of a router even when its routing process is brought down for software upgrade or maintenance, thus avoiding the route flaps that normally occur when the routing process goes down. Unfortunately, current routing protocols, such as BGP, OSPF and IS-IS do not support such operation. In an earlier paper [1], we described an enhancement to OSPF, called the IBB (I'll Be Back) capability, that enables a router to continue forwarding packets while its routing process is inactive.When the OSPF process in an IBB-capable router is inactive, it cannot adapt its forwarding table to reflect changes in network topology. This can lead to routing loops and/or black holes. In this paper, we focus on the loop problem and provide a detailed analysis of how and when loops are formed and propose solutions to prevent them. We develop two necessary conditions for the formation of routing loops in the general case when multiple routers are inactive. These conditions can easily be checked by the neighbors of the inactive routers. Simulations on several network topologies showed that checking the two conditions together signaled a loop in most cases only when a loop actually existed.