Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) update on *4004 strange problem*
I had a problem with my Max 4004 about a year ago where the max would
start refusing calls at about 13 or so channels. Those folks that were
already connected were ok, but if they hung up, they couldn't get back
in. I had
a strong suspicion that it was a T1 problem, but the Bell folks looked
at it at length from their CO, and again onsite. I was still conviced
that it was a T1 problem, but I was wrong. I noticed that the menus on
the max were sluggish, and looked at the segment (for the 50th time)
with a sniffer and it looked ok. I did have some multicast traffic
coming from my LAN, but it didn't seem to be that high. I decided to
filter the mulicast data on my 3Com router as a test. I filtered all
the unnecessary broadcast/multicast traffic and voila, it started
working great. Since the max had to forward all the broadcast traffic
to the attached stations, it could only keep up with it for a few
systems (13 or so in my case), and then he would run out of buffer space
and would refuse any new calls from then on. I don't know if this will
help you or not, but the slow telnet response was the clue on mine. My
broadcasts on the segment were less than 1% of the ethernet, so it
doesn't take much. Needless to say, we filter as much as possible, on
that segment. We do all of our filtering on the 3Com Netbuilder II
router instead of the Max so we can save processor horsepower on the
Max. My users voiced unsolicited comments on 'increased performance'
after doing the filters. If you can, put the Max on it's own segment on
a router (3Com, Bay, Cisco, etc.) so you can easily filter and control
broadcasts without taxing the Max processor.
S. Anton
Manfred Kwiatkowski wrote:
> Luke Parrish <lparrish@iAmerica.net> writes
> >
> > Well, ended buying a new MAX 4004, and getting it delta dashed to
> the POP.
> > Plugged it in configured it, all 4 PRI came up just fine. Today
> about 11:00
> > am, box stops taking calls. I telnet to it, and it is too slow even
> move
> > around in though the ethernet. I am talking 1800ms pings from its
> local
> > ethernet segment. Other devices plugged into that catalyst are
> working just
> > fine.
> >
> > The console is even slow, to slow to even work with. Of course if we
> unplug
> > the ethernet it goes back to normal...
> >
> > For some reason i just get the feeling that someone is playing with
> us...
>
> Well I would deploy a hub and network monitor to analyse what is
> really
> going on at this port. Are you running RIP? Having a MAX listen to
> more than a default route is no good idea in terms of performance.
> And if something goes wrong (e.g. some misconfigured workstations
> start
> to do poisoned reverse) a MAX is likely the one to suffer from it.
>
> --
> Manfred Kwiatkowski, ZRZ (Zentraleinrichtung Rechenzentrum), Sekr.: EN
> 50,
> Technische Universitaet Berlin, Einsteinufer 17, D-10587 Berlin,
> GERMANY.
> INTERNET: kwiatkowski@zrz.TU-Berlin.DE phone: +49 30 314
> 24355
> X.400: s=kwiatkowski ou=zrz p=tu-berlin a=d400 c=de fax: +49 30 314
> 21060
> ++ Ascend Users Mailing List ++
> To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> To get FAQ'd: <http://www.nealis.net/ascend/faq>
++ 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: