From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 13:19:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8844F16A4CE for ; Mon, 1 Dec 2003 13:19:39 -0800 (PST) Received: from web80213.mail.yahoo.com (web80213.mail.yahoo.com [66.218.79.48]) by mx1.FreeBSD.org (Postfix) with SMTP id 7979D43FD7 for ; Mon, 1 Dec 2003 13:19:22 -0800 (PST) (envelope-from secureplay@sbcglobal.net) Message-ID: <20031201211922.53625.qmail@web80213.mail.yahoo.com> Received: from [161.114.1.182] by web80213.mail.yahoo.com via HTTP; Mon, 01 Dec 2003 13:19:22 PST Date: Mon, 1 Dec 2003 13:19:22 -0800 (PST) From: Val P To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: bridging... stops? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 21:19:39 -0000 Hi, Every now and then (maybe once a month), our freebsd firewall/bridge stops bridging. There are no errors anywhere, and no obvious triggers (for example, it was working sunday night, Monday morning it was dead). Turning off IPF or setting its rules to pass all did not fix the problem, so I am somewhat ruling out IPF as the problem. Rebooting the machine did fix the problem -- everything was working once again... but I'd rather not be fixing problems the microsoft way. :) How can I go about debugging this issue when it happens again? FYI: Proliant DL380/G2 (or G3, I forget?) with 1GB RAM. Three active NICs: copper broadcomm gigabit on bge0 (management port), and fiber broadcom gigabit on bge 2/3 (bridge endpoints). Single processor at around 2 GHz or so. Load on the server is light, no packet loss. Running FreeBSD 4.8. There were absolutely no changes (physical or software) between the time the machine was working and the time it stopped working. Whether or not there were any transient network conditions I do not know. I did find a machine on the network which was broadcasting with an IP of 127.0.0.1, and killed it.. but that was after rebooting the server and restoring bridging functionality.