By Topic

Avoiding instability during graceful shutdown of multiple OSPF routers

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$33 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

3 Author(s)
Shaikh, A. ; AT&T Labs.-Res. ; Dube, R. ; Varma, A.

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, 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

Published in:

Networking, IEEE/ACM Transactions on  (Volume:14 ,  Issue: 3 )