Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Urgent TNT problem
Most likely you haven't seen the problem because your not fully loading
up your boxes, See, in the ISP world we have no money and have to squeeze
out every available port we can get for the buck, so we LOAD THEM UP with
PRI's and watch them. I'm 100% postive it's a load issue. But what's weird
is when the box is exhibiting the problem, everything looks good from
the inside, It's as if eth0 was renamed /dev/null.
I've emailed my TAC support about this on Sunday, but I haven't recieved
a response yet as to what they believe the problem to be, I guess I'll
email again :(
Jason Nealis
Director Internet Operations / Network Access
Erols Internet
On Mon, 13 Apr 1998 Mitchell.Arnone@occ.treas.gov wrote:
> I am concerned about this report because I have two TNTs in a shelf configuration which provide all the remote access needs for an entire federal organization. I have been running these boxes since September 97 but never experienced the outages describ
ed in this way. I have run 1.3ap6, 1.3ap24 and now am running 2.0. At 2.0, my TNT has been running for almost 20 days without missing a beat. Prior to that It was running appx 14 days but I had to reboot to rebuild routing tables due to routing corrupt
ion (not caused by the TNT).
>
> I have each of my TNTs configured with one 4/100mb ethernet card one eight-port T-1(PRI) card, ISDN signalling and three 48-port K56flex cards. I have a total of 11 PRI circuits distributed between the two TNTs and am load balancing using both 100mb et
hernet ports connected to separate and unique segments on a Bay Networks BCN router (both 100mb ethernet port configured as a default gateway) plus one of my 10mb ports connected to a separate segement for RADIUS authentication with a static route defined
to route all packets destined for a specific IP address. I am using OSPF to maintain my routing tables. I have over 2000 remote users plus close to 18 remote LANs over ISDN (with many more on the way). I average appx 2400 calls each day (maybe more) b
ut my high water mark for simultaneous sessions is around 90.
>
> I am assuming those of you who have experienced this problem see a much higher load on your TNTs. Could this be a load issue? If so, I wonder where the breakdown begins. Loss of this device for any period of time would spell significant problems for
many of our staff.
>
> Mitch
> Semper Fi
> ---------- Original Text ----------
>
> From: Mickey Coggins <mick@iprolink.ch>, on 4/13/98 2:35 PM:
>
> > I have the same problem, The TNT will drop off the net and only return
> > for a couple of seconds etc.. My Opinion it's either the poorly engineered
> > Half Duplex Ethernet card or it's some sort of internal routing issue.
> > This is something Ascend has to fix and I don't think the problem is on
> > your side.
>
> ...
>
> > > The 10 shelfs running 1.3Ap24 has today all stopped communicating on
> alle
> > > interfaces (looks like) except for some small 10 sec periods (ping
> alive)
> > > once per abt. 5 minutes.
>
> ...
>
> > > After another reboot, the problem has gone !!
>
> I've got the same problem on 1.3Ap24. I tested 2.0 and it also had this
> problem. I even switched TNTs under the wrong assumption that it might
> be hardware. Of course, when this hang happens, I don't have the time to do
> much debugging, so I just pop the box. We can usually run about 3 days
> between reboots. Is this expected uptime for a TNT? Anyone have any
> idea how I can get it to run for at least a week without a reboot?
>
> Thanks,
> Mickey
>
> ++ 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>
>
++ 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: