Re: Ascend Fatal Error and Calls OnLine

Josh Hillman ( (no email) )
Wed, 5 Aug 1998 11:25:37 -0400

> From: Albert Churba <Albert@dialisdn.com>
> 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.

Radius 2.5 works much better than the previous versions. What I did was
uninstall RadiusNT (whatever version was out prior to 2.5) and install 2.5
on our backup radius server. After testing it out for a few days
(successfuly), I pointed our Maxes to it for a little while and switched
over to 2.5 on the main radius server, then went back into the Maxes and
mixed the radius server IPs again. I haven't had a single problem with 2.5
that I can think of (ODBC mode with MSSQL 6.5, running as a service).

> 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.

With the exception of dial-outs, we do some similar stuff and have 7 class
Cs coming in here. All we had to do in the Maxes (and a couple Pipeline
50s) was set up "Ethernet / Static Rtes" in each of the Maxes (not using
RIP or anything).

> RIP was killing our Cisco 3640 router
> bringing it to 90%+ utilization.

I think we had RIP running temporarily, but brought it down because of some
kind or quirk with our Cisco 2501 (maintained and owned by Sprint, our
upstream provider). It's since been replaced by a newer model with more
memory in it and a newer OS, so I have no idea if there'd still be a
problem or not.

> 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 kind of problems are you running into with stacking? I just enabled
it a week and a half ago but only played with MP (using modems) one time,
so I don't know if we're experiencing any problems or not. None of our
customers know that we have the ability to MP, so I'm not losing too much
sleep over it at the moment.

> What do you
> have Proxy mode (Ethernet/Mod Config/Ether Options/Proxy Mode set to?

"Always"

> How are you configuring your Pools

We're letting the Maxes handle that stuff (Ethernet / Mod Config / Wan
options). In each of our 3 maxes (4004, 4048, 4002) we have 48 modems and
I gave each Max one IP pool containing 50 IPs (50 instead of 48 just to
make counting easy on our part). All regular PPP accounts are assigned
these addresses (people with dedicated IPs are in one or two other
subnets):
max 1: 11 - 60
max 2: 61 - 110
max 3: 111 - 160

> 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).

The only IP-related radius attributes that (a few of) our customers have is

Framed-Address = (some IP)
Framed-Netmask = 255.255.255.255
for dedicated IP connections.

> 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

After upgrading our Maxes from 5.0Ap42? to 6.0.0, we had problems with IP
address leaks. For a while, I kept increasing the IP pool sizes to
accomodate the problem (there were times that it thought we had 62 IPs in
use when there were only 40something people even online on a single Max
(only 48 modems to begin with on there). I contacted Ascend about this and
they said that there's been that problem for a long time and that one
setting needed to be changed in the Maxes to fix it:
Ethernet / Mod config / Auth
Auth pool = No (ours were set to Yes)
After changing this and resetting the Maxes ("fsave..." then "fclear", then
"nvr") we haven't seen the problem since.

Now, if I could figure out why our first max seems to periodically skip
STOP records, I'd be really happy :)

Josh Hillman
hillman@talstar.com

> -----Original Message-----
> From: Josh Hillman [SMTP:admin-maillist@talstar.com]
> Sent: Monday, August 03, 1998 6:20 PM
> To: emerald@iea-software.com
> Subject: Re: Ascend Fatal Error and Calls OnLine
>
> > From: Albert Churba <Albert@dialisdn.com>
> > 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
> Fatal
> > Errors, I'll have to give up the channels. The proposed fix is a few
> weeks
> > 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
> 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