Date: Thu, 7 Mar 1996 03:08:52 -0800 (PST) From: "Brian Litzinger" <brian@easy1.mediacity.com> To: gclarkii@neon.nwpros.com (Gary Clark II) Cc: freebsd-isp@freebsd.org Subject: Re: Ascend 400 & PRI Message-ID: <199603071108.DAA15361@MediaCity.com> In-Reply-To: <199603070343.VAA05472@neon.nwpros.com> from "Gary Clark II" at Mar 6, 96 09:43:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> We're in the process of getting an PRI installed here and I am looking
> for information on the best way to hook this up to my local ethernet.
> I've got all FreeBSD machines here and a Cisco 2501 router.
> Any ideas on which product? Ascend or Combinet?
> Gary Clark II (N5VMF) | Director of Operations | Good service at
(SHORT FORM)
Ascend pipeline 400s: 2B MLPPP session could only obtain 75% of the
expected throughput.
Technical support is very poor, if you can actually
get through to them.
Units are not field upgradable.
Combinet Everywhere 900: Do not support RADIUS or any other "standard"
remote user database facility.
Net Express 5000: Wonderful, Wonderful.
Not that expensive either.
(LONG FORM)
With regard to Ascend (Combinet & Net Express are later):
I ordered 2 Ascend pipeline 400s for connection to two PRIs. The
pipelines sure were pretty looking and had a nice VT100 configuration
manager.
Regretably they didn't actually work very well. The first time I
contacted customer support I was on hold for 45 minutes after which
I gave up. (the actual problem is described below)
Other attempts to contact technical support at ascend yielded similar
results.
I then went through the sales channel and got the Technical Support
Manager and told him of my misfortunate. His response, not wanting
to address the problem with the Ascends, was that he had records
that showed the average call was answered in 5 minutes. This in
itself surprised me but he seemed proud of it. I asked him what
the worst case wait was.
Apparently, the nice people who developed the phone system they use at
Ascend were nice enough to shield the poor managers at Ascend from
information like the worst case. And the TS manager replied that
his reports didn't include that information, but that it was no
where near 45 minutes. (apparently I was lying to him)
And believe it or not I still didn't get through to a TS person.
I went back to our sales person and announced if I didn't get through
to TS the units were going back. Shortly thereafter I was talking
to someone from Ascend technical support.
I explained the trouble with the units and they suggested I field
upgrade them to some experimental release of the firmware.
A fiasco ensued with trying to get them to actually put the
software on their ftp site but it did eventually happen.
Well, the uploads of the firmware failed, and the units went into a
loop wanting to upload the firmware. I tried everything they
recommended but the units refused to start working.
I even hooked up an RS232alyzer and watched every packet go acknowledged
correctly, but in the end, it was still in upload mode. I eventually
tried uploading the real release but it wouldn't upload either.
During my trials and tribulations in trying to upload the firmware
technical support made a statement that made no sense. I queried
the TS person on the statement and it was clear he didn't know what
he was talking about.
Finally Ascend said to send the units back to the factory and they
would upgrade the firmware. I told them that field upgradability
was an important feature and if I send the units back to the
factory it would mean that Pipeline 400s weren't field upgradable.
In the end, it was determined that contrary to their literature
the Pipeline 400s that I had were NOT field upgradable.
I returned the units and got a refund.
The problem, by the way, was one of performance. The Pipeline 400s
were unable to perform adequately on MLPPP 2B calls. That is they
were only able to attain 75% of the expected throughput.
100% throughput was obtained via a NetExpress 5000 in the same setup.
Regarding Combinet:
I bought 2 Combinet Everywhere 900s. As I do with all products I
opened the box they came in and took out the documentation and
read it all. (I know its hard to believe, but I really do).
When I finished with the manual it was clear that Combinet didn't
support RADIUS or any of the other "standard" remote user database.
They did have some proprietary scheme which required an machine
running Work Group for Windows to run the software and maintain the
database.
I contacted technical support at Combinet to confirm that I understood
the scheme. No troubles getting through and yes there stuff really
did work that way.
Well, I wrapped the manuals back up and put them back into the box and
returned the units. (note that I never took the combinets out of the
box. To this day I don't know that they look like).
In any case, a few weeks later I got a bill for $600 to replace the
broken bezel on one the units. I explained my story, and eventually
they gave up on the $600.
Regarding Net Express:
I bought an NE5000 with 2 PRI interfaces. (at the time an NE5000 could
handle 2 PRIs itself, I believe a single NE5000 now handles 4)
Nex Express was willing to match the prices offered to my by Ascend
and Combinet, so eventhough NE equipment looks horrendously priced
in their literature there solution was no more expensive than Ascend
or Combinet after negiotiating with them.
And boy what a difference in support!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
They insisted on sending an FSE (field service engineer) out to my
site to give my an overview of the units operationn and to help me
set it up. At first I figured that meant the thing was impossible
to manage. But after the course it was clear that the system was
reasonably straight forward. Ascend's menuing system is nicer, but
the NE actually works well.
After getting the unit setup things went well, and I had no trouble
getting through to NE technical support when I needed to. In fact,
I don't believe I have ever been put on hold by them.
A few weeks later I did a field upgrade of the unit to the next release
of the firmware. It took about 5 minutes and I didn't even have to
re-enter my config info. The whole upgrade went hitch free.
We started having problems with customers using 3COMs Impact's having
their 2B channel MLPPP sessions die under heavy loads. NE took about
3 weeks and was able to determine that the problem was a bug in the 3COM
firmware (which is still there in 2.02beta). 3COM acknowledged the bug,
and NE kept us appraised of the situation as they worked on it,
including a nice report describing the problem.
--
Brian Litzinger Powered by FreeBSD
<brian@mediacity.com> http[s]://www.mpress.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603071108.DAA15361>