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
hillman@talstar.com
> -----Original Message-----
> From: Josh Hillman [SMTP:admin-maillist@talstar.com]
> Sent: Monday, August 03, 1998 4:38 PM
> To: emerald@iea-software.com
> Subject: Re: Ascend Fatal Error and Calls OnLine
>
> > From: Albert Churba <Albert@dialisdn.com>
> > We have been battling some software load problems with our Ascend Max
> > products. When the Max reboots itself due to a fatal error, clients
that
> > were connected are denied access when they try and reconnect. This is
due
>
> > to having concurrency control turned on. How, if at all, can we force
the
>
> > 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
online.
> I've tried everything I can think of to fix this and nothing's worked,
so
> in a day or two, I'll reinstall 6.1.0 on the Max and see if that cures
it.
> We're having a modem problem with it also and everything that's going
wrong
> 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
turned
> 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
> hillman@talstar.com