A performance issue we have seen has to do when a KDC has a heavy load and cannot provide a response within 1 sec. The Kerberos client libraries apparently expect a response within a sec and if they don't get it they move on to the next KDC in the list for the realm and so on for both udp and tcp packets. Packet sniffing has shown a KDC to send a response in 1.03 seconds however the client has already shut down listening for that UDP response and is waiting for a response from the next KDC on the list. So loads just get worse on all KDCs. Curious why there is not some configuration parameter at least for TCP connections that allows for a longer wait time for a response.
This is really a problem when the Kerberos password is a one time use password. The first KDC provides back a TGT on the "first" request but in 1.03 seconds, however the client ignores the response. Now when the second KDC gets the request, it rejects it because the "password" is no longer valid. Glenn On 9/25/12 2:34 PM, Jack Neely wrote: > Greetings, > > Has anyone done any rate limiting or throttling of Kerberos requests? > I've had several situations where I had a load of 600 requests / minute > against my 3 kerberos slaves that caused degradation of performance for > everyone else. Always from misbehaving tools or applications. > > What suggestions do folks have for doing this? I've thought about using > the limit module in iptables: > > iptables -A INPUT -p tcp --dport 88 -m limit --limit 4/min --limit-burst > 6 -j ACCEPT > iptables -A INPUT p tcp --dport 88 -j DROP > > Jack > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
