Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Maturity or Second Childhood
>Now Cisco has seen the light and is coming out with an device which
>promises to have the scalability that the GRF does. But realistically, it
>will be a year or more before it has the maturity of the GRF.
>Matt Holdrege http://www.ascend.com matt@ascend.com
I have not observed that the maturity of an Ascend product has any
bearing on stability or reliable operation. In fact, our mature
Ascend routers are the only unreliable components in our operation,
while our Cisco products (like the new AS5200 we received from among
the very earliest release which has worked flawlessly).
Here's an example (ticket #162005). Before writing to the list I took
Matt's advice and sent in a request for technical support. We're running
two Maxes -- release 5.0Ap27 is loaded in both. After 2-5 days, the
Maxes stop acccepting any incoming calls and cannot make outgoing calls
successfully. We have to reboot. There's no obvious way to detect the
condition until someone complains. At first, the engineer indicated that
nobody had reported such a problem before, and suggested that we use the
debug facility and look at radif and the wan debug information. We observed
that the Max never made any requests for radius authentication (the server
was still running). The engineer indicated that the wan packet dump didn't
show anything useful.
However, one engineer today said that he had seen this same problem (then why
isn't it in a database somewhere so the other engineers know about it?) and
suggested we turn off proxying. Why? He didn't have a reason -- he just
thought it might have been related. (In fact we plan to do this anyway -
but the engineer turned it off without any warning, so all our isdn routes
were lost to our backbone router. This is not a trivial change to be
made in the middle of the day).
This is very typical of the tech support we've received from Ascend. They
have us "try" things that often don't seem to have any relation to the problem
at hand. On three different occasions, these attempts to solve problems have
resulted in much more serious disruptions of service while the Ascend engineer
messed with our routers.
As another example, we wanted to merge our two Maxes so all the profiles
would work interchangeably. The documentation wasn't just unclear -- it's
virtually non-existent. So we waited for assistance from Ascend (and thanks
to Matt, after about 3 weeks somebody was prompted to get back to us). We
were assured that we could make the transition smoothly, without disrupting
our normal services. For the next four days, we had major periods of
instability while the engineer assisting us had us try one thing, then
another. For example, he had us set Ascend-ppp-address a certain way for
every profile. When that broke things, he had us set it another way. Finally
he determined that the function changed after a certain release and we should
try yet something different. This should have been a very straightforward
operation -- surely other people are running more than one Max. Apparently
nobody has tried it at Ascend (if they have, then why didn't they share
their knowledge with us in the first place?).
I know that the engineers were sincerely trying to help to the best of their
abilities. But Ascend doesn't seem to have much regard for the quality of
service we have to provide while trying to debug their "mature" hardware.
At this point I have much more faith in a brand-new Cisco product than a
mature Ascend product.
Incidentally, Cisco has a web page that lists every test they perform for
every software release, major or minor, that's very informative. Maybe the
Ascend quality control people should look at it.
Mike Berger
Shouting Ground Technologies, Inc.
++ 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: