full socket buffers

[Mirek Lauš]

On Fri, Feb 11, 2011 at 4:25 PM, Friesen, Don SSBC:EX
<Don.Friesen at gov.bc.ca> wrote:
>
>>Snooping/storing traffic would cause high disk I/O and probable influence
>>DHCPD performance. It could be a week before the issue occur :-(
>
>   We have a sniffer for our DHCP server traffic.  The switch mirrors the traffic of all our DHCP servers to a server dedicated to watching the traffic.  It tends to show us things like rougue servers answering our traffic (when someone inserts a Linksys they bought onto our network with DHCP configured).
>
>   On our DNS servers we run a rolling 10000 packet capture, and spin it off to a support server if it takes less than a couple of seconds to capture the 10000 packets. "snoop -qr -c 10000 -o /var/tmp/dns.watch" and the servers never notice the load.  I suspect the '-r' is not needed when '-o' is present.
>
>   So from "could be a week" you have not noticed a pattern for how long it takes to occur?  It might be enough to just capture the packets shortly before you restart DHCPD.  What does DHCPD performance matter if you're just about to kill the task.

I already tried to capture the traffic just before restarting the
process when there is the
problem with UDP loss but no suspect traffic was noticed. I agree
there must be some
trigger event which cause the kernel to fill the socket buffer and
start dropping packets
but it is suspect to me that restarting the dhcpd process solves the issue ...

-ml