Re: (ASCEND) Disconnect Cause 101 but radif shows Ack - MAJOR problem

[Tony Ray <tony@turbonet.com>]

I have multiple pools and have verified that addresses are given out of
pool 2 when pool 1 is used up.  Just make sure that you are not
specifying a pool in your radius.

--Tony 

Dave Joyce wrote:
> 
> I'm not sure why they have multiple pools, hidden deep in the documentation
> somewhere it read that IP addresses are only given out of Pool 1 when using
> radius!!! I too wanted to subdivide the IP ranges but instead of running
> 'radif' run 'addrpool' it shows that after pool 1 has depleted it's count
> then calls are dropped.
> 
> If there is a work around please post it because 28 IP addresses is a
> terrible thing to waste on a 96 modem box.
> 
> Dave Joyce
> Internet Manager
> RTC on Line
> 219-223-0228
> FAX 219-223-4898
> 
> ----- Original Message -----
> From: <ascend@digistar.com>
> To: Oystein Homelien <oystein@homelien.no>
> Cc: <ascend-users@bungi.com>
> Sent: Thursday, November 04, 1999 11:09 PM
> Subject: Re: (ASCEND) Disconnect Cause 101 but radif shows Ack - MAJOR
> problem
> 
> > On Wed, 3 Nov 1999 ascend@digistar.com wrote:
> >
> > > The MAX seems to "normalize" a bit if I only have one WAN pool.  With
> > > three WAN pools the problem appears HORRIBLY.  This sounds like
> > > another fscking bug.
> >
> >
> >
> > Seems that by using only a single (large and wasteful) WAN pool the
> > problems have disappeared.  My goal was to have a /27, a /28 and a /29 to
> > provide 50 IPs to a 48-line MAX 4048.  This, however, doesn't seem to be a
> > viable option because doing so causes the MAX to flake out.  Now, I'm
> > stuck devoting a /26 (64 IPs) to a 48-line unit.
> >
> >
> > Is this a known issue?  Surely i'm not the first person to discover this
> > problem.
> >
> >
> > Next question...  did it ever get fixed?  If so, what release fixed it?
> >
> >
> >
> > thanks!
> >
> >
> >
> >
> > > On Sun, 31 Oct 1999, Oystein Homelien wrote:
> > >
> > > > We're also seeing the exact same problem.  Max TNT talking to a
> > > > proprietary radius server.  (developed in-house).  We get cause 101.
> Does
> > > > the TNT check if a user is already logged in?  Why?  How do we turn
> that
> > > > off?
> > > >
> > > > >
> > > > > I am plagued by a problem that is causing serious grief.
> > > > >
> > > > >
> > > > > At times of high activity users are being disconnected after the
> radius
> > > > > server authenticates the user.  The radif radius debug shows the
> user
> > > > > entered the correct password and "Authentication Ack" but the radius
> > > > > detail file shows Disconnect Cause 101.
> > > > >
> > > > > At slower call volumes the disconnect problem disappears.
> > > > >
> > > > > Below is my DEFAULT user:
> > > > >
> > > > >
> > > > > DEFAULT Password = "UNIX"
> > > > >         User-Service=Framed-User,
> > > > >         Framed-Protocol=PPP,
> > > > >         Ascend-Maximum-Channels=1
> > > > >
> > > > > I am using FreeBSD 3.1 and have tried numerous radius servers, old
> and new
> > > > > ascendd, the livingston radius and cistrond - all show successful
> > > > > authentication in the radius log and in -x debug mode but the 4048
> boots
> > > > > the user off and displays "LAN security error".  I have Auth Pool =
> Yes.
> > > > > I have no connectivity issues or authentication timeout problems
> that I
> > > > > can see.  Ping times to the radius server are under 10ms.
> > > > >
> > > > >
> > > > > The max 4048s are all running 6.1.7, newer versions seemed to be
> worse.
> > > > >
> > > > >
> > > > > What is even more odd is three other 4048s (same software, etc) do
> not
> > > > > experience this problem at all, ever.  The problem is related to
> three
> > > > > individual units.
> > > > >
> > > > >
> > > > > I have tried everything I can think of to remedy the problem (nvram
> clear,
> > > > > etc.) but nothing seems to make a difference.
> > > > >
> > > > >
> > > > > Anyone got any ideas?
> > > > >
> > > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > ++ Ascend Users Mailing List ++
> > > > > To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> > > > > To get FAQ'd: <http://www.nealis.net/ascend/faq>
> > > > >
> > > >
> > > > Oystein Homelien                  |  oystein@powertech.no
> > > > PowerTech Information Systems AS  |  http://www.powertech.no/
> > > > Nedre Slottsgate 5, N-0157 OSLO   |  tel: +47-23-010-010, fax:
> +47-2220-0333
> > > >
> > >
> > >
> > > --
> > >
> > >       /
> > >   /  o     Jason Buchanan
> > >  o         Digistar Microsystems
> > >        /   jsb@digistar.com
> > >       o    http://www.digistar.com/~jsb/
> > >
> > > ++ Ascend Users Mailing List ++
> > > To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
> > > To get FAQ'd: <http://www.nealis.net/ascend/faq>
> > >
> >
> >
> > --
> >
> >       /
> >   /  o     Jason Buchanan
> >  o         Digistar Microsystems
> >        /   jsb@digistar.com
> >       o    http://www.digistar.com/~jsb/
> >
> > ++ 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>