Re: (ASCEND) after so many logins.. max6000 causes problems

["Henry Smith, Jr" <hensj@ihs2000.com>]

This is an interesting opinion.  A question arises with this.

Our original upstream which handles our secondaries was recently 
purchased by OneMain and since then they have been having a problem 
where their files match.. but then a few days latter, do not.  It 
seems some of their system are correct, and others are not.. the end 
result produce the wrong secondaries to be the winner.  Sad but true.

Some of the IP's in the pool for the Max resolve, while others do 
not.  Could this be the cause?  I'll start checking my logs and 
comparing the assigned IP's and look them up to see if they resolve 
from our upstream..

Question is:  To avoid my secondary file from being screwed up, I 
disabled the secondary zone transfers and simple point the system 
back unto itself.  But the system itself obviously still has the 
secondary DNS as the upstream, as I merely wanted to protect the 
files from changing to incorrect information during the transfers. 
Does the max, or radius require the IP to resolve?  If so does it 
look solely at the primary DNS files or will it verify from the 
secondary DNS also?

Oh yeah.. and to answer the question.. yes.. I have 94 available pool 
addresses for the max.

>Umm. have you enuf assigned number in the pools??? ( I had this problem
>before)
>
>----- Original Message -----
>From: Henry Smith, Jr <hensj@ihs2000.com>
>To: <ascend-users@bungi.com>
>Sent: Wednesday, 12 January 2000 5:18 PM
>Subject: (ASCEND) after so many logins.. max6000 causes problems
>
>
>  >
>  >
>  > Having a bit of difficulty with our Max 6000.  It currently has 3 out
>  > of the 4  PRI's activated but once it reaches approximately 40
>  > customers dialed in..they get varied problems.  Most get
>  > 720_no_protocols_configured, but if there is a sudden surge of people
>  > receiving those.. the max will log you in.. but hang you up instantly.
>  >
>  > Once the usage goes down a bit.. everyone is fine.
>  >
>  >
>  > therefore logins
>  > ================
>  > 40 and below.. no problems  (zero!)
>  > 41 to 42/46  receive the 720_no_protocols_configured error
>  > while the 42-46 login attempts are processing, anyone after that...
>  > 47+ will logins but be disconnected immediately.  Even though logins
>  > 41-47 error out anyway..
>  >
>  > At first I though the problem may have been with the third pri.. but
>  > I would then have to believe that the problem would only happen at 46
>  > connected users (23 per PRI * 2), but its not.
>  >
>  > Looking at the configurations, the only thing that I noticed was that
>  > the time was an hour behind and the date was 1 day ahead.
>  >
>  > Any suggestions on what I should be looking for and/or how to correct
>  > this problem would be of great help.  This is really starting to
>  > annoy us and our users.  We originally believed it was our users,
>  > because we would walk them through deleting the dialer, dialup
>  > adapter and tcp/ip and then readd them all.  This would work every
>  > time!  No shit!..  But further analysis seems to be that we were
>  > merely delaying there next attempt the login. Doing these steps was
>  > not fixing the problem.. only delaying them on the phone.. leaving
>  > time for the max 6000 to go below 40 again.  >DUH<   but hey... it
>  > was an honest mistake.
>  >
>  > Again, any help desperately desired!
>  >
>  > TIA
>  > ++ 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>