Re: (ASCEND) Re[2]: 4.6Dp3 for MAX Classic

To: RBoozer@symantec.com (Ray Boozer), Ascend User-Group <ascend-users@bungi.com>, MMedwid@symantec.com (Michael Medwid)
Subject: Re: (ASCEND) Re[2]: 4.6Dp3 for MAX Classic
From: Kevin Smith <kevin@ascend.com>
Date: Wed, 07 May 1997 15:19:29 -0700
Cc: NMarshall@symantec.com (Nicole Marshall)
In-Reply-To: <0000C280.3152@symantec.com>
Sender: owner-ascend-users@max.bungi.com

At 07:15 PM 5/6/97 -0700, Ray Boozer wrote:
>     I wanted to get some clarification on TR 1898: When our 4004 would 
>     have its PCAnywhere seizure or that's what it appeared to be, the few 
>     ISDN users that had been connected were still active and never 
>     dropped, furthermore my digital modem call and a colleague's 
>     connections remained active we both could access other IP devices on 
>     the network. Telnet to the 4004 failed and attempts to place video 
>     calls also. Once the 4004 finished gagging I ran a telnet session to 
>     look at the up-time it wasn't reset the "meter" was still running. I 
>     have seen the 1600's completely go off-line to where all is reset 
>     including the PRI's and up timer is at zero (simulated power failure). 

OK, as I understand it there were at least 2 different effects caused by the
PCAW related bug. The above observations are the two that I was familiar with.

The 1600 has been reported as resetting, and just freezing...so I suspect the
actual effect was also dependent on the configuration and environment that the
unit was being used in. 

I believe that the main reason that there was a significant difference between
the effect on the 1600 and on the 400X is due to architecture and processor
load differences. I do not have the insight to go further than that though.

>     For me it is hard to grasp that an application like PCA can cause 
>     this, also I'm clue less to what portion of the MAX is resetting. It 

I believe that the main problem was that the application caused the MAX to try
connecting to all configured remote sites simultaneously,(to forward ARP
requests
on all inactive interfaces) and it didn't handle this load on NVRAM access.

This problem does not exist in the "i" branch.

Kevin Smith                              Updated Service and Support
Ascend Communications                    Resources are now at:
                                         http://www.ascend.com/service
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.shore.net/~dreaming/ascend-faq>
or		<ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>

References:

(ASCEND) Re[2]: 4.6Dp3 for MAX Classic

From: RBoozer@symantec.com (Ray Boozer)

Prev by Date: (ASCEND) Autentication after network down
Next by Date: Re: (ASCEND) message in debug
Prev by thread: (ASCEND) Re[2]: 4.6Dp3 for MAX Classic
Next by thread: (ASCEND) Single login (fwd)
Index(es):
- Main
- Thread