Page 1 of 1

OSPF Slow convergence

Posted: Tue Sep 13, 2011 10:24 pm
by hopp
Below is a rough approximation of one of our networks. Lines are wireless links. This network is about 85 miles long and located in hilly terrain so no more wireless links can be easily added to shorten its overall path.

I've tried NBMA OSPF backbone area and while it works the convergence time is several minutes after any break.
I've used the default timing and redistribute connected routes.

Any ideas on where best to partition the area or other tips which could speed convergence?

Edit:Blue squares are Mikrotik routers.

Re: OSPF Slow convergence

Posted: Tue Sep 13, 2011 11:03 pm
by fewi
Are those routed links, or bridged links?

Is this all one big area?

If they're routed links and it is one area my suggestion would be the below.

- Red dots are routers in the backbone area (
- Yellow dots are routers in a not so stubby area ( advertising a default route on the ASBR.
- Green dots are routers in a stubby area (
- Orange dots are routers in a stubby area (
- Cyan dots are routers in a stubby area (
Try to summarize at the area borders via area ranges as much as you can to hide any thrashing within the area from other areas. Hopefully this won't require too much re-addressing of links/connected routes. That's going to be the major benefit: summarizing at area borders allows to you to completely hide that links within an area are having events because the summary inter-area route advertised to other areas stays completely stable.
That should minimize convergence time.

Re: OSPF Slow convergence

Posted: Tue Sep 13, 2011 11:45 pm
by hopp
I was never able to see the clear area division because I kept putting the backbone area at the GW.


Re: OSPF Slow convergence

Posted: Wed Sep 14, 2011 5:59 am
by changeip
im still thrashing some of this on my own as well. since they are nbma neighbors they are slower correct? the default polling timer is 2 minutes, what happens if we made that 30s or so? Is that a bad idea?

OSPF Slow convergence

Posted: Wed Sep 14, 2011 6:24 am
by fewi
You absolutely can, setting it to 30s would definitely help getting a down peer back up quicker. I got the impression OP was more worried about convergence time (the time it takes for the routers in an area to have synchronized their LSDBs) than peer recovery time, but lowering the polling value is definitely a good idea if you are worried about that - and getting routers back up quick would certainly be a good thing. In proper NBMA networks (multiple peers in a subnet) you'd want higher values than in point to point links like in the network OP has - you can go quite low with those. For wireless point to point links you're just picking NBMA because of the unreliable multicast delivery, and the fact that multicast is delivered at the lowest common denominator data rate.