OSPF & ISDN Backup Problems

Hi Guys,

I'm re-posting again, but this time I will explain my network better.

We have recently switched over to MPLS. Previously we were running EIGRP and ISDN was working fine. We have 30 remote routers and 2 central routers located in two different locations. So, it's a full mesh network however, we only serve business applications from the two central sites. The problem I'm having is when a branch fails over to ISDN the entire network slows down for a few seconds. I get a couple of time-outs on all of the routers. At the two central sites, we have PRI circuits for the remote sites to dial into when the primary links fail. All remote routers are set up as ABR routers. Serial interfaces are in area 0 and fastethernet interfaces are in different areas. (each site has different area). The ISDN interfaces at the remote routers are in area 0 and the dialer interfaces at the central sites are also in area 0. Should I place all ISDN interfaces in a separate area ? I tired placing the ISDN interfaces in a separate area, but then I was not able to route to the remote branch (had to reload the router). When a remote branch fails to ISDN I could see the neighbor relationship form. (successfully forms and it's in full loading stage, so no problems there). I could do static routes back to the remote routers, but I would like to have this set up dynamically if possible. Any input or suggestions would be greatly appreciated . Also, all remote routers are using floating static routes to activate the ISDN backup. I can post any router outputs if that helps.

Thank you!

Reply to
NetWorkMan
Loading thread data ...

While I have never run OSPF in a retail or branch situation, I would definitely advise you get those out of Area 0. When a link in area 0 goes down, all of area 0 must reconverge and recalculate paths. For this reason, your entire network will come to crawl. When I worked for a very large grocery retailer (1,200 plus locations), we ran eigrp to the majority of the sites, although I think in your situation, stub areas might do you well. Regardless, try to avoid placing wan links in area 0, particularly those with any type of regular up/down behavior.

Reply to
Trendkill

Our vendor only support OSPF and therefore we had to get rid of EIGRP. I may have to look into stub areas.

Reply to
NetWorkMan

You can also move all ISDN links into different OSPF process.

Regards, Andrey.

Reply to
Andrey Tarasov

Golden rule of OSPF - backbone should not be partitioned, even under fault conditions if you can avoid it.

if there anything on the LAN at the remote sites? if not then putting them into a different area is not helping with scale, just making life more complicated.

you can allow any other area to split into 2 bits and things will continue to work, but splitting area 0 causes black hole routing problems.

The ISDN interfaces at the

you would need a virtual link to make this work - note, not a good idea.

usually a carrier MPLS cloud uses statics or BGP - do you actually have OSPF on the MPLS, or are you tunnelling with something like GRE?

if the carrier is providing CE routers and you have OSPF neighbourship to them, then even though you are "talking" to them with OSPF there may not be native OSPF all the way through the cloud - in other words it isnt a single OSPF network.

Or if it is some sort of Ethernet transport, maybe all layer 2, maybe the hits are actually spanning tree events?

Sounds like you need a sniffer and deliberately cause some hits to see what is happening in detail.

try putting "log-adj detail" in the OSPF config, and see what gets logged.

When a remote branch fails to ISDN I could see

if you have floating statics anyway, then you dont really need OSPF on the backups -

30+ routers is not big for OSPF - but the "mesh" you mentioned worrys me.

log of events should help....

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.