Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) Re: Re: OSPF question



>From: Joe Portman <baron@ws4.aa.net>
>Date: Sun, 31 Aug 1997 10:38:21 -0700 (PDT)
>Subject: Re: (ASCEND) Re: OSPF question
>
>On Fri, 29 Aug 1997, Peter Lalor wrote:
>
>> >In the past, we've tried to use OSPF on the Maxen and had the usual
>>troubles
>> >with it.  The consensus on this list seems to be that if I "flatten" out my
>> >OSPF configuration, getting rid of the stub areas and making everything be
>> >the backbone, OSPF should be stable.  Does this match everyone's
>>experience?
>>
>> We run OSPF between a 4000 (5.0Ap16) and a TNT (1.3A), area 0, with no
>> problems.
>>
>> This was not the case in earlier releases and frankly I'm afraid to upgrade
>> although I can see I'm going to have to to address K56 problems.
>
>Since we've started using OSPF in our Maxen the following symptoms have
>cropped up:
>
>1. Random reboots once every two weeks or so. Sometimes only a day,
>   sometimes as long as three weeks.
>
>2. OSPF dies with a memory allocation error, stopping OSPF. This error
>   causes routing to stop working altogether, resulting in a MAX that
>   takes calls and leaves the customer with a "dead" connection.
>
>#1 is painful but only irritating.
>
>#2 is simply unacceptable.
>
>-
>-----------------------------------------------------------------------------
>J
>oe Portman  - Alternate Access Inc.     Affordable, Reliable Internet
>-
>-----------------------------------------------------------------------------
>
>>------------------------------
>
>From: "Alex.Bligh" <amb@xara.net>
>Date: Sun, 31 Aug 1997 20:20:03 +0100
>Subject: Re: (ASCEND) Re: OSPF question
>
>> Since we've started using OSPF in our Maxen the following symptoms have
>> cropped up:
>>
>> 1. Random reboots once every two weeks or so. Sometimes only a day,
>>    sometimes as long as three weeks.
>>
>> 2. OSPF dies with a memory allocation error, stopping OSPF. This error
>>    causes routing to stop working altogether, resulting in a MAX that
>>    takes calls and leaves the customer with a "dead" connection.
>>
>> #1 is painful but only irritating.
>>
>> #2 is simply unacceptable.
>>
>Yep, we see this too. Except our MTBF on #1 is a couple of days.
>Ascend have now managed to duplicate the problem in their labs,
>allegedly. Whether or not this means they'll deign to fix it is,
>of course, another matter. Allegedly due to "duplicate routes"
>(which I presume is a reference to a memory leak if your network
>has more than one feasible route to any given destination).
>
>If you are really lucky you can get it to do #3 (crash without
>dumping core).
>
>Alex Bligh
>Xara Networks

I'm sorry to hear you guys are having OSPF troubles. I had the same kind of
problems for ages and went through extensive troubleshooting with Ascend to
try to fix it. We never knew why it got stable but it did. Here's what we
went through. I suggest you try it, as it works great for us now:

1. Clear non-volatile RAM. Do it whenever you update software:

fclear
Clears non-volatile RAM of configuration saved by tload.

fsave
Saves configuration to non-volatile RAM.

nvr
Clears non-volatile RAM and resets. If you've just uploaded new code via
tload, configuration was saved to flash RAM and will be retained.
Otherwise, configuration will be lost. Doing an nvr after tloading new code
is recommended.

2. Make _sure_ you have no duplicate routes. We found that we'd
inadvertantly assigned the same subnet to two clients, each handled by a
different Max talking OSPF to each other.

3. Turn off OSPF on unused interfaces. If your routers are talking to each
other over WAN lines, you don't need it running on your Ethernet port.

4. Run at least 5.0Ap16  on any 4000s. I have yet to try Ap20. Pre-1.3A
versions seemed fine on the TNT, and 1.3A is also stable for me. Again, I
have yet to try later versions.

I really hope this helps. I was in utter hell when my Maxen were rebooting
themselves. There's pretty much nothing worse in this business.

Peter Lalor
Infoasis
plalor@infoasis.com
http://www.infoasis.com/
415-459-7991 x102
415-459-7992 fax


++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>


Follow-Ups: