<div dir="ltr"><div><div>Thanks Robbie for the inputs.. the load should not have been high as I have around 4000 clients with 160 users which should be manageable </div>However, I saw a lot of clock skew too great errors in my krb5kdc.log... however I haven't been able to verify if those were genuine... </div>Can too many clock skew errors take down the kerberos service.. </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Sep 19, 2016 at 10:15 PM, Robbie Harwood <<a href="mailto:rharwood@redhat.com" target="_blank">rharwood@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rakesh Rajasekharan <<a href="mailto:rakesh.rajasekharan@gmail.com">rakesh.rajasekharan@gmail.com</a>> writes: > On Mon, Sep 12, 2016 at 10:13 AM, Rakesh Rajasekharan > <<a href="mailto:rakesh.rajasekharan@gmail.com">rakesh.rajasekharan@gmail.com</a> <mailto:<a href="mailto:rakesh.rajasekharan@gmail.com">rakesh.rajasekharan@gmail.com</a>>> > wrote: > > sorry I guess I did not put the question correctly.... > > I wanted to know .. like we have the ListenBacklog for apache to > basically define the number of connections it can handle.. do we > have some thing similar for our krb5kdc service.. as the SYN floodin > at 88 looks like krb5kdc service is not able to handle sudden spurt > in connections or the number of connections are more than it could > handle.. > > So, would be great if I could know how many connection it can > support at any given time ..most of the times I see this error while > i add clients to IPA master.. so if thers a known limit , I could > first check netstat to see how many connections I have at any point > and if its below the limit only then setup ipa-client-install We intentionally do not have such a parameter in krb5. We call listen(5) internally, but please note this is probably not the parameter you want to be able to tune. The listen() backlog is the number of connections that are waiting to be accept()ed by the process. They sit in the kernel, not receiving SYNACK. This number does not count connections that the process - here krb5kdc - has accept()ed and is currently processing. If you're truly seeing connections faster than they can be accept()ed, you have a load problem that tuning this parameter likely won't fix. You should probably configure replicas: krb5 will fall back if the connection is refused from one kdc to the next configured one. This will result in faster operation for your users than waiting on an enormous listen() backlog will as well. A tunable for the listen value may be added in the future, but is not available at the present time. </blockquote></div> </div>