Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Re: What is carrier-class?
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, 8 Nov 1997, Wade Williams wrote:
> I certainly understand that Cisco is not perfect, and I'd like to
> understand how you think we (or Ascend) can improve things to what you call
> carrier-class. If you can give me some feedback on that, I'll take it back
> to some of the guys at TAC to pass to the powers that be.
Certainly.
I've heard two excuses back from Ascend why things don't get fixed/get
broken:
1. This is leading edge technology.
2. There are too many possible combinations for us to find all the bugs
before we release software.
To address them both:
1. This is leading edge technology.
Our 7513 gave a lot of trouble during testing, refusing to swap RSPs
properly on hotswap - with hardly any config in it. This is hundreds of
thousands of dollars worth of equipment with minimal chance of any
conflict with anything else - with one card configured up with an IP
address. In the end, our reseller (a Gold partner) replaced the chassis.
What testing is done on the hardware to make sure it works before it
ships? A carrier-class vendor would have caught this problem before it got
to us.
We daily analyse RADIUS records, indexed by Max and cause code. We can
then pick out chassis' underperforming - many abnormal disconnects
compared to the rest. We see an extremely wide variation - even among
Maxes at the same POP and on the same switch card (yes, they're all
running the same software version, same build, same configuration).
A carrier-class vendor would've picked this up. There is very standard
equipment around to generate hundreds of calls to boxes - I imagine given
a little effort Ascend could even write something to drive a Max in
reverse to test against other boxes.
Ascend - just think. Ask nicely some of your largest customers for some of
their RADIUS data - I'm sure people like Jason and certainly myself would
gladly let you have a look since it'd improve the service. Find out how
your product performs in the field. And then, just think, how many fewer
"disconnects with cause 185" support calls you would have taken if you'd
done this earlier and fixed it....
Brand-name PC vendors have been doing this for years. Burn the stuff in,
*before* it ships. Even TV manufacturers do that, and I'm sure a lot more
TVs get sold than Ascend Maxes...
2. There are too many possible combinations...
Fine. Which is why Telcos have the resources to pay for model
environments. For instance, we have a model exchange, a model ATM node,
and a model POP. So we *can* test for things in our environment in a
consistant way before deploying them.
NEC give us a software release, which we test, find lots of bugs in,
document them all, and send back to NEC - which they fix. NEC trust us -
we trust them.
The point is - Ascend/Cisco take the commodity paradigm too far. You guys
treat all your customers like dummies. In fact, it's worse than that. A
few months ago, an Ascend engineer came in to demonstrate a system for us.
It didn't work. He declared it a bug. He had to reproduce the thing all
over again with new debug before *Ascend* would acknowledge it! Seems
Ascend doesn't trust even its own engineers. :(
We've been finding bugs in our platform for many months, which our
reseller has been escalating to Ascend. Our perception is, Ascend are the
black hole. Things get lost in there. Ascend say, "No, there is no
accounting problem in release p13." I show the guy some debug with
negative IP addresses. No response.
One of our Maxes won't take a hash code update. Ascend say I'm typing it
wrong. I triple check it - the box won't take it - difficult to type it
wrong if I cut and paste between xterms. I let an Ascend employee telnet
in on condition he tell me if there's any risk so I can move any customers
off. "No risk".
Two minutes later, my box is off the air. Permanently. It no longer
booted. It had to be replaced.
I must say here our local vendor I don't have a problem with - it's
Ascend. While access servers are complicated beasts, there's no excuse for
a human-complexity "take two aspirin and a new software release and call
me if it doesn't work in the morning" approach.
I understand this is a somewhat heretical view - but why not stop your
customers ringing with complaints by:
1. Treating them not only with politeness but also if they have an IQ
above 100. I was self-employed a couple of years ago. I won a lot of
business because I didn't treat people who didn't understand what they
were using as if they were stupid.
2. Listen to what they say. There is a problem here. Perhaps it's config -
perhaps it isn't. The attitude should be - fix it, don't point the finger.
3. Acknowledge their concerns - "that's bad." They're ringing you because
their business is going down the drain, and your box has something to do
with it. Give them some confidence in the product - *show* them it works
somewhere else.
4. Stop firefighting. I have worked at two ISPs where growth has been
phenominal. Companies growing at 15%/month. Customers signing up
1000/week. New staff being hired every other week.
Yes, it is difficult to manage growth. Yes, it is difficult to cope with
software versions. But not impossible and it's been done many times
before. We cannot get away with "but you get that on the Internet" any
longer.
- --
Josh Bailey (mailto:joshb@xtra.co.nz - GroupWise mailto:j6bw@telecom.co.nz)
Internet Network Specialist Voice (DDI): +64-9-355-5923
Telecom Internet Services Voice (Mob): +64-25-514-899
Extension: 93423 (Lvl. 4, 120 Mayoral Dve) Fax: +64-9-355-5260
Private Bag 92028, Auckland, NZ Pager: +64-26-114-448
PGP public key available at http://www.pgp.net/pgpnet/pks-commands.html
DISCLAIMER: Viewer discretion is advised.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQB1AwUBNGTT0/le+GEe9W4hAQE0agL9ED0HrzNtH3wZ7GS1fc+GNm0kXm+cBrdZ
pv/Bk1x0C4fPLdcXkOx90gHHhRdVCSjxtX0TvcyyVpkis2ucoG6kQtt2YDMHFAoL
hLMPeh3MAAyJSS1UY1mWW/tIjyd083Pr
=zGWm
-----END PGP SIGNATURE-----
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: