From owner-freebsd-questions@FreeBSD.ORG Fri Jan 29 16:51:07 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7151065679 for ; Fri, 29 Jan 2010 16:51:07 +0000 (UTC) (envelope-from up@3.am) Received: from mail.pil.net (ns3.pil.net [209.17.170.205]) by mx1.freebsd.org (Postfix) with SMTP id D912F8FC12 for ; Fri, 29 Jan 2010 16:51:06 +0000 (UTC) Received: (qmail 48929 invoked from network); 29 Jan 2010 11:51:05 -0500 Received: from unknown (HELO localhost) (127.0.0.1) by 0 with SMTP; 29 Jan 2010 11:51:05 -0500 Date: Fri, 29 Jan 2010 11:51:05 -0500 (EST) From: James Smallacombe X-X-Sender: up@ns3.pil.net To: freebsd-questions@freebsd.org In-Reply-To: <6201873e1001281207o6071426ud29a9de5b02424e@mail.gmail.com> Message-ID: References: <979FD2CE-FCCE-4C61-8FA8-74D75E091C43@mac.com> <6201873e1001281207o6071426ud29a9de5b02424e@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: UDP flooding / Ethernet issues? WAS Re: named "error sending response: not enough free resources" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:51:07 -0000 > On Thu, Jan 28, 2010 at 12:59 PM, James Smallacombe wrote: > >> To follow up on this: Noticed the issue again this morning, which also was >> accompanied by latency so high that I could not connect (some pings got >> through at very high latency). I emailed the provider and they told me that >> they had my port on their Ether switch set to 10Mbs. They switched it to >> 100Mbs and only time will tell if that fixes it. >> >> Does this sound like it could be the entire cause? I ask because I've >> maxed out pipes before, but never seen it shut all traffic down this much. >> One key difference that I forgot to mention is that this server is running >> TWO instances of named, on two different IPs (for different domains), each >> running a few hundred zones. >> >> Bottom line: Would congestion cause this issue, or would this issue cause >> congestion? Some updates that may confuse more than inform: I caught this while it was happening yesterday and was able to do a tcpdump. I saw a ton of UDP traffic outbound to one IP that turned out to be a colocated server in Chicago. I put that IP in my ipfw rules and once I blocked "any to" that IP, it seemed to stop. Since then however, the logs have show the same issue again and there have been a few brief service disruptions. Today's security run output showed this: +(RULE NUMBER) 16054161 131965203420 deny ip from any to (blocked IP) and more alarmingly, this: kernel log messages: +++ /tmp/security.BErFHSS3 2010-01-29 03:09:32.000000000 -0500 +re0: link state changed to DOWN +re0: link state changed to UP +re0: promiscuous mode enabled +re0: promiscuous mode disabled +re0: promiscuous mode enabled +re0: promiscuous mode disabled +re0: promiscuous mode enabled +re0: promiscuous mode disabled re0 obviously being the Realtek Ethernet driver. The server itself never went down during this time, but the Ethernet did. Is there any DOS type of event that could cause this, or could the root of the problem be an Ethernet hardware or driver issue? Again, it is not clear to me which is the cause and which is the effect. Last bit of info: I just did a: 'tcpdump -n | grep -i udp' and saw a bunch of these, coming up a couple of times per second: 11:31:59.387561 IP (IP REMOVED) > (IP REMOVED): NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST Where the source and destination IPs vary, but are NOT one of mine, but DO appear to belong to my colo/dedicated server provider and their customers. Is my server being used to DDOS others? If so, how? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am =========================================================================