Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Ascend going mad ? (was: Stable code for Max 1800)
Hi,
now it is not the first day trashed with an Ascend problem for me, but
what I heard back from EMEA support on one of the most esoteric
problems with Max1800s really shocked me. It is ignorance at its best,
and it finally gave me back the feeling that reporting bugs to the TAC
is ABSOLUTELY USELESS because nobody cares about them. Note that I was
currently developing the impression that this feeling might be wrong.
Short review:
On Thu, Apr 09, 1998 at 10:42:55AM +0200, Andre Beck wrote:
>
> Any chance that this load may have a fix for the most penetrant problem
> we ever had with 1800s, the (supposed) BRI-out-of-sync problem ? It
> happens when you heavily load a 1800 with BRI connections (starting at
> 6, better full loaded) which go to independend networks (like different
> telcos, different PBXs/PBX slots or independend leased lines). It appears
> that the 1800 uses _one_ BRI as clock source and gets out of sync if other
> BRIs have remarkable swimming away clocks on other BRIs. This causes massive
> packet loss with all upper layer protocols (ping measures show up to 50%
> lost packets). The problem disappears (on upper layers) when PPP link
> compression is disabled, but this is just an observation, no solution.
>
> We have a call open with EMEA support currently (again) because we now
> have a Max1800 where the problem can be seen (it has the bad property
> of showing only up in RW environments, not in the lab and not if an
> Ascend support guy is looking onto it, but in this case we _captured_
> it finally). Hopefully this is now escalated - this problem is known for
> ages now (more than a year if not two) and was never fixed. But it _kills_
> us because the customer whos network deteriorates totally since we sold
> him a one-1800-for-two-pipe400-replacement makes _us_ responsible for the
> problem and we cannot fix it...
A bit more history: We are seeing this since the first 1800 we were
trying to install replacing two P400s. We have made _countless_ bug
reports about this issue, the only response beeing "we don't see this",
"nobody else has this problem" and the omnipresent "install X.YZpP" with
X,Y,Z and P beeing the bleeding edge version available at the time
the "answer" came. We finally got Ascend to recognize that there MAY
be something and they told us "when you see this error next, make a new
TR and our engineers will have a look on it". Now that we indeed were
struggled by the problem again (more exactly, a customer of us which runs
a production network) we again reported this problem. We made a date with
the customer and the technical supplier of the customers network, reserved
two hours of maintenacne time there (cost us some bucks btw) and dated
a hands-on session with EMEA support. Just for you to remember: The BUG
appears when you fully load a 1800 with BRIs going to different sources
and causes extreme packet loss making the network unusable. The packet
loss disappears magically if you set Link Comp=None, but the customer
REQUIRES Stac compression because the network is mainly transporting
database queries and responses and becomes unusable slow without Stac.
It is a temporary solution to switch of Stac and at least prevent the
packet loss, but we want this bug fixed. OF COURSE did we write all of
this DETAILED into our bug report conversation with TAC, MORE than once.
Now on the date we were a bit surprised that the support did not do
much more than going to debug mode and getting some pools dumps (we would
have done this ourselfs) and was only hard to convince that he should
go to TermServ, ping a destination and the 50% packet loss IS A PROBLEM
actually. This became a two hours conversation on the phone whith
essentially no new information but the stuff we already reported by
EMail anyway (actually I expected an Ascend engineer to physically move
to the customer site and diagnose the problem as well as the circumstances
at the site that may cause it, with all the nifty tech like BRI monitors,
but I now realize I'm just DREAMING).
However, I still had the hope that the problem was _finally_ escalated and
Ascend engineering will come up with a FIX to it and not hot air bubbles.
But what we received yesterday was that:
------------------------ snip ----------------------------------------
Hello,
In telecommuting and Internet access applications there are frequent
situations where large
amounts of uncompressed text (e.g. Web pages, regular text documents,
e-mail, etc.) need
to be transferred from a remote server. Because regular text files are
highly compressible users
may want to purchase the compression option because they have the
potential to double, triple,
or even quadruple the throughput of their ISDN line.
In your configuration it seems that you're not transferring such kind of
files. So I highly
recommend you to turn off the stac compression in your configuration.
Have a nice day,
...
---------------------- snap ------------------------------------------
HELL !
Should this be a cynical joke or what ? We don't need tips about how
compression works or to switch it off ! The customer bought this damn
box because it CAN DO STAC and HE NEEDS IT and if the 1800 breaks under
certain conditions KNOWN TO ASCEND they have to FIX IT or _finally_
tell us the TRUTH.
To my impression, the TRUTH is that the 1800 has a HARDWARE FLAW in that
it CANNOT sync BRIs independantly and thus WILL ALWAYS SUFFER from
situations where it is fully loaded with BRIs from different sources.
This is a BUG and cannot be fixed with software so they circumcloud it
and pretent it would not exist just to FOOL the customer. But believe
me, we are not fooled easyly like a dumb average windows luser, we
are no analphabets either and we really dont like it if someone makes
jokes on our cost.
Ok, I'll calm down now. My last hope is that my wording above may have
convinced Ascend that it's time now to come up with a real solution for
this oddity. But I'm not really sure. We've sold Ascend gear since day
one here in Germany (starting 94) and use it ourself for large parts of
our infrastructure. Maybe it's finally time to choose something new. I
hate it if the boxes I try to base my job on are generally called
"Ätzend" around here in Germany (that means Acid), and the BinTec BRICKs
are looking nicer and nicer every day that Ascend stays on the path it has
choosen to go in the last years. I used to be an Ascend advocate actually
and like to pronounce that Cisco, Bay etc. pp. are all cooking with water
as well. I'm not easily shocked. But as said, that one trashed my day.
Sorry for the whining again, but I felt it was finally time for this to
be said.
Back to constructive criticism,
Andre.
--
Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) AB10-RIPE XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ 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:
References: