OSPF and ISDN Backup

Sounds kida like a timer issues to me.

You may just need to cut down on some timers so the network converges faster.

The previous poster is correct decreassing timers will spead up convergence when running OSPF. You will need to do this on all routers in the area. If you are truly doing a hub and spoke design, and the all traffic to other sites and the internet flows thru the hub you may want to consider an option of static routes point to the hub. and with floating statics in place for the ISDN connections. Under this design your remote areas do not need to know what is happening at each one if the have to cross the hub anyhow.

Option 2. Use hierarchay in your design with a seperate area for the remote sites, and then perform address aggregation into the hub. This way the remote sites will not reconverge for every flap.

How many routers are in your network ?

Do you have a single OSPF area or multiple OSPF areas ?

What is the reason for using OSPF as the IGP (i.e. is this a multi- vendor router network) ?

How many routers at the hub site have ISDN interfaces ( assuming they are PRI's) ?

you might want to not allow OSPF over the ISDN route, which should simplify the topology change.

Also unless you inject a default route into OSPF to act as a black hole, the ISDN lines will tend to come up when a packet to an unknown address finds the static.....

It creates a few second times-outs on all of the

No - adding areas isnt going to help much durectly, although summarising routes is at the area boundary would cut down how far the update has to go, and where it has an effect.

The Dykstra should only affect routes across the "downed" serial link.

If that isnt happening, you might want to try incremental updates.

dont forget that the ISDN is going to take a second or 2 to come up - so you may get a 2nd set of OSPF updates when the link is actually up.

if should only matter for sites where the routes change (and where there is a 2nd path to the site) - anywhere else the old and new routing tables will be the same, so calculating them a couple of sec later should not have any effect.

If you are truly doing a hub and spoke design, and the

there are interface timers that affect how quickly a link is actually declared down - whether they alter the convergence time depends on the interface type and exactly which type of "down" you get in practice.

try altering carrier-delay (default is either 500 or 5000 mSec). if you put it to zero, then add "dampening" to the interface in case the link flaps.

if the link doesnt send a physical "down" event (eg an Ethernet WAN without link loss forwarding), then alter the hello and dea timers to detect a "down" faster.

Note this can seriously load a router with a lot of adjacencies, so be cautious on the hub box. Note2 - tinkering with the timers will kill an adjacency on the 1st change - so do the far end 1st unless you have a back door........

there are also a couple of global timers for OSPF itself - the defaults defer a recalc for to allow updates to arrive from multiple neighbours. flip side is, the routing table doesnt get undated until all this lots kicks off.

look for the ospf "throttle / lsa" commands - some IOS versions claim this is off by default, but i had to tweak this on a Cat 6509 with 12.2 to get down to 100 mSec convergence (on GigE, so likely not the same as your problem).

how about - even on a Cisco router, OSPF is more predictable / reliable than EIGRP? :)

here is an SRND (actually for campus) that gives some good tips on using OSPF (and EIGRP) to provide high availability and fast convergence.

in reality, fast convergence is only really about how quickly you find an alternate to a lost path.

bringing links back up is much less of an issue (as long as you dont get a forwarding hit during the topology change)

if you had a backup path then getting the main link working quickly and with minimal side effects is much more important than doing that instantly.

and if you didnt - well everything stopped working when the main link died, so it will take plenty of time and effort to get everything back anyway, and the users probably went home / for coffee when it happened.....

Also would be useful for OP to post the output of "show ip ospf statistics"

for the hub and several of the spoke routers