From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 05:41:00 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 E1C1316A4B3 for ; Wed, 8 Oct 2003 05:40:59 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B96CF43FE3 for ; Wed, 8 Oct 2003 05:40:55 -0700 (PDT) (envelope-from peter.bozarov@moniforce.com) Received: from moniforce.com (213-84-208-64.adsl.xs4all.nl [213.84.208.64]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id h98CesPL037179; Wed, 8 Oct 2003 14:40:54 +0200 (CEST) Message-ID: <3F8405D6.1000102@moniforce.com> Date: Wed, 08 Oct 2003 14:40:54 +0200 From: Peter Bozarov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <3F83E2A7.8070209@moniforce.com> <20031008101733.GI6524@saboteur.dek.spc.org> <3F83F37A.7020908@moniforce.com> <20031008121755.GA83114@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Recovery from mbuf cluster exhaustion 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: Wed, 08 Oct 2003 12:41:00 -0000 Bruce M Simpson wrote: > Support for 4.7 is very limited as we transition to 4.9, please be > prepared to upgrade the box. Bear in mind we commit fixes for problems > to HEAD first except in those cases where RELENG_4 is more appropriate. I wonder if it has to do with the version I use. Let's hope so, so that an upgrade will get rid of this. Unfortunately, an upgrade to 4.9 is not feasible for me right now (I'd have done it a long time ago otherwise). > Did you add the 10.2.1.68 route manually? Note that there is code > in if_ethersubr.c which should loopback a copy of a packet sent on an > IFF_SIMPLEX interface automatically, so it shouldn't be required. > > For example, on my laptop: > 192.168.1.68 00:04:76:5e:ec:7d UHLW 0 2 lo0 > > This route is created automatically by arp_rtrequest(). The RTF_WASCLONED > (W) flag tells us this. Because ether_output() is calling if_simloop() to > loopback the packets, the RTF_LLINFO (L) flag gets ignored. The route is added at boot time via DHCP. In fact, this is all that I have in my /etc/rc.conf ifconfig_rl0="DHCP" ifconfig_xl0="inet 10.0.0.1 netmask 255.255.255.0" ifconfig_xl1="up" > > Try removing this route and see what happens. > These are the routing tables now: Internet: Destination Gateway Flags Refs Use Netif Expire default 10.2.1.1 UGSc 24 0 rl0 10.2.1/24 link#1 UC 3 0 rl0 10.2.1.1 00:04:76:1f:53:60 UHLW 27 444 rl0 1134 10.2.1.2 00:60:08:10:4a:36 UHLW 0 2 rl0 928 10.2.1.6 00:d0:a8:00:a8:f5 UHLW 0 334 rl0 1178 127.0.0.1 127.0.0.1 UH 1 30 lo0 I've removed the 10.2.1.68 route on lo0. Injecting packets from the dump file still leads to mbuf cluster depletion. 4433/4592/18240 mbufs in use (current/peak/max): 4433 mbufs allocated to data 4432/4560/4560 mbuf clusters in use (current/peak/max) 10268 Kbytes allocated to network (75% of mb_map in use) 219 requests for memory denied 4 requests for memory delayed 0 calls to protocol drain routines > Are you using the bridging code to do this? > If so, can you post the bridging configuration? I'm sorry. I meant gateway. I have "gateway_enable=yes" in rc.conf and the following in my ipfw configuration. 00050 divert 8668 ip from any to any via rl0 This way the machine on the 10.0.0.0/24 network can get onto the 10.2.1.0/24 network (which leads to the Internet). Conversely, traffic for the 10.0.0.0/24 received on the 10.2.1.0/24 interface (rl0) is routed appropriately to xl0. > Unfortunately it doesn't quite work that way... you are exercising > a leak somewhere and it needs to be tracked down. You should collate > all the information as we track this thread and prepare to submit a PR. Do you suppose it's inside the xl0 driver code? As I said, bringing the xl0 interface down stops draining my mbufs, bringing it up starts the drain again. I find this very odd. Peter