Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>