ERROR :Trying to reconnect too fast from new address

[temp]

Darren,
	In your general {} settings, there is 

	/* throttle time: the minimum amount of time between connections
from
	 * the same ip.  exempt {} blocks are excluded from this throttling.
	 * Offers protection against flooders who reconnect quickly.  
	 * Set to 0 to disable.
	 */
	throttle_time = 10;

Try playing with that, ... if you need a specific IP address or a specific
range to connect without going through the throttle_time, try adding an
exempt, I have my bopms, oomons, services, and other misc services all
exempt, cuz they try reconnecting too fast too.

/* exempt {}: IPs that are exempt from deny {} and Dlines. (OLD d:) */
exempt {
	ip = "192.168.0.0/16";
};

-----Original Message-----
From: hybrid-bounces at lists.ircd-hybrid.org
[mailto:hybrid-bounces at lists.ircd-hybrid.org] On Behalf Of Darren Spruell
Sent: Wednesday, February 02, 2005 1:59 PM
To: hybrid at lists.ircd-hybrid.org
Subject: ERROR :Trying to reconnect too fast from new address

We recently changed our network infrastructure to route us through a new 
translation point.

We are now seeing the error: "ERROR :Trying to reconnect too fast." when 
connecting to port 6667 on our Hybrid-7 server from NAT'd addresses. 
Addresses in another building and any public address on the Internet can 
connect to and use the ircd without any problems. For this reason we are 
considering this problem to be specific to the new address range. We've 
looked at our ircd-ipv4.conf and can't find anything that sticks out as 
for dlines, klines, classes allowing too few connections per IP, or 
anything. Increasing our debug level doesn't give us any more 
information in the log file. The NAT address is 64.58.235.2 and this is 
our definition for the users class:

class {
         name = "users";
         ping_time = 2 minutes;
         number_per_ip = 2000;
         max_number = 500;
         sendq = 10000 kbytes;
};

We don't believe that users are being placed in any other class than 
this; obviously we've jacked up the numbers trying to mess with it.

Any other suggestions on how we can figure out what is causing the error?

-- 
DS