RE: Ascend Fatal Error and Calls OnLine

Albert Churba ( )
Mon, 3 Aug 1998 18:58:57 -0400

I'm running the older RadiusNT and have been reluctant to make the change.
We are always busy and I'm tired of working at 4:00AM. I guess I'll have to
take the plunge.

I need to use some form of routing protocol since I do dial-out, dial-in,
and permconn connections across all the Max's. What I found was users from
one Max could not route to another Max on the physical Ethernet or WAN. I
also run two remote locations so a routing protocol also helped the overall
routing tables across the LAN & Wan. When I accept a call on one box and
dialout on another the weighed outdial has to know where it is to dial out
from, hence the static route. RIP was killing our Cisco 3640 router
bringing it to 90%+ utilization. OSPF fixed the CPU overload and brought it
under control to 7~10% average. I've been having problems with stacking
since 5.0Ap13 on up. They said 5.0Ap51 works, yet that puts me back to
kFlex and not v.90 and kills the Shotgun functionality too. What do you
have Proxy mode (Ethernet/Mod Config/Ether Options/Proxy Mode set to? How
are you configuring your Pools, we use RadiusNT (pools-MAX?), and create
summary info (also still wrote /32 routes on the RIP updates even with
static Cisco routes 192.168.64/26 - Defined Pool 1 192.168.65 62). I think
there are memory leaks with only 62 channels utilized:
Diag mode: > pools -v
Validating free lists...
0 errors; 779 buffers; 889184 bytes memory free

I could go on forever...


-----Original Message-----
From: Josh Hillman []
Sent: Monday, August 03, 1998 6:20 PM
Subject: Re: Ascend Fatal Error and Calls OnLine

> From: Albert Churba <>
> I've been reluctant to turn off concurrency control. But if that is the
> only option until Ascend fixes the stacking issue, their claim to the
> Errors, I'll have to give up the channels. The proposed fix is a few
> away, so they say. Are you running RIP or OSPF?

I don't know if there are any problems with stacking or not. I turned it
on on our Maxes about a week and half ago so I could re-enable MP across
the Maxes. I was going to turn off stacking on the Max that we're having
these problems with to see if there's any corelation, but I forgot about
it. Considering the other Maxes are using the same OS, I'd imagine that
they too would be having problems if stacking was an issue. So far, only
this one Max has been having problems, so I don't think stacking is the
problem here--I think the OS got screwed up and needs to be reinstalled OR
the Max is physically damaged in some way (from the brownouts).
I had no desire to turn off concurrency control either, but I had less of a
desire to watch people log in and kill non-existent connections when I'd
see an "Over Login Limit" pop up. I have no idea what's causing your FEs
though. Luckily, none of our Maxes have ever had one of those...
I'm not using RIP or OSPF.

Josh Hillman

> -----Original Message-----
> From: Josh Hillman []
> Sent: Monday, August 03, 1998 4:38 PM
> To:
> Subject: Re: Ascend Fatal Error and Calls OnLine
> > From: Albert Churba <>
> > We have been battling some software load problems with our Ascend Max
> > products. When the Max reboots itself due to a fatal error, clients
> > were connected are denied access when they try and reconnect. This is
> > to having concurrency control turned on. How, if at all, can we force
> > calls online to clear when the Max reboots itself? Currently we have to
> > manually clear the calls online when this happens. When this problem
> occurs
> > during non-business hours we get into trouble. Can you help please.
> > 6.1.3 ftik.m40 OSPF & Stacking enabled
> I'm using 6.1.0 ftk.m40 (stacking enabled) on our Maxes and haven't run
> into any OS-specific problems that I'm aware of (no Fatal Errors or
> anything). Unfortunately though, as of last week, one of our Maxes seems
> to occasionally have a problem not sending out stop records. Because we
> also use Concurrency Control/Variable Login Limits, some of our users
> haven't been able to get in because the system thinks they're still
> I've tried everything I can think of to fix this and nothing's worked,
> in a day or two, I'll reinstall 6.1.0 on the Max and see if that cures
> We're having a modem problem with it also and everything that's going
> has been doing so since some power fluctuations last week due to storms
> here (UPS is being replaced).
> As far as the concurrency problem goes, I got tired of babysitting the
> system after a few days (manually clearing out a record here and there in
> Emerald's Online tab) and this morning went into RadiusNT Admin and
> off Concurrency Control, stopped Radius, and restarted it. It's not a
> cure, but at least for the time being, it's a work-around that's keeping
> the customers happy.
> For what it's worth, I'm using RadiusNT 2.5.105 on NT4 with SQL Server
> 6.5...
> Josh Hillman