From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 01:19:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16AC016A400 for ; Sun, 25 Mar 2007 01:19:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id A2AD413C487 for ; Sun, 25 Mar 2007 01:19:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l2P1JAZx007959; Sat, 24 Mar 2007 20:19:10 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l2P1J8M2007958; Sat, 24 Mar 2007 20:19:08 -0500 (CDT) (envelope-from brooks) Date: Sat, 24 Mar 2007 20:19:08 -0500 From: Brooks Davis To: Hartmut Brandt Message-ID: <20070325011908.GC7607@lor.one-eyed-alien.net> References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> <4604FDD4.2080805@freebsd.org> <20070324123754.GA80483@svzserv.kemerovo.su> <20070324182901.I59406@knop-beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline In-Reply-To: <20070324182901.I59406@knop-beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sat, 24 Mar 2007 20:19:10 -0500 (CDT) Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, Andre Oppermann , Eugene Grosbein Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 01:19:15 -0000 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 24, 2007 at 06:37:59PM +0100, Hartmut Brandt wrote: > On Sat, 24 Mar 2007, Eugene Grosbein wrote: >=20 > EG>On Sat, Mar 24, 2007 at 11:30:44AM +0100, Andre Oppermann wrote: > EG> > EG>> Harti Brandt wrote: > EG>> >Nice feature, although it would be nice to align the maximum length= with=20 > EG>> >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more= =20 > EG>> >naturally fits into struct if_data (see net/if.h) given the comment= for=20 > EG>> >that struct: > EG>> > > EG>> >/* > EG>> > * Structure describing information about an interface > EG>> > * which may be of interest to management entities. > EG>> > */ > EG>>=20 > EG>> The string array should most likely not be part of struct ifnet as t= hat > EG>> would bloat it quite a bit. If it is in there it should be at the e= nd > EG>> of the struct to avoid cache line busting effects. > EG> > EG>Also vote for this. And is it possible to make it a pointer instead > EG>of array? The bloat would be minimal for system with tons of interface= s, > EG>think about large pptp or pppoe server or similar that never would > EG>utilize arrays. >=20 > That makes sense. If it is a pointer it should not live in struct ifdata= =20 > which can be retrieved via sysctl(). >=20 > As for access to this field perhaps it makes more sense to use the sysctl > net.link.generic.ifdata subtree. We have already IFDATA_DRIVERNAME there= =20 > which returns a string. Could be IFDATA_DESCRIPTION (4). This would=20 > probably be more in line with the management nature of the data. Just a= =20 > thought... Would be slightly easier for the SNMP daemon to use... If must not live in struct ifdata as the size of struct ifdata is part of the routing socket API. :( There are two bytes avaible in struct ifdata. -- Brooks --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGBc4MXY6L6fI4GtQRAjp0AKDL6bYit59V+7Fptg8/TtcijgyGHQCfSKqi BnyLnBae+A2iduGFcBlwMvQ= =E/BL -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 07:21:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D521016A400 for ; Sun, 25 Mar 2007 07:21:52 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id B046313C459 for ; Sun, 25 Mar 2007 07:21:52 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (206-223-169-82.beanfield.net [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 1F7B479E2AF for ; Sun, 25 Mar 2007 02:04:02 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 81042-02 for ; Sun, 25 Mar 2007 07:04:01 +0000 (UTC) Received: from hole.shrew.net (24-155-108-213.dyn.grandenetworks.net [24.155.108.213]) by shrew.net (Postfix) with ESMTP id E640979E2A4 for ; Sun, 25 Mar 2007 02:04:00 -0500 (CDT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.6/8.13.6) with ESMTP id l2P06Ie7073834 for ; Sun, 25 Mar 2007 00:06:18 GMT (envelope-from mgrooms@shrew.net) Message-ID: <46062D3E.3080208@shrew.net> Date: Sun, 25 Mar 2007 02:05:18 -0600 From: Matthew Grooms User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: VPN Client for Win32 and now FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 07:21:52 -0000 All, I recently released the Shrew Soft Win32 VPN Client 2.0 Beta which is designed to work with ipsec tools. This software has seen an immense amount of improvement since the 1.1 release and features a completely re-worked kernel driver framework, a new direct adapter mode for more traditional road warrior setups, simplified configuration, improved gateway compatibility using modecfg push or pull mode, a much improved debug output application and loads of bug fixes. If you are interested in giving it a try, please visit the url below to obtain a free download. Any feedback or bug reports are very much welcome using the shrew.net mailing lists or web submission form. http://www.shrew.net Along with the improvements to the win32 package, I have ported the ike daemon and front end gui applications to FreeBSD under a liberal open source license. The ike daemon can be used to support site to site or client to gateway communications for ipv4 hosts. While the win32 client has its own ipsec code, the FreeBSD port uses the existing kernel ipsec support with or without Yvans NATT kernel patches. While this software should be considered experimental on FreeBSD, I use it on a regular basis to connect to a cisco ASA system so it certainly has some utility. The best way to describe the software working in a client mode would be to put vpnc on steroids and add a gui front end. When using the software as a VPN client gateway, it is functionally similar to racoon with en emphasis on flexible client based connectivity and a few other extras. Please have a look at the build.txt and iked.conf man page for more details. Here is the subversion url if anyone wants to check out the source ... svn://svn.shrew.net/ike/head And a few gui screen shots are available here ... http://www.shrew.net/?page=software I also attempted to cobble together a rough port for the software. This is my first attempt at writing a port so it could use a lot of help. For starters, the software requires bison 2.3 to build properly but I couldn't quite figure out how to create the dependency. QT is also required for the client front end applications. I tried to create this dependency but am not sure if its working either. If both are installed in advance, the port builds and works fine. Here is the url if anyone wants to give it a try ... http://www.shrew.net/vpn/ike.tgz Bug reports and feedback are welcome using the shrew.net mailing lists. -Matthew From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 20:10:46 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A93F16A402; Sun, 25 Mar 2007 20:10:46 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFA813C459; Sun, 25 Mar 2007 20:10:46 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2PKAkX3018213; Sun, 25 Mar 2007 20:10:46 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2PKAkAk018209; Sun, 25 Mar 2007 20:10:46 GMT (envelope-from matteo) Date: Sun, 25 Mar 2007 20:10:46 GMT From: Matteo Riondato Message-Id: <200703252010.l2PKAkAk018209@freefall.freebsd.org> To: matteo@FreeBSD.org, freebsd-net@FreeBSD.org, matteo@FreeBSD.org Cc: Subject: Re: bin/100969: [rpc.lockd] rpc.lockd conflict with cups over udp ports 631 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 20:10:46 -0000 Synopsis: [rpc.lockd] rpc.lockd conflict with cups over udp ports 631 Responsible-Changed-From-To: freebsd-net->matteo Responsible-Changed-By: matteo Responsible-Changed-When: Sun Mar 25 20:10:23 UTC 2007 Responsible-Changed-Why: I'll work on this http://www.freebsd.org/cgi/query-pr.cgi?pr=100969 From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 02:33:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49ED716A400 for ; Mon, 26 Mar 2007 02:33:47 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id D2AF213C457 for ; Mon, 26 Mar 2007 02:33:46 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1479048ugh for ; Sun, 25 Mar 2007 19:33:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nk7/sJwHZfwKCnXq9GGd0Z2FZJxRLlxxsj5o8/6x/MmBVBejOrd+iYx2fiXnEXqHMjYpknydJmMxZp9wpSMwNsZ3hDxUbOXG8PHMjVjMqSmd211sL+tWYKFicWvGY+Iyw/bznuv9/Rv0CRaQb39fNpi3yt3EzND1LmxT0rFG1rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=P10NltykscL2LFsoK90kOBDsi1XUlQm9z9BhN8BZ7SoGUY10aMw9VAYG5+0yJkh5o7QqVA3cAnDT33SDw3PzxfOJAOtuQWKY4mFl6SMf/gIGlToAwthd/a2tSIk8DjJeHPP104wR5klsLp+xEQC3AX1DJKdiFfmnN2mfdDMMy1A= Received: by 10.114.153.18 with SMTP id a18mr2430664wae.1174876424792; Sun, 25 Mar 2007 19:33:44 -0700 (PDT) Received: by 10.114.254.5 with HTTP; Sun, 25 Mar 2007 19:33:44 -0700 (PDT) Message-ID: Date: Mon, 26 Mar 2007 13:33:44 +1100 From: "Sam Wun" To: "Yuri Lukin" In-Reply-To: <20070309140331.M56659@swaggi.com> MIME-Version: 1.0 References: <20070309140331.M56659@swaggi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: wireless serer card that can handle multi-users X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 02:33:47 -0000 On 3/10/07, Yuri Lukin wrote: > > On Fri, 9 Mar 2007 14:10:45 +1100, Sam Wun wrote > > Hi, > > > > About half year ago, I tested a mini wireless server card with > > FreeBSD 6. The connection runs very fast if only myself using it, > > but when there are more than 1 user connected to it, the second > > user will suffer extremely slow wireless network connection. My > > colleague also told me he also experienced that problem for his > > clients. So he purchased a cheap D-Link Wireless access point for > > his client rather than bundle the wireless access point > > (card) in the freebsd router box. > > > > Can anyone tell me which wifi server card don't have that problem > > when configured with freebsd? > > Assuming that you're talking about MiniPCI cards, you can use any based on > the > Atheros chipset. I believe most if not all currently shipping Atheros > cards > are supported in FreeBSD 6.2. I have personally been using Wistron CM9 for > nearly a year now. As far as the problem you described, you could have > been > running mixed b/g mode causing protection bit to be set which effectively > reduces the throughput of your wireless LAN. Hi, thanks for the information. I have logged on to the freebsd router have a look at its wifi setup in rc.conf, but I don't think it is configured as b/g combination mode. I don't have a login to this router at the moment, so I can't post the content of the rc.conf file here. Do you mind post your wifi configuration here or send it to my email? Thanks Sam Yuri > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 07:00:19 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CF1816A401 for ; Mon, 26 Mar 2007 07:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9C913C45D for ; Mon, 26 Mar 2007 07:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2Q70IYl011792 for ; Mon, 26 Mar 2007 07:00:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2Q70IIU011790; Mon, 26 Mar 2007 07:00:18 GMT (envelope-from gnats) Date: Mon, 26 Mar 2007 07:00:18 GMT Message-Id: <200703260700.l2Q70IIU011790@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Roman Bogorodskiy Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roman Bogorodskiy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 07:00:19 -0000 The following reply was made to PR kern/110720; it has been noted by GNATS. From: Roman Bogorodskiy To: bug-followup@FreeBSD.org, dmitri@dworlds.ru Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions Date: Mon, 26 Mar 2007 10:52:20 +0400 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I wrote that two years ago... mailto:bug-followup@FreeBSD.org,dmitri%40dworlds.ru?subject=Re:%20kern/110720:%20%5Bnet%5D%20%5Bpatch%5D%20support%20for%20interface%20descriptions brooks@ left some comments recently, though I have not had enough time to take a look at it... Roman Bogorodskiy --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iQCVAwUBRgdtpIB0WzgdqspGAQJJZAQAkbS1UX8mIxIjhsUuQRJnJpFfOQvoM4RL 25fiFNumPw+nXGAA51mGpf/0BCXsV1dkbvNVTAPaqJZzPdH7uyNor826hYM1FPD4 OCmnDIIpDo7fIcYtpxTBbfoq7QfIZGM4RGJHW57ZeWxcXZMOsYNwkT2Ad/ohv7SE MkvV/C8pkTc= =1OzW -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 07:10:06 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A78B16A400 for ; Mon, 26 Mar 2007 07:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7B213C458 for ; Mon, 26 Mar 2007 07:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2Q7A6tR012763 for ; Mon, 26 Mar 2007 07:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2Q7A6CY012762; Mon, 26 Mar 2007 07:10:06 GMT (envelope-from gnats) Date: Mon, 26 Mar 2007 07:10:06 GMT Message-Id: <200703260710.l2Q7A6CY012762@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Roman Bogorodskiy Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roman Bogorodskiy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 07:10:06 -0000 The following reply was made to PR kern/110720; it has been noted by GNATS. From: Roman Bogorodskiy To: bug-followup@FreeBSD.org, dmitri@dworlds.ru Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions Date: Mon, 26 Mar 2007 11:04:19 +0400 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Roman Bogorodskiy wrote: > I wrote that two years ago... >=20 > mailto:bug-followup@FreeBSD.org,dmitri%40dworlds.ru?subject=3DRe:%20kern/= 110720:%20%5Bnet%5D%20%5Bpatch%5D%20support%20for%20interface%20descriptions Doh, I copy-pasted wrong link. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/83622 > brooks@ left some comments recently, though I have not had enough time > to take a look at it... >=20 > Roman Bogorodskiy Roman Bogorodskiy --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iQCVAwUBRgdwc4B0WzgdqspGAQJZ6wQAnpdEpAR7e+L27AQvbhW2ycge4XBX0VcM kNQcy8JHbJbAcgrSwclzZeRPau4ulM89XUOphE5QG3SpGS0vYoX8rewFYgqAa96z eeByiRrC+jqqKFZby3R2z50vFQKZ7e3c0qEn5Lvlz+cL4gsU3Cx89/7qDsxVbbXX SwoK9f14bYI= =Eyes -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 07:49:37 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F3CF16A401 for ; Mon, 26 Mar 2007 07:49:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 477C013C458 for ; Mon, 26 Mar 2007 07:49:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l2Q7nKvr016627; Mon, 26 Mar 2007 00:49:21 -0700 (PDT) Date: Mon, 26 Mar 2007 16:49:04 +0900 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Tomoyuki Okazaki Subject: Camellia Patch for CURRENT IPsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 07:49:37 -0000 Hi Folks, I've been working with Tomoyuki Okazaki of NTT on integrating their Camellia encryption code into CURRENT. I have tested the patch, which you can find at: http://people.freebsd.org/~gnn/diff-20070320.gz against HEAD as of the last couple of days, and it builds and runs without problems. I have NOT done extensive testing, just basic tests with src/tools/regression/ipsec/ipsec*.t, which I have updated to test both Camellia and AES. I would like to commit Camellia to HEAD in the next few days but I would also like to hear from people about this code. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 08:21:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AA7A16A402 for ; Mon, 26 Mar 2007 08:21:22 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4F113C45B for ; Mon, 26 Mar 2007 08:21:22 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1950915ana for ; Mon, 26 Mar 2007 01:21:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=OboJXZ0sDW/STA9VCBeHPqGBGupCsF0I/kAAt+XiD7QQ5C+QQmDzL0gDMJyHH1ixon2iH+z9aPkJ7UsDVzprzD4jVko30Q+u+Q3L4BexaJVce2hEqIQNgVHhuvKMw+MPdmBgeFM8yoBCXvCyuA5DgKiee+YTSiqFN1KQV36ONjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=AYa7+9lfwFw5m2QoT9U+ucWxb1k7xhqGHeT/IBoaIInxCLwzc++I/fv3wn+mgeHvMLUQ4EKhjhjzR+bIGnUzLXMCI4y1okCJaSyS142gcFSUwPBIVhDagJm14WtrAxWsU2LlAo5avplqTJNWJNGjJRouyUrpqMPIa/C1/LVINUc= Received: by 10.100.191.5 with SMTP id o5mr4687073anf.1174895534430; Mon, 26 Mar 2007 00:52:14 -0700 (PDT) Received: by 10.100.167.12 with HTTP; Mon, 26 Mar 2007 00:52:14 -0700 (PDT) Message-ID: <8ae5ea120703260052m13cf2687va5ede1f81b0f45d9@mail.gmail.com> Date: Mon, 26 Mar 2007 15:52:14 +0800 From: "Zhu Yan" To: freebsd-net@freebsd.org, freebsd-bug@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: The wi0 's Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 08:21:22 -0000 Hi Everybody, There is a bug in wi0, when I ifconfig scan the IP from DHCP, my wi0 will be panic... This bug is in all FreeBSD 6.x RELEASE, is there anybody know it? -- eSX From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 08:34:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBFDB16A401 for ; Mon, 26 Mar 2007 08:34:47 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 61D7713C459; Mon, 26 Mar 2007 08:34:47 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id D84C8EB4D48; Mon, 26 Mar 2007 16:34:41 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id IV2DsxBlqpZa; Mon, 26 Mar 2007 16:34:34 +0800 (CST) Received: from [10.217.12.249] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 1710CEB4970; Mon, 26 Mar 2007 16:34:34 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=HGxKxOa6Y+nEddOrqXH6PFdzZA9j0zfvfkY8eZfN7kLftTx91SCgwBj024fNyu1sq M9C2cXYZ2vLCYyhKCyZbA== Message-ID: <4607858C.7050104@delphij.net> Date: Mon, 26 Mar 2007 16:34:20 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Zhu Yan References: <8ae5ea120703260052m13cf2687va5ede1f81b0f45d9@mail.gmail.com> In-Reply-To: <8ae5ea120703260052m13cf2687va5ede1f81b0f45d9@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFF7B8137574C36FDCF09A2C8" Cc: freebsd-net@freebsd.org, freebsd-bug@freebsd.org Subject: Re: The wi0 's Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 08:34:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF7B8137574C36FDCF09A2C8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Zhu Yan wrote: > Hi Everybody, > There is a bug in wi0, when I ifconfig scan the IP from DHCP, my wi0 > will be > panic... > This bug is in all FreeBSD 6.x RELEASE, is there anybody know it? You really have to give us the *backtrace*. Compile a kernel with ddb and try to obtain a crash dump according to the Developers' Handbook. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigFF7B8137574C36FDCF09A2C8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB4WMOfuToMruuMARCqkaAJ4ydBcUE7SqOSjpN5I4j4Z4T5UmIwCdFCNl tx7Qn6inQ3Zur6FxYa9yYxk= =fZMJ -----END PGP SIGNATURE----- --------------enigFF7B8137574C36FDCF09A2C8-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 11:08:21 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C404B16A4CF for ; Mon, 26 Mar 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B145D13C4C4 for ; Mon, 26 Mar 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QB8L1g049356 for ; Mon, 26 Mar 2007 11:08:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QB8KnY049350 for freebsd-net@FreeBSD.org; Mon, 26 Mar 2007 11:08:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Mar 2007 11:08:20 GMT Message-Id: <200703261108.l2QB8KnY049350@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 11:08:21 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch a bin/94920 net [rpc] rpc.statd(8) conflict with cups over tcp and udp o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net bridge interface given in rc.conf not taking an (stati o kern/110720 net [net] [patch] support for interface descriptions 13 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 14:37:34 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 691BD16A403; Mon, 26 Mar 2007 14:37:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1B013C45E; Mon, 26 Mar 2007 14:37:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2QEbYdA084250; Mon, 26 Mar 2007 14:37:34 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2QEbXMv084246; Mon, 26 Mar 2007 14:37:33 GMT (envelope-from bms) Date: Mon, 26 Mar 2007 14:37:33 GMT From: Bruce M Simpson Message-Id: <200703261437.l2QEbXMv084246@freefall.freebsd.org> To: pingpan@research.bell-labs.com, bms@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/19875: A new protocol family, PF_IPOPTION, to handle IP options at socket interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 14:37:34 -0000 Synopsis: A new protocol family, PF_IPOPTION, to handle IP options at socket interface State-Changed-From-To: suspended->closed State-Changed-By: bms State-Changed-When: Mon Mar 26 14:36:38 UTC 2007 State-Changed-Why: It is unlikely this code will ever be committed. Reasons: 1) This information can be obtained via cmsg so as to lie out-of-band of protocol data 2) This code is IPv4 specific 3) Most consumers of IP options and router alerts either live in the kernel, or have this information delivered via raw sockets. http://www.freebsd.org/cgi/query-pr.cgi?pr=19875 From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 17:29:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 529A816A402 for ; Mon, 26 Mar 2007 17:29:15 +0000 (UTC) (envelope-from tutatnhamon@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id D2B0313C4AD for ; Mon, 26 Mar 2007 17:29:14 +0000 (UTC) (envelope-from tutatnhamon@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1667091ugh for ; Mon, 26 Mar 2007 10:29:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=MkPk5dKFAgxLfQwjoH+06bLezLM6rHBl4JUPcDritn0UTvBI5wFJ6kOvxYZDosv77qn+wdbwayw/283J3jEbXfB8QRpN7iP1dGN9gmcmje5ISP7MYGK9xPm5pJfu5J9Q7MkkUva+otdqApi1BRRCDbaqYi2omntpQFEBVfSI62Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Q2m3npQkv2j2QXFu6QAvDsBkZwFuVW1Gk1Q2U18MpWHYp1Uu6jMMF5FaMLFh+TdT2zXFlkwAehZDRny5kSVt/sxPbpHcy2n8fROnS5DIJ2oarBIMaJsC0TrxFXilKdF/jf0iNdPTleot8NorgxV0ccwzRonnhzMmErXoI9Hegbs= Received: by 10.78.138.14 with SMTP id l14mr3089894hud.1174928453683; Mon, 26 Mar 2007 10:00:53 -0700 (PDT) Received: by 10.78.29.10 with HTTP; Mon, 26 Mar 2007 10:00:53 -0700 (PDT) Message-ID: <65dfa4fc0703261000r4af6f548p2ac287611b8524f6@mail.gmail.com> Date: Mon, 26 Mar 2007 20:00:53 +0300 From: "Artem Naluzhny" Sender: tutatnhamon@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: b773a4e27e5b9cb2 Subject: Reason of "dropped due to full socket buffers" UDP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 17:29:15 -0000 hi I have 6.1-RELEASE with default sysctl vars. Continuous 'netstat -sp udp' with 100 ms. interval shows dropped UDP due to full socket buffers sometimes. The script also monitors 'netstat -anp udp' and there are no connections with non-zero Recv-Q value by the end of the interval with drops. The server is used as SIP server (ser) with RTP proxy (rtpproxy). Avg pps (Broadcom BCM5721 Gigabit Ethernet, bge): 630 in, 460 out. Any ideas how to find out a reason? (no kernel changes allowed, the server is in production) -- tut DaRK VoIP GuRU From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 18:42:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC22B16A406 for ; Mon, 26 Mar 2007 18:42:08 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBA813C4B8 for ; Mon, 26 Mar 2007 18:42:08 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2121717ana for ; Mon, 26 Mar 2007 11:42:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hcjTSA5bvXYesQducCkPy75GAKfxMi9zByVLF2zF8veXNp/UhLV1sK3dGdi39ok6bLOVCiyD/cOmrMPXIqw0yAum7waNjWim/74Ed4NxjmpLiiT92DstKjJI62xRGllRWMGiYf2dVnjVXcRtU+jKSbqR+hKe+cowg7Wcin0eUFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bZD2/08/8OVm0Fki/TTGPCnRdKyCW4Yz+jZes/IAXzEBewVDnxkRHh92OyulgOXbf5E1Urwk9wEYSwWElABzzOdsC577IHJZSrrIFGB19oPSjZjiwU+SOUuJLOuDPOi+nNkeK00OOJqOsxZNNWO61ddiTn0Q7ZMgqadIHw6E7Tc= Received: by 10.100.37.4 with SMTP id k4mr5326348ank.1174934527249; Mon, 26 Mar 2007 11:42:07 -0700 (PDT) Received: from ?192.168.11.5? ( [65.33.136.97]) by mx.google.com with ESMTP id d19sm10549602and.2007.03.26.11.42.05; Mon, 26 Mar 2007 11:42:06 -0700 (PDT) Message-ID: <46081409.2080300@gmail.com> Date: Mon, 26 Mar 2007 14:42:17 -0400 From: Sten Daniel Soersdal User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Artem Naluzhny References: <65dfa4fc0703261000r4af6f548p2ac287611b8524f6@mail.gmail.com> In-Reply-To: <65dfa4fc0703261000r4af6f548p2ac287611b8524f6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Reason of "dropped due to full socket buffers" UDP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 18:42:08 -0000 Artem Naluzhny wrote: > hi > > I have 6.1-RELEASE with default sysctl vars. Continuous 'netstat -sp > udp' with 100 ms. interval shows dropped UDP due to full socket > buffers sometimes. The script also monitors 'netstat -anp udp' and > there are no connections with non-zero Recv-Q value by the end of the > interval with drops. > > The server is used as SIP server (ser) with RTP proxy (rtpproxy). Avg > pps (Broadcom BCM5721 Gigabit Ethernet, bge): 630 in, 460 out. > > Any ideas how to find out a reason? (no kernel changes allowed, the > server is in production) > Perhaps it would be helpful to do non-promiscous packet capture on the ethernet interface over a longer period of time. Perhaps you find something unexpected? That might the least intrusive and most effective without giving you down time. It wouldn't surprise me if broadcom drivers have been improved in -STABLE. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 19:44:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B59DF16A401 for ; Mon, 26 Mar 2007 19:44:38 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7065913C4BC for ; Mon, 26 Mar 2007 19:44:38 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 8FACC7E84D for ; Mon, 26 Mar 2007 22:19:35 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+ocU277Xj6H for ; Mon, 26 Mar 2007 22:19:22 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 8033F7E828 for ; Mon, 26 Mar 2007 22:19:22 +0300 (EEST) Message-ID: <46081CB9.6030109@net.utcluj.ro> Date: Mon, 26 Mar 2007 22:19:21 +0300 From: Cristian KLEIN Organization: Data Communication Center - Technical University of Cluj-Napoca User-Agent: Icedove 1.5.0.7 (X11/20061013) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: GRE with key X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 19:44:38 -0000 Hello everybody, I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid questions. I would like to add key support to gre(4). I have already been able to use gre(4) with a hardcoded key. The single thing remaining to do is to transfer the key from ifconfig(8). The key is an uint32_t and I haven't found a way to transfer it without modifying ifconfig(8). My question is, which is the "BSD-style" to achieve the above? Solutions I came up with are as follows: 1) Use SIOCSDRVSPEC / SIOCGDRVSPEC 2) Add SIOCSGREKEY / SIOCGGREKEY 3) [Probably to ugly to be mentioned, but requires fairy few modifications.] Add a sysctl MIB which is read when calling "ifconfig ... create". Another thing I wanted to ask is, which function of ifconfig(8) should I modify to display the GRE key? Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 20:14:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7C6316A400 for ; Mon, 26 Mar 2007 20:14:23 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by mx1.freebsd.org (Postfix) with ESMTP id 47C6813C4E5 for ; Mon, 26 Mar 2007 20:14:23 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from lqm4.gcapmedia.com (no-dns-yet.demon.co.uk [194.70.58.205] (may be forged)) by rly02b.srv.mailcontrol.com (MailControl) with ESMTP id l2QJOLVA032097 for ; Mon, 26 Mar 2007 20:25:50 +0100 Received: from LQEVS1.gcapmedia.com ([10.73.2.12]) by lqm4.gcapmedia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 20:24:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Mar 2007 20:24:48 +0100 Message-ID: <3DDDCC38D00FA545A6C012475EF2DC0302AF85DF@LQEVS1.gcapmedia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vrrp/CARP/ucarp Problems Thread-Index: Acdv3GtVHpShS0fORi+7ONcFQCvhgg== From: "Ross Draper" To: X-OriginalArrivalTime: 26 Mar 2007 19:24:51.0507 (UTC) FILETIME=[6CF8A030:01C76FDC] X-Scanned-By: MailControl A-07-06-90 (www.mailcontrol.com) on 10.66.0.112 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 20:14:23 -0000 Hi All =20 I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. =20 I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. =20 UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always comes up advertising itself as the master then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to). The backup boxes initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. =20 CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. =20 Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitous arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements(lower priority), it never goes into backup mode again. =20 So, what am I doing wrong? Are these common problems, or something that appears specific to my hosts/switches? are there more suitable options? The loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards.=20=20 =20 Any help/suggestions much appreciated, also, any links to a perl based gratuitous arp util would be great! =20 Many thanks Ross=20 PS - Apologies if you see multiple copies of this message, I seem to be having trouble getting mails onto the list. All correspondence, attachments and agreements remain strictly subject to f= ully executed contract. (c) GCap Media plc 2006. All rights remain reserved= . This e-mail (and any attachments) contains information which may be confi= dential, subject to intellectual property protection and may be legally pri= vileged and protected from disclosure and unauthorised use. It is intended = solely for the use of the individual(s) or entity to whom it is addressed a= nd others specifically authorised to receive it. If you are not the intende= d recipient of this e-mail or any parts of it please telephone 020 7054 800= 0 immediately upon receipt. No other person is authorised to copy, adapt, f= orward, disclose, distribute or retain this e-mail in any form without prio= r specific permission in writing from an authorised representative of GCap = Media plc. We will not accept liability for any claims arising as a result = of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. = Registered in England & Wales with No. 923454 From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 21:23:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAE4316A403 for ; Mon, 26 Mar 2007 21:23:47 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6FE13C4B7 for ; Mon, 26 Mar 2007 21:23:47 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A8D2220ABAE; Mon, 26 Mar 2007 17:23:47 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 26 Mar 2007 17:23:47 -0400 X-Sasl-enc: 5mdvDMtD6itqdbGqzVC28IiSJ0n2o+DDqBtXHKd6oHDQ 1174944227 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 470B719DEF; Mon, 26 Mar 2007 17:23:47 -0400 (EDT) Message-ID: <460839E1.8080408@FreeBSD.org> Date: Mon, 26 Mar 2007 22:23:45 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Cristian KLEIN References: <46081CB9.6030109@net.utcluj.ro> In-Reply-To: <46081CB9.6030109@net.utcluj.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: GRE with key X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2007 21:23:47 -0000 Cristian KLEIN wrote: > Hello everybody, > > I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid > questions. > > I would like to add key support to gre(4). I have already been able to > use gre(4) with a hardcoded key. The single thing remaining to do is to > transfer the key from ifconfig(8). The key is an uint32_t and I haven't > found a way to transfer it without modifying ifconfig(8). > Excellent. Thanks for volunteering to do this! > My question is, which is the "BSD-style" to achieve the above? Solutions > I came up with are as follows: > 1) Use SIOCSDRVSPEC / SIOCGDRVSPEC > 2) Add SIOCSGREKEY / SIOCGGREKEY > 3) [Probably to ugly to be mentioned, but requires fairy few > modifications.] Add a sysctl MIB which is read when calling "ifconfig > ... create". > If I were doing this, I would add the code to ifconfig.c where the other tunnel stuff lives, and go for option number 2. Feel free to modify ifconfig to accomodate the the new options. > Another thing I wanted to ask is, which function of ifconfig(8) should I > modify to display the GRE key? > Look at how af_status_tunnel() works and consider adding it there. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 08:08:31 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60A6216A404 for ; Tue, 27 Mar 2007 08:08:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C05013C484 for ; Tue, 27 Mar 2007 08:08:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9BD2146D6F for ; Tue, 27 Mar 2007 03:08:30 -0500 (EST) Date: Tue, 27 Mar 2007 09:08:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org In-Reply-To: <20070226114451.O48828@fledge.watson.org> Message-ID: <20070327090718.O77768@fledge.watson.org> References: <20070226114451.O48828@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Looking for users of IPX over IP tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 08:08:31 -0000 On Mon, 26 Feb 2007, Robert Watson wrote: > Over the next couple of weeks, I will be reviewing the set of non-MPSAFE > network stack components in preparation for a status update to the arch@ > mailing list. One of the remaining components that requires Giant is the > IPX over IP tunneling facility (ipx_ip). I'd like to solicit users of this > facility, if any, to work with me in testing locking patches I'm currently > developing against FreeBSD 7.x. > > I'm actually not entirely convinced this feature works, so would also like > to hear from users of IPX over IP tunneling for this reason. I've found a > couple of bugs that would result in improper error messages being returned, > etc. There's also a comment in the NOTES file that this feature is "not > available". Still looking for IPX over IP users. Please let me know if you use IPX over IP tunneling support, and/or if you would be able to test MPSAFEty patches on 6.x or 7.x. The other easy route here is to remove IPX over IP tunnel support from 7.0 and then reintroduce it if testers are found in the future, but such scenarios generally don't lead to feature re-introduction, so if this is a feature you care about, then please get in touch with me. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 08:10:10 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9916C16A400 for ; Tue, 27 Mar 2007 08:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF8413C448 for ; Tue, 27 Mar 2007 08:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2R8A9rW039619 for ; Tue, 27 Mar 2007 08:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2R8A9JV039618; Tue, 27 Mar 2007 08:10:09 GMT (envelope-from gnats) Date: Tue, 27 Mar 2007 08:10:09 GMT Message-Id: <200703270810.l2R8A9JV039618@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Dmitri Alenitchev" Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitri Alenitchev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 08:10:10 -0000 The following reply was made to PR kern/110720; it has been noted by GNATS. From: "Dmitri Alenitchev" To: "Roman Bogorodskiy" Cc: bug-followup@freebsd.org Subject: Re: kern/110720: [net] [patch] support for interface descriptions Date: Tue, 27 Mar 2007 12:01:45 +0400 Roman Bogorodskiy wrote: [...] > Doh, I copy-pasted wrong link. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 > > > brooks@ left some comments recently, though I have not had enough time > > to take a look at it... Yes, really. This PR is duplicated with 83622. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 08:37:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FDC216A400 for ; Tue, 27 Mar 2007 08:37:41 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id AD8CC13C48A for ; Tue, 27 Mar 2007 08:37:40 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 6082B1B10F09; Tue, 27 Mar 2007 10:37:39 +0200 (CEST) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 5ADA81B10EA4; Tue, 27 Mar 2007 10:37:39 +0200 (CEST) Message-ID: <4608D7D1.4070304@sun-fish.com> Date: Tue, 27 Mar 2007 11:37:37 +0300 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: Ross Draper References: <3DDDCC38D00FA545A6C012475EF2DC0302AF85DF@LQEVS1.gcapmedia.com> In-Reply-To: <3DDDCC38D00FA545A6C012475EF2DC0302AF85DF@LQEVS1.gcapmedia.com> Content-Type: multipart/mixed; boundary="------------010107000605050406040108" X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stefan.lambrev@sun-fish.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 08:37:41 -0000 This is a multi-part message in MIME format. --------------010107000605050406040108 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable HI all, Ross Draper wrote: > Hi All > =20 > I was wondering if I could get some advice from those of you who have > successfully implemented ip address failover systems such as carp and > freevrrpd. > =20 > I am trying to set up a high availability web loadbalancer using a pair= > of freebsd 6.2 boxes. I have tried a number of ways to perform failover= > but always seem to be hitting a problem. > =20 > UCARP > Pro's:This would be my ideal solution as the startup/shutdown scripts > enable me to stop and start my applications and add aliases to adaptors= > easily. > Cons: When the backup box is rebooted it always comes up advertising > itself as the master then after a few seconds reverts to backup, > although I was under the impression it was supposed to wait and listen > for advertisements(it doesnt seem to). The backup boxes initial > gratuitous arp as a master is sufficient to poison any traffic from the= > local router to the shared ip address. Only solution was to use arp-sk > to send gratuitous arps every few secs, however, arp-sk was a bit flake= y > and it was a bodge. > =20 > CARP > Pro's: stable and built into the kernel. Could enable acive/active arp > load sharing at a later point. > Cons: There is a Freebsd bug (I've seen it discussed on the lists) wher= e > the creation and destroyal of a carp interface causes a kernel panic. > Also, there is no support for start/stop scripts. > =20 I do not have experience with ucarp and freevrrpd, so I can talk only=20 about CARP :) The bug you are talking is fixed in -CURRENT, and you can trigger it=20 only if you have more then 1 carp interface per host. I fetch changes from -current and made patch for -stable, that seems to=20 work without problems. There are other bugs, and I'm not sure what is their status, but you=20 always can search for PR. I do not think start/stop scripts are problem as average sysadmin can=20 solve this for itself :) > =20 > Freevrrpd > Pros: Mac address changing removes some of the arp timeout > issues/gratuitous arp problems and it supports start/stop scripts > Cons: I'm finding that upon rebooting the backup unit it correctly > starts as a backup, then three seconds later syslogs that it is the > master and changes its mac address accordingly. although a sniff of the= > network traffic indicates it is sending the right advertisements(lower > priority), it never goes into backup mode again. > =20 > So, what am I doing wrong? Are these common problems, or something that= > appears specific to my hosts/switches? are there more suitable options?= > The loadbalancers are all single homed and I have tried a mixture of xl= , > bge and fxp cards. =20 > =20 > Any help/suggestions much appreciated, also, any links to a perl based > gratuitous arp util would be great! > =20 > Many thanks > > Ross=20 > > PS - Apologies if you see multiple copies of this message, I seem to be= > having trouble getting mails onto the list. > > > > All correspondence, attachments and agreements remain strictly subject = to fully executed contract. (c) GCap Media plc 2006. All rights remain re= served. This e-mail (and any attachments) contains information which may = be confidential, subject to intellectual property protection and may be l= egally privileged and protected from disclosure and unauthorised use. It = is intended solely for the use of the individual(s) or entity to whom it = is addressed and others specifically authorised to receive it. If you are= not the intended recipient of this e-mail or any parts of it please tele= phone 020 7054 8000 immediately upon receipt. No other person is authoris= ed to copy, adapt, forward, disclose, distribute or retain this e-mail in= any form without prior specific permission in writing from an authorised= representative of GCap Media plc. We will not accept liability for any c= laims arising as a result of the use of the internet to transmit informat= ion by or to GCap Media plc. > > GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7L= A. Registered in England & Wales with No. 923454 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > =20 P.S. the attached patch is little old so I'm not sure it still apply=20 cleanly to the latest -stable :) I tested base functionality with patched carp, but still do not have=20 server in production with it, so be careful! --=20 Best Wishes, Stefan Lambrev ICQ# 24134177 --------------010107000605050406040108 Content-Type: text/plain; name="carp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carp.patch" --- src/sys/netinet/ip_carp.c.orig Thu Feb 1 18:53:55 2007 +++ src/sys/netinet/ip_carp.c Tue Feb 6 18:41:24 2007 @@ -191,7 +191,7 @@ static void carp_input_c(struct mbuf *, struct carp_header *, sa_family_t); static int carp_clone_create(struct if_clone *, int); static void carp_clone_destroy(struct ifnet *); -static void carpdetach(struct carp_softc *); +static void carpdetach(struct carp_softc *, int); static int carp_prepare_ad(struct mbuf *, struct carp_softc *, struct carp_header *); static void carp_send_ad_all(void); @@ -406,9 +406,7 @@ if (sc->sc_carpdev) CARP_SCLOCK(sc); - carpdetach(sc); - if (sc->sc_carpdev) - CARP_SCUNLOCK(sc); + carpdetach(sc, 1); /* Returns unlocked. */ mtx_lock(&carp_mtx); LIST_REMOVE(sc, sc_next); @@ -420,7 +418,7 @@ } static void -carpdetach(struct carp_softc *sc) +carpdetach(struct carp_softc *sc, int unlock) { struct carp_if *cif; @@ -450,9 +448,10 @@ sc->sc_carpdev->if_carp = NULL; CARP_LOCK_DESTROY(cif); FREE(cif, M_IFADDR); - } + } else if (unlock) + CARP_UNLOCK(cif); + sc->sc_carpdev = NULL; } - sc->sc_carpdev = NULL; } /* Detach an interface from the carp. */ @@ -471,7 +470,7 @@ CARP_LOCK(cif); for (sc = TAILQ_FIRST(&cif->vhif_vrs); sc; sc = nextsc) { nextsc = TAILQ_NEXT(sc, sc_list); - carpdetach(sc); + carpdetach(sc, 0); } } --------------010107000605050406040108-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 11:37:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D646D16A400 for ; Tue, 27 Mar 2007 11:37:26 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.freebsd.org (Postfix) with ESMTP id 33CDF13C45E for ; Tue, 27 Mar 2007 11:37:25 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from [89.190.198.138] (account jgordeev HELO [10.102.9.50]) by dir.bg (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 1658265 for freebsd-net@freebsd.org; Tue, 27 Mar 2007 13:37:25 +0300 Message-ID: <4608F3B2.3000609@dir.bg> Date: Tue, 27 Mar 2007 13:36:34 +0300 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20070109 X-Accept-Language: bg, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <3DDDCC38D00FA545A6C012475EF2DC0302AF85DF@LQEVS1.gcapmedia.com> In-Reply-To: <3DDDCC38D00FA545A6C012475EF2DC0302AF85DF@LQEVS1.gcapmedia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 11:37:26 -0000 On OpenBSD web server load balancing is achieved using PF + hoststated. Using CARP is not appropriate as is noted in the (FreeBSD) man page. I think VRRP is also not appropriate. Ross Draper wrote: > Hi All > > I was wondering if I could get some advice from those of you who have > successfully implemented ip address failover systems such as carp and > freevrrpd. > > I am trying to set up a high availability web loadbalancer using a pair > of freebsd 6.2 boxes. I have tried a number of ways to perform failover > but always seem to be hitting a problem. > > UCARP > Pro's:This would be my ideal solution as the startup/shutdown scripts > enable me to stop and start my applications and add aliases to adaptors > easily. > Cons: When the backup box is rebooted it always comes up advertising > itself as the master then after a few seconds reverts to backup, > although I was under the impression it was supposed to wait and listen > for advertisements(it doesnt seem to). The backup boxes initial > gratuitous arp as a master is sufficient to poison any traffic from the > local router to the shared ip address. Only solution was to use arp-sk > to send gratuitous arps every few secs, however, arp-sk was a bit flakey > and it was a bodge. > > CARP > Pro's: stable and built into the kernel. Could enable acive/active arp > load sharing at a later point. > Cons: There is a Freebsd bug (I've seen it discussed on the lists) where > the creation and destroyal of a carp interface causes a kernel panic. > Also, there is no support for start/stop scripts. > > Freevrrpd > Pros: Mac address changing removes some of the arp timeout > issues/gratuitous arp problems and it supports start/stop scripts > Cons: I'm finding that upon rebooting the backup unit it correctly > starts as a backup, then three seconds later syslogs that it is the > master and changes its mac address accordingly. although a sniff of the > network traffic indicates it is sending the right advertisements(lower > priority), it never goes into backup mode again. > > So, what am I doing wrong? Are these common problems, or something that > appears specific to my hosts/switches? are there more suitable options? > The loadbalancers are all single homed and I have tried a mixture of xl, > bge and fxp cards. > > Any help/suggestions much appreciated, also, any links to a perl based > gratuitous arp util would be great! > > Many thanks > > Ross > > PS - Apologies if you see multiple copies of this message, I seem to be > having trouble getting mails onto the list. > > > > All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. > > GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England & Wales with No. 923454 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 13:11:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C5F316A402 for ; Tue, 27 Mar 2007 13:11:15 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id 16F5213C469 for ; Tue, 27 Mar 2007 13:11:15 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 9135E7E82F; Tue, 27 Mar 2007 16:11:13 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sicp+0Y8C0nl; Tue, 27 Mar 2007 16:11:03 +0300 (EEST) Received: from [10.132.4.235] (unknown [10.132.4.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 8DD8E7E829; Tue, 27 Mar 2007 16:11:03 +0300 (EEST) Message-ID: <460917E6.1060604@net.utcluj.ro> Date: Tue, 27 Mar 2007 16:11:02 +0300 From: Cristian KLEIN Organization: Data Communication Center - Technical University of Cluj-Napoca User-Agent: Icedove 1.5.0.7 (X11/20061013) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46081CB9.6030109@net.utcluj.ro> <460839E1.8080408@FreeBSD.org> In-Reply-To: <460839E1.8080408@FreeBSD.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: GRE with key X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 13:11:15 -0000 Hi, Thank you for your quick reply. Bruce M. Simpson wrote: > Cristian KLEIN wrote: >> Hello everybody, >> >> I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid >> questions. >> >> I would like to add key support to gre(4). I have already been able to >> use gre(4) with a hardcoded key. The single thing remaining to do is to >> transfer the key from ifconfig(8). The key is an uint32_t and I haven't >> found a way to transfer it without modifying ifconfig(8). >> > Excellent. Thanks for volunteering to do this! I just wanted to be able to use the OS I like. ;) >> My question is, which is the "BSD-style" to achieve the above? Solutions >> I came up with are as follows: >> 1) Use SIOCSDRVSPEC / SIOCGDRVSPEC >> 2) Add SIOCSGREKEY / SIOCGGREKEY >> 3) [Probably to ugly to be mentioned, but requires fairy few >> modifications.] Add a sysctl MIB which is read when calling "ifconfig >> ... create". >> > If I were doing this, I would add the code to ifconfig.c where the other > tunnel stuff lives, and go for option number 2. Feel free to modify > ifconfig to accomodate the the new options. I have added GREGKEY / GRESKEY in if_gre.h and included this file in ifconfig.c. >> Another thing I wanted to ask is, which function of ifconfig(8) should I >> modify to display the GRE key? >> > Look at how af_status_tunnel() works and consider adding it there. I have included key displaying in status() because it is af independent. Please review the patch, so I can PR it. The patch is against RELENG_6_2. Could someone check whether it works on HEAD? http://users.utcluj.ro/~cristiklein/patches/grekey.patch One note: gre(4) still ignores incomming keys (i.e. accepts any incomming key) and I think that is quite okey, because they are deprecated in RFC2784. However, should someone find it useful, I am willing to implement it, for the sake of correctness. I have tested the current implementation against both a Cisco router and a Linux box, so it should work for everybody. Thank you for your help! From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:29:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6374616A402 for ; Tue, 27 Mar 2007 14:29:18 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1324513C48C for ; Tue, 27 Mar 2007 14:29:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=cvWCXdO7YHDnuMOOybXk6H5fVF886lX0XdwMcgjd0TEL6WnrqQuiSjppseE+//KeCNHlI/Q1qx/fBganUambZB9q8KeZ4ZCXt5CgE29S/VPNEb3uJxWhSyOMmfRP22CJ5lR1kgKHNdguwSTvyPRPoBT/Tq5kxSK52bkkGeCsdYM=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HWCff-000DqX-T5; Tue, 27 Mar 2007 18:29:12 +0400 Date: Tue, 27 Mar 2007 18:29:07 +0400 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070327142907.GH14837@codelabs.ru> References: <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> <20070318051709.GE82045@codelabs.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="I3tAPq1Rm2pUxvsp" Content-Disposition: inline In-Reply-To: <20070318051709.GE82045@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, rik@inse.ru Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:29:18 -0000 --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Good day. Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote: > You're right, thanks for spotting the error. The corrected patch > is attached. After some iterations with rik@ we came to a next version of an if_bridge.4 patch. Comments are welcome. -- Eygene --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_bridge.4.diff" --- if_bridge.4.orig Sun Mar 4 15:37:22 2007 +++ if_bridge.4 Tue Mar 27 18:25:52 2007 @@ -82,6 +82,13 @@ .Nm interface randomly chooses a link (MAC) address in the range reserved for locally administered addresses when it is created. +This address is guaranteed to be unique +.Em only +across all +.Nm if_bridge +interfaces on the local machine. +Thus you can theoretically have two +bridges on the different machines with the same link addresses. The address can be changed by assigning the desired link address using .Xr ifconfig 8 . .Pp @@ -219,9 +226,89 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table. +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. There are situations when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). +It is not possible to distinguish between these interfaces using +their MAC address, excluding the case when the packet's destination +MAC address is equal to the MAC address of the interface on which +the packet was entered to the system. +In this case the filter will see the incoming packet on this +interface. +In all other cases the interface seen by the packet filter is chosen +from the list of bridge members with the same MAC address and the +result strongly depends on the member addition sequence and the +actual implementation of +.Nm if_bridge . +It is not recommended to rely on the order chosen by the current +.Nm if_bridge +implementation: it can be changed in the future. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let +.Bl -bullet +.It +the MAC address of the incoming packet's destination is +.Nm nn:nn:nn:nn:nn:nn , +.It +the interface on which packet entered the system is +.Nm ifX , +.It +.Nm ifX +MAC address is +.Nm xx:xx:xx:xx:xx:xx , +.It +there are possibly other bridge members with the same MAC address +.Nm xx:xx:xx:xx:xx:xx , +.It +the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. +.El +.Pp +Then if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm ifX +no matter if there are any other bridge members carrying the same +MAC address. +But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is one of the +.Nm vlanYn . +It is not possible to predict the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. +So if one wants the filter the locally destined packets based on +their interface name, one should be aware of this implication. +The described situation will appear at least on the filtering bridges +that are doing IP-forwarding; in some of such cases it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. +But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf --I3tAPq1Rm2pUxvsp-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:29:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C39A516A400 for ; Tue, 27 Mar 2007 14:29:47 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [217.69.20.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4A46013C4BA for ; Tue, 27 Mar 2007 14:29:46 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from rly35d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly35d.srv.mailcontrol.com (MailControl) with ESMTP id l2RETdwE000775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2007 15:29:41 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly35d.srv.mailcontrol.com (MailControl) id l2RET7U9031667 for freebsd-net@freebsd.org; Tue, 27 Mar 2007 15:29:07 +0100 Received: from lqm4.gcapmedia.com (no-dns-yet.demon.co.uk [194.70.58.205]) by rly35d-eth0.srv.mailcontrol.com (envelope-sender Ross.Draper@gcapmedia.com) (MIMEDefang) with ESMTP id l2RERaId025748; Tue, 27 Mar 2007 15:29:07 +0100 (BST) Received: from LQEVS1.gcapmedia.com ([10.73.2.12]) by lqm4.gcapmedia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 15:28:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Mar 2007 15:28:42 +0100 Message-ID: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vrrp/CARP/ucarp Problems Thread-Index: AcdwfDhLzQL3SxzoRz+Dnho4zBw/Fg== From: "Ross Draper" To: X-OriginalArrivalTime: 27 Mar 2007 14:28:43.0557 (UTC) FILETIME=[38DC5D50:01C7707C] X-Scanned-By: MailControl A-07-06-90 (www.mailcontrol.com) on 10.68.1.145 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:29:47 -0000 Hi =20 Firstly, many thanks to Stefan (who provided me a diff of the CURRENT update) and Bruce for advising me that the "multiple CARP interface destroy" bug is fixed in CURRENT. =20 Jordan, thanks for your reply, but I cant find a reference to CARP being unsuitable for this purpose in the CARP man page, have I perhaps misunderstood you? I also did a quick search of the freebsd.org site and cant find any mention of it being an issue - If you could provide me with a link I'd be grateful. =20 Further to this, I have been in the office today performing local testing as opposed to remote testing and have noticed that when both machines in the cluster are using xl network cards, failover etc seems fine. However, when having one node using xl and the other using em/bge I can see the em or bge card physically go down after it reverts to backup mode, then come back up and goto master. (this wasnt displaying in the messages log, but was obvious on the console). I believe that this down period is sufficient for it to miss the remaining advertisements and believe it is the master again. For some reason it doesnt seem to ever remove the mac address or recover after this point, but I'm not particularly suprised. Not sure how to take this further, but I'll continue fiddling. =20 Many thanks =20 Ross =20 =20 =20 All correspondence, attachments and agreements remain strictly subject to f= ully executed contract. (c) GCap Media plc 2006. All rights remain reserved= . This e-mail (and any attachments) contains information which may be confi= dential, subject to intellectual property protection and may be legally pri= vileged and protected from disclosure and unauthorised use. It is intended = solely for the use of the individual(s) or entity to whom it is addressed a= nd others specifically authorised to receive it. If you are not the intende= d recipient of this e-mail or any parts of it please telephone 020 7054 800= 0 immediately upon receipt. No other person is authorised to copy, adapt, f= orward, disclose, distribute or retain this e-mail in any form without prio= r specific permission in writing from an authorised representative of GCap = Media plc. We will not accept liability for any claims arising as a result = of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. = Registered in England & Wales with No. 923454 From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:31:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 903FB16A400 for ; Tue, 27 Mar 2007 14:31:43 +0000 (UTC) (envelope-from maarten.verbeek@ordina.be) Received: from mail.ordina.be (mail.ordina.be [212.35.120.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD5B13C448 for ; Tue, 27 Mar 2007 14:31:40 +0000 (UTC) (envelope-from maarten.verbeek@ordina.be) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Mar 2007 16:23:25 +0200 Message-ID: <484EC6860B1EB041A54358540C0AA2D603298590@ordexchange.ordina.belgium> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD router Thread-Index: Acdwe3sS6Ds/s7D1QkadocqYi3kuBA== From: "Verbeek, Maarten" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:31:43 -0000 Hi, =20 i'm busy creating a a http-proxy server/router with FreeBSD 6.2, but somewhere along the line i'm doing things wrong i think. =20 situation: network 172.45.x.x/12 -----FREEBSD ROUTER ----- 192.168.3.x/16 ------ firewall. =20 The defaultroute will be the ip-adress of the firewall, being 192.168.3.1. i won't be needing a firewall or NAT on the machine, since the only traffic to the internet will be HTTP and that will be handled by the proxy server. =20 But all the howto's handle firewalls and HTTP. Anyone knows a good page with information on doing this without a firewall and NAT. =20 Kind Regards =20 Maarten Verbeek =20 From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:47:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1692B16A406 for ; Tue, 27 Mar 2007 14:47:56 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.freebsd.org (Postfix) with ESMTP id 45D7113C46A for ; Tue, 27 Mar 2007 14:47:54 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from [89.190.198.138] (account jgordeev HELO [10.102.9.50]) by dir.bg (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 1705814; Tue, 27 Mar 2007 17:47:51 +0300 Message-ID: <46092E46.4090502@dir.bg> Date: Tue, 27 Mar 2007 17:46:30 +0300 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20070109 X-Accept-Language: bg, en MIME-Version: 1.0 To: Ross Draper References: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> In-Reply-To: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:47:56 -0000 The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Ross Draper wrote: > Hi > > Firstly, many thanks to Stefan (who provided me a diff of the CURRENT > update) and Bruce for advising me that the "multiple CARP interface > destroy" bug is fixed in CURRENT. > > Jordan, thanks for your reply, but I cant find a reference to CARP > being unsuitable for this purpose in the CARP man page, have I perhaps > misunderstood you? I also did a quick search of the freebsd.org site > and cant find any mention of it being an issue - If you could provide > me with a link I'd be grateful. > > Further to this, I have been in the office today performing local > testing as opposed to remote testing and have noticed that when both > machines in the cluster are using xl network cards, failover etc seems > fine. However, when having one node using xl and the other using > em/bge I can see the em or bge card physically go down after it > reverts to backup mode, then come back up and goto master. (this wasnt > displaying in the messages log, but was obvious on the console). I > believe that this down period is sufficient for it to miss the > remaining advertisements and believe it is the master again. For some > reason it doesnt seem to ever remove the mac address or recover after > this point, but I'm not particularly suprised. Not sure how to take > this further, but I'll continue fiddling. > > Many thanks > > Ross > > > > > > All correspondence, attachments and agreements remain strictly subject > to fully executed contract. > > (c) GCap Media plc 2006. All rights remain reserved. > > This e-mail (and any attachments) contains information which may be > confidential, subject to intellectual property protection and may be > legally privileged and protected from disclosure and unauthorised use. > It is intended solely for the use of the individual(s) or entity to > whom it is addressed and others specifically authorised to receive it. > If you are not the intended recipient of this e-mail or any parts of > it please telephone 020 7054 8000 immediately upon receipt. > > No other person is authorised to copy, adapt, forward, disclose, > distribute or retain this e-mail in any form without prior specific > permission in writing from an authorised representative of GCap Media plc. > > We will not accept liability for any claims arising as a result of the > use of the internet to transmit information by or to GCap Media plc. > > *GCap Media plc. Registered address: 30 Leicester Square, London WC2H > 7LA. Registered in England & Wales with No. 923454* > From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:55:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D772616A403 for ; Tue, 27 Mar 2007 14:55:40 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) by mx1.freebsd.org (Postfix) with ESMTP id D5D6A13C489 for ; Tue, 27 Mar 2007 14:55:39 +0000 (UTC) (envelope-from Ross.Draper@gcapmedia.com) Received: from rly05b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly05b.srv.mailcontrol.com (MailControl) with ESMTP id l2REtXdY009144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2007 15:55:34 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly05b.srv.mailcontrol.com (MailControl) id l2REt8vV007929 for freebsd-net@freebsd.org; Tue, 27 Mar 2007 15:55:08 +0100 Received: from lqm4.gcapmedia.com (no-dns-yet.demon.co.uk [194.70.58.205]) by rly05b-eth0.srv.mailcontrol.com (envelope-sender Ross.Draper@gcapmedia.com) (MIMEDefang) with ESMTP id l2REsTA4005829; Tue, 27 Mar 2007 15:55:08 +0100 (BST) Received: from LQEVS1.gcapmedia.com ([10.73.2.12]) by lqm4.gcapmedia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 15:53:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Mar 2007 15:52:59 +0100 Message-ID: <3DDDCC38D00FA545A6C012475EF2DC0302AF8FD5@LQEVS1.gcapmedia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vrrp/CARP/ucarp Problems Thread-Index: AcdwfyBjSvCZRzrFTeusf4w4qjeP2gAABAkQ From: "Ross Draper" To: "Jordan Gordeev" X-OriginalArrivalTime: 27 Mar 2007 14:53:00.0904 (UTC) FILETIME=[9D81DE80:01C7707F] X-Scanned-By: MailControl A-07-06-85 (www.mailcontrol.com) on 10.66.1.115 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: RE: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 14:55:41 -0000 Ah... I see your point, thankyou for clarifying. =20 =20 Sorry, this is down to me only explaining half the story. The actual loadbalancing will be performed by HAProxy, I require carp or freevrrp to enable "a clustered pair" of loadbalancers.=20 =20 I did toy with the idea arp balancing to enable greater throughput in an active/active scenario, but as you say mention this is not suitable for certain deployments. =20 Kind Regards =20 Ross ________________________________ From: Jordan Gordeev [mailto:jgordeev@dir.bg]=20 Sent: Tuesday, March 27, 2007 3:47 PM To: Ross Draper Cc: freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Ross Draper wrote:=20 Hi =09 Firstly, many thanks to Stefan (who provided me a diff of the CURRENT update) and Bruce for advising me that the "multiple CARP interface destroy" bug is fixed in CURRENT. =09 Jordan, thanks for your reply, but I cant find a reference to CARP being unsuitable for this purpose in the CARP man page, have I perhaps misunderstood you? I also did a quick search of the freebsd.org site and cant find any mention of it being an issue - If you could provide me with a link I'd be grateful. =09 Further to this, I have been in the office today performing local testing as opposed to remote testing and have noticed that when both machines in the cluster are using xl network cards, failover etc seems fine. However, when having one node using xl and the other using em/bge I can see the em or bge card physically go down after it reverts to backup mode, then come back up and goto master. (this wasnt displaying in the messages log, but was obvious on the console). I believe that this down period is sufficient for it to miss the remaining advertisements and believe it is the master again. For some reason it doesnt seem to ever remove the mac address or recover after this point, but I'm not particularly suprised. Not sure how to take this further, but I'll continue fiddling. =09 Many thanks =09 Ross =09 =09 =09 All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England & Wales with No. 923454 From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 16:26:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA4C916A40F for ; Tue, 27 Mar 2007 16:26:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.44]) by mx1.freebsd.org (Postfix) with ESMTP id 273F913C4BC for ; Tue, 27 Mar 2007 16:26:27 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 13281 invoked from network); 27 Mar 2007 15:59:46 -0000 Received: from unknown (HELO localhost) (775067@[217.50.145.147]) (envelope-sender ) by smtprelay06.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 27 Mar 2007 15:59:46 -0000 Date: Tue, 27 Mar 2007 17:59:38 +0200 From: Fabian Keil To: "Verbeek, Maarten" Message-ID: <20070327175938.410a44f1@localhost> In-Reply-To: <484EC6860B1EB041A54358540C0AA2D603298590@ordexchange.ordina.belgium> References: <484EC6860B1EB041A54358540C0AA2D603298590@ordexchange.ordina.belgium> X-Mailer: Claws Mail 2.8.0 (GTK+ 2.10.9; i386-portbld-freebsd6.2) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_MLIdw/y4w5fjndNeJrwz=oi"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:26:28 -0000 --Sig_MLIdw/y4w5fjndNeJrwz=oi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Verbeek, Maarten" wrote: > i'm busy creating a a http-proxy server/router with FreeBSD 6.2, but > somewhere along the line i'm doing things wrong i think. What exactly did you do so far and how is it failing? =20 > situation: network 172.45.x.x/12 -----FREEBSD ROUTER ----- > 192.168.3.x/16 ------ firewall. > =20 > The defaultroute will be the ip-adress of the firewall, being > 192.168.3.1. The defaultroute on which system? > i won't be needing a firewall or NAT on the machine, since the only > traffic to the internet will be HTTP and that will be handled by the > proxy server. >=20 > But all the howto's handle firewalls and HTTP. Anyone knows a good page > with information on doing this without a firewall and NAT. It's not clear to me what exactly you're trying to do. Which systems are supposed to use the proxy? Are these systems configured to use the proxy or should the proxy intercept their requests? Which proxy do you use? Building a router and a http proxy are two different problems and maybe you should solve them one at the time. Fabian=20 --Sig_MLIdw/y4w5fjndNeJrwz=oi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGCT9qBYqIVf93VJ0RApk1AKCL4hbf4b16Tnhs+6cE4dN3YghfuQCgr/q3 NJmsWvJ3TkdOXjocKnHXXVE= =PmrA -----END PGP SIGNATURE----- --Sig_MLIdw/y4w5fjndNeJrwz=oi-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 16:49:52 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930D416A478 for ; Tue, 27 Mar 2007 16:49:52 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 230E413C45E for ; Tue, 27 Mar 2007 16:49:51 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l2RGWVcC077790 for ; Tue, 27 Mar 2007 20:32:32 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Tue, 27 Mar 2007 20:32:31 +0400 (MSD) From: Maxim Konovalov To: net@freebsd.org Message-ID: <20070327202749.F89187@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: bin/110933: [traceroute] minimal wait time should be 1 sec, not 2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:49:52 -0000 Hi, Are there any ideas why traceroute requires waittime >=2 seconds? The only place it used is select(2) timeout. -- Maxim Konovalov ---------- Forwarded message ---------- Date: Tue, 27 Mar 2007 19:44:54 +0400 (MSD) From: Dmitry Marakasov To: FreeBSD-gnats-submit@freebsd.org Subject: bin/110933: [traceroute][patch] minimal wait time should be 1 sec, not 2 Resent-Date: Tue, 27 Mar 2007 15:50:09 GMT Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) Resent-To: freebsd-bugs@freebsd.org [...] In traceroute utility, minimal time to wait for reply is 2 seconds. That's annoying, because system administrators often need traceroute to skip hosts that do not respond faster, but when specifying obvious wait time as 1 sec, they get an error. I see no reason for minimal wait time to be 2 sec, the patch attached lowers limit to well expected 1 second. >How-To-Repeat: 1) traceroute -w1 somehost traceroute: wait time must be > 1 2) ?! >Fix: --- traceroute.patch begins here --- --- src/contrib/traceroute/traceroute.c.orig Tue Mar 27 19:34:53 2007 +++ src/contrib/traceroute/traceroute.c Tue Mar 27 19:35:00 2007 @@ -608,7 +608,7 @@ case 'w': waittime = str2val(optarg, "wait time", - 2, 24 * 60 * 60); + 1, 24 * 60 * 60); break; case 'z': --- traceroute.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 18:14:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57E1516A403 for ; Tue, 27 Mar 2007 18:14:45 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 133F913C465 for ; Tue, 27 Mar 2007 18:14:44 +0000 (UTC) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id 577F233C4C; Tue, 27 Mar 2007 22:14:42 +0400 (MSD) Message-ID: <46096078.4000909@inse.ru> Date: Tue, 27 Mar 2007 22:20:40 +0400 From: Roman Kurakin User-Agent: Thunderbird 1.5.0.7 (X11/20061110) MIME-Version: 1.0 To: Eygene Ryabinkin References: <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> <20070318051709.GE82045@codelabs.ru> <20070327142907.GH14837@codelabs.ru> In-Reply-To: <20070327142907.GH14837@codelabs.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 18:14:45 -0000 Eygene Ryabinkin wrote: > Good day. > > Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote: > >> You're right, thanks for spotting the error. The corrected patch >> is attached. >> > > After some iterations with rik@ we came to a next version of an > if_bridge.4 patch. Comments are welcome. > If there is no objections, I'll wait till the weekend and commit this patch to finally close the PR. Eygene what about the next patch for physically input filtration? I guess we need a separate PR and a thread here for it. rik From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 20:47:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 401D416A400 for ; Tue, 27 Mar 2007 20:47:31 +0000 (UTC) (envelope-from ross@virtualgeek.net) Received: from achilles.virtualgeek.net (perseus.demon.co.uk [83.104.128.109]) by mx1.freebsd.org (Postfix) with ESMTP id B9C4613C4CC for ; Tue, 27 Mar 2007 20:47:30 +0000 (UTC) (envelope-from ross@virtualgeek.net) Received: from virtualgeek.net (achilles.virtualgeek.net [127.0.0.1]) by achilles.virtualgeek.net (Postfix) with ESMTP id 66A46104B37; Mon, 26 Mar 2007 08:31:21 +0100 (BST) Received: from 83.104.128.109 (SquirrelMail authenticated user ross.virtualgeek) by virtualgeek.net with HTTP; Mon, 26 Mar 2007 08:31:21 +0100 (BST) Message-ID: <31629.83.104.128.109.1174894281.squirrel@virtualgeek.net> Date: Mon, 26 Mar 2007 08:31:21 +0100 (BST) From: "Ross Draper" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: carp/vrrp/ucarp advice X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 20:47:31 -0000 Hi guys I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always seems to come up advertising itself as the master, then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to)to see if a master exists. Its initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitus arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements, it never goes into backup mode again and keeps the virtual mac address. So, what am I doing wrong? are there more suitable options? the loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards. Also, any links to a perl based gratuitous arp utils would be great Any help/suggestions much appreciated. Ross PS - I mailed this to freebsd-cluster earlier but it didnt seem to make it onto the list - apologies if this ends up as a cross post. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:43:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA75E16A404 for ; Tue, 27 Mar 2007 21:43:36 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1A90213C458 for ; Tue, 27 Mar 2007 21:43:33 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.236.62]) (authenticated bits=128) by parrot.aev.net (8.14.0/8.13.8) with ESMTP id l2RLNS6N052506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Mar 2007 23:23:34 +0200 (CEST) (envelope-from ml@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l2RLFGqB026160; Tue, 27 Mar 2007 23:15:16 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <46098962.3040707@netfence.it> Date: Tue, 27 Mar 2007 23:15:14 +0200 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Jordan Gordeev References: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> <46092E46.4090502@dir.bg> In-Reply-To: <46092E46.4090502@dir.bg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org, Ross Draper Subject: Re: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 21:43:37 -0000 Jordan Gordeev wrote: > The only load balancing that CARP supports, to my knowledge, is ARP > level load balancing. From carp(4): > The ARP load balancing has some limitations. First, ARP balancing only > works on the local network segment. It cannot balance traffic that > crosses a router, because the router itself will always be balanced to > the same virtual host. Forgive me for stepping in, but I had read the above statement over and over trying to figure what it meant; perhaps it's not so clear... If I understood it correctly it's not saying you should not use CARP on routers. Instead it's meaning that load-balancing won't cross a third router which is on cascade of the two CARP routers. An image might help to clarify: +------+ +------+ +------+ .... +------+ |host I| |host J| |host K| .... |host Z| +------+ +------+ +------+ .... +------+ | | | | \--------+--------+-------------+---------\ | +------+ +------+ +------+ .... +------+ +--------+ |host A| |host B| |host C| .... |host H| |Router 3| +------+ +------+ +------+ .... +------+ +--------+ | | | | | \--------+-----+--+-------+-----+---------/ | | +--------+ +--------+ |Router 1| |Router 2| +--------+ +--------+ Suppose you are arp-balancing with CARP on Router 1 & 2, hosts A-H will get balanced, but hosts I-Z will all go to the same router (wether Router 1 or Router 2). This is because all their incoming packets will bear Router 3's MAC address. Is this interpretation correct? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 00:43:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A414F16A400 for ; Wed, 28 Mar 2007 00:43:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 68A6B13C45D for ; Wed, 28 Mar 2007 00:43:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6F2D820CB65; Tue, 27 Mar 2007 20:43:11 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 27 Mar 2007 20:43:11 -0400 X-Sasl-enc: /JV+OR/jMZl7X3LZ27UJk6cYXPK6QKzE9x7Rr/Fip4f/ 1175042591 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BF1A21A101; Tue, 27 Mar 2007 20:43:10 -0400 (EDT) Message-ID: <4609BA1C.3060405@FreeBSD.org> Date: Wed, 28 Mar 2007 01:43:08 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Andrea Venturoli References: <3DDDCC38D00FA545A6C012475EF2DC0302AF8F55@LQEVS1.gcapmedia.com> <46092E46.4090502@dir.bg> <46098962.3040707@netfence.it> In-Reply-To: <46098962.3040707@netfence.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jordan Gordeev , Ross Draper , freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 00:43:11 -0000 Andrea Venturoli wrote: > Jordan Gordeev wrote: >> The only load balancing that CARP supports, to my knowledge, is ARP >> level load balancing. From carp(4): >> The ARP load balancing has some limitations. First, ARP balancing only >> works on the local network segment. It cannot balance traffic that >> crosses a router, because the router itself will always be >> balanced to >> the same virtual host. > > Forgive me for stepping in, but I had read the above statement over > and over trying to figure what it meant; perhaps it's not so clear... > > If I understood it correctly it's not saying you should not use CARP > on routers. Instead it's meaning that load-balancing won't cross a > third router which is on cascade of the two CARP routers. ... Andrea, you are correct. Jordan is pointing out the main limitation of CARP, which is that it operates only within a broadcast domain. I should point out such a feature is out of scope for VRRP, CARP, IPMP or other Layer 2 IP sharing protocol. However this behaviour is just fine for load balancing a router, in which case one relies on next-hop reachability anyway. The thing to remember with CARP is that it relies on the ability of the interface to go into promiscuous mode to pick up traffic for its virtual MAC addresses. More modern cards may support more than one station address in hardware, which avoids the need for promiscuous mode processing, however we don't currently support this hardware feature. If one wishes to load balance across Layer 3 hops (rather than within the same broadcast domain), what one is asking for is a feature like BGP4 Anycast, IPv6 Anycast, or OSPF-based Anycast which relies on cooperating routers to inject a route into the Layer 3 routing domain for a given 'virtual' IP address. There is a daemon out there which uses the OSPF API in Quagga to flood OSPF domains with virtual host routes for anycasting services using Opaque LSAs but I forget its name. XORP has the potential to do the same but requires some development effort to do so. If one wishes to load balance specific requests for an application layer service, one enters the wonderful world of 'middleware' and competing commercial solutions to the problem. And this is where money comes into play... Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 05:26:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 881AF16A402 for ; Wed, 28 Mar 2007 05:26:55 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 495EC13C45B for ; Wed, 28 Mar 2007 05:26:55 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2588165ana for ; Tue, 27 Mar 2007 22:26:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=FMs4qzMpWhJQAeMtaauRVJxFpIUxVsdFgraZrnnO7WS3pDIbllWbYbR29AYijY1jokLShWlJKSbyt0wtxz/QMI6ehLlbYkaM3JJ3kR9U33ViLBsxn/BhDc/kpyphVegraF7n38aQQt1Ct4lO4EHxgdN2nzMSfGN/bxLF41qQELw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jnECr7mnflWyAPUqtiq79+8QdONq9R5cI3rDEfV5SFnGldhfAR4ihjzGvuOEnTP4uSihngmk1UZxdkMdje4GH3kCOJu9gs8+4JKBiQxMYgtI6Y63Njfg0t4AVqy1vtT6nNQUE85oDssnlf4jJof+Joq9g1wuv21hzOs59ez97pk= Received: by 10.100.33.14 with SMTP id g14mr54931ang.1175059614270; Tue, 27 Mar 2007 22:26:54 -0700 (PDT) Received: by 10.100.167.12 with HTTP; Tue, 27 Mar 2007 22:26:54 -0700 (PDT) Message-ID: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> Date: Wed, 28 Mar 2007 13:26:54 +0800 From: "Zhu Yan" To: freebsd-net@freebsd.org, freebsd-python@freebsd.org, freebsd-bugs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: The broadcast of python in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 05:26:55 -0000 Hi, Everybody. In FreeBSD, I write a program in python(2.4.4 & 2.5), which include a broadcast routine. But, I send the broadcast in FreeBSD, it's different from others OS, like Windows, Linux... When I send the broadcast in FreeBSD with address 255.255.255.255, the packet can not be received by other OS. But I send the broadcast in non-BSD System with address 255.255.255.255, all OS got it. When I send the broadcast in FreeBSD with address like 192.168.1.255, all OS got it. I have seen the Python socket implement, there is no added option for FreeBSD, but why? Why it is different? From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 05:45:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 191B516A406 for ; Wed, 28 Mar 2007 05:45:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C158E13C4B8 for ; Wed, 28 Mar 2007 05:45:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=kB1YAFVOOxhg6fKQrqy8+r7UkFgU3Y4Yab83jxQRlIKJFYq5ZG2g9jdRcbnSP5Q6pD0HOFiTZwKOMbD4LrC8feoiowGW1e/2gKW1umeb0iEnpFYEq8VL51W0NgyAphUwyfP7ZGqB4qDQym0Ay30HNoL/1ASQv993JJzJJR74eLM=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HWQxu-000F0i-VT; Wed, 28 Mar 2007 09:44:59 +0400 Date: Wed, 28 Mar 2007 09:44:54 +0400 From: Eygene Ryabinkin To: Roman Kurakin Message-ID: <20070328054454.GN14837@codelabs.ru> References: <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> <20070318051709.GE82045@codelabs.ru> <20070327142907.GH14837@codelabs.ru> <46096078.4000909@inse.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46096078.4000909@inse.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 05:45:04 -0000 Tue, Mar 27, 2007 at 10:20:40PM +0400, Roman Kurakin wrote: > Eygene what about the next patch for physically input filtration? > I guess we need a separate PR and a thread here for it. Yes, I will port it to the new if_bridge.c. The end of this week is a good estimate for the patching and testing timeline from my side. Will open a PR once the new patch will work for me. -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 06:24:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 872AB16A402 for ; Wed, 28 Mar 2007 06:24:58 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 2874813C48C for ; Wed, 28 Mar 2007 06:24:57 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 968631B10F1D; Wed, 28 Mar 2007 08:24:56 +0200 (CEST) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 92B551B10F1B; Wed, 28 Mar 2007 08:24:56 +0200 (CEST) Message-ID: <460A0A38.7000607@sun-fish.com> Date: Wed, 28 Mar 2007 09:24:56 +0300 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: Zhu Yan References: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> In-Reply-To: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, freebsd-python@freebsd.org Subject: Re: The broadcast of python in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stefan.lambrev@sun-fish.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 06:24:58 -0000 Hi, Zhu Yan wrote: > Hi, Everybody. > > In FreeBSD, I write a program in python(2.4.4 & 2.5), which include a > broadcast routine. > > But, I send the broadcast in FreeBSD, it's different from others OS, like > Windows, Linux... > > When I send the broadcast in FreeBSD with address 255.255.255.255, the > packet can not be received by other OS. > > But I send the broadcast in non-BSD System with address > 255.255.255.255, all > OS got it. > > When I send the broadcast in FreeBSD with address like 192.168.1.255, > all OS > got it. > > I have seen the Python socket implement, there is no added option for > FreeBSD, but why? Why it is different? Can you change "sysctl net.inet.icmp.bmcastecho=1" and test again? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 06:57:14 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96E3816A400; Wed, 28 Mar 2007 06:57:14 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6F03613C46C; Wed, 28 Mar 2007 06:57:14 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2S6vEsQ061633; Wed, 28 Mar 2007 06:57:14 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2S6vE46061629; Wed, 28 Mar 2007 06:57:14 GMT (envelope-from remko) Date: Wed, 28 Mar 2007 06:57:14 GMT From: Remko Lodder Message-Id: <200703280657.l2S6vE46061629@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/110959: Filtering incoming packets with enc0 does not work with GIF-based IPSec setups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 06:57:14 -0000 Synopsis: Filtering incoming packets with enc0 does not work with GIF-based IPSec setups Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Mar 28 06:57:07 UTC 2007 Responsible-Changed-Why: Networking issue http://www.freebsd.org/cgi/query-pr.cgi?pr=110959 From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 07:14:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E7E916A402 for ; Wed, 28 Mar 2007 07:14:51 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B544713C448 for ; Wed, 28 Mar 2007 07:14:50 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=HfpBIGia9NV5/k8bOF3MgBjvJo1uFcMJnleSni0G+p69cBLSYzKLmSdMfSY1E2GhbsqVrsU5mC17MJkdYIgw9B9jyEOGx2wxb2QBTO2nJmz3iGSQgpMwBKhOC4GBXWHPFrc2+/OLTATfE7dZufr/ZamlfWBkZ/ZEeDI1i7jP9mc=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HWSMo-000F5H-Ar; Wed, 28 Mar 2007 11:14:46 +0400 Date: Wed, 28 Mar 2007 11:14:41 +0400 From: Eygene Ryabinkin To: Zhu Yan Message-ID: <20070328071441.GO14837@codelabs.ru> References: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, freebsd-python@freebsd.org Subject: Re: The broadcast of python in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 07:14:51 -0000 Zhu, good day. Wed, Mar 28, 2007 at 01:26:54PM +0800, Zhu Yan wrote: > Hi, Everybody. > > In FreeBSD, I write a program in python(2.4.4 & 2.5), which include a > broadcast routine. > > But, I send the broadcast in FreeBSD, it's different from others OS, like > Windows, Linux... > > When I send the broadcast in FreeBSD with address 255.255.255.255, the > packet can not be received by other OS. > > But I send the broadcast in non-BSD System with address 255.255.255.255, all > OS got it. > > When I send the broadcast in FreeBSD with address like 192.168.1.255, all OS > got it. Seems like you will want to read these thread: http://lists.freebsd.org/mailman/htdig/freebsd-net/2007-January/012874.html -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 09:55:14 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F302116A402; Wed, 28 Mar 2007 09:55:13 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id CB0C313C45E; Wed, 28 Mar 2007 09:55:13 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2S9tDmM090358; Wed, 28 Mar 2007 09:55:13 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2S9tDhq090354; Wed, 28 Mar 2007 09:55:13 GMT (envelope-from matteo) Date: Wed, 28 Mar 2007 09:55:13 GMT From: Matteo Riondato Message-Id: <200703280955.l2S9tDhq090354@freefall.freebsd.org> To: matteo@FreeBSD.org, freebsd-net@FreeBSD.org, matteo@FreeBSD.org Cc: Subject: Re: bin/94920: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 09:55:14 -0000 Synopsis: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631 Responsible-Changed-From-To: freebsd-net->matteo Responsible-Changed-By: matteo Responsible-Changed-When: Wed Mar 28 09:53:28 UTC 2007 Responsible-Changed-Why: I'll work on a similar issue for rpc.lockd and I hope to find a solution for rpc.statd too. http://www.freebsd.org/cgi/query-pr.cgi?pr=94920 From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 10:06:50 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 476AF16A401 for ; Wed, 28 Mar 2007 10:06:50 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id D642513C45B for ; Wed, 28 Mar 2007 10:06:49 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so3257916nfc for ; Wed, 28 Mar 2007 03:06:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YWkUYdvkNxep1lXvZYkLNjtUebqT+VOohspHDt/hL4DjapczzA3XIRlOXIIZbgt21wMt18vdjbeP2AMf7Qne9VHeQFHV9Cp9e0OPETVL3GEumf1KkVT/B92967RJbOUoXbvevBs4ChTUI7C4031E3ZOVO99h9r4dOwuU3l5/WT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K6iS9TRtyWf0h6Jy7dod+Eaqn4TWRy+F8QexG4PmEp9SV3ExTMmlKCl4C8toq7/A0JfPi964G2+7OMwEiTL7cGJeweygbG/KkDIv9wD/RuOrfZqtOcBWRqsDTXa5E2+zkUyZht3uaCX3qvpGy0ISsFz3CuWcF6h9B+Q1Wkuyg9w= Received: by 10.82.134.12 with SMTP id h12mr18493694bud.1175074724905; Wed, 28 Mar 2007 02:38:44 -0700 (PDT) Received: by 10.82.187.19 with HTTP; Wed, 28 Mar 2007 02:38:44 -0700 (PDT) Message-ID: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Date: Wed, 28 Mar 2007 11:38:44 +0200 From: "Ulrich Spoerlein" To: current@freebsd.org, net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: NFS write() calls lead to read() calls? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 10:06:50 -0000 Hi, I observe a strange effect, when using the following setup: Three FreeBSD 6.2[1] machines on Gigabit Ethernet using em(4) interfaces. HostC is the NFS server, HostB has /net/share mounted from HostC. I will use HostA and HostB to demonstrate the issue. Picture this: hostA # scp 500MB hostB:/net/share/ Iff the file "500MB" does not yet exist on the NFS share, I can see X MB/s going out of HostA, X MB/s coming in on HostB, X MB/s going out on hostB again and finally X MB/s coming in on HostC. If I run the scp again, I can see X MB/s going out from HostA, 2*X MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's happening is, that HostB issues one NFS READ call for every WRITE call. The traffic flows like this: -----> -----> A B C <----- If I rm(1) the file on the NFS share, then the first scp(1) will not show this behaviour. It is only when overwritting files, that this happens. The real weirdness comes into play, when I simply cp(1) from HostB itself like this: hostB # cp 500MB /net/share/ I can do this over and over again, and _never_ get any noteworthy amount of NFS READ calls, only WRITE. The network traffic is also, as you would expect. Then I tested using ssh(1) instead of scp(1), like this: hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" This works, too. Probably, because sh(1) is truncating the file? So, can someone please explain to me, what is happening and if/how it can be avoided? Cheers, Uli [1] I know this is current, but on stable@ nobody picked up the thread, so I'll try my luck here. From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 10:37:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D44CD16A400; Wed, 28 Mar 2007 10:37:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id A112013C448; Wed, 28 Mar 2007 10:37:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 690F620F9C4; Wed, 28 Mar 2007 06:37:45 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 28 Mar 2007 06:37:44 -0400 X-Sasl-enc: rTb0nKwCdLF6MGzgYhpEP4C5qmRgXsjMdHh9ixm8J1ls 1175078264 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 16E251B288; Wed, 28 Mar 2007 06:37:43 -0400 (EDT) Message-ID: <460A4575.7010709@FreeBSD.org> Date: Wed, 28 Mar 2007 11:37:41 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Zhu Yan References: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> In-Reply-To: <8ae5ea120703272226q39b37660qb2ad25f0f8693a18@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, freebsd-python@freebsd.org Subject: Re: The broadcast of python in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 10:37:44 -0000 Zhu Yan wrote: > > When I send the broadcast in FreeBSD with address 255.255.255.255, the > packet can not be received by other OS. FreeBSD applications need to use the IP_ONESBCAST option to send all-ones broadcasts. See the ip(4) man page. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 23:51:37 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C07316A401; Wed, 28 Mar 2007 23:51:37 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0F23813C459; Wed, 28 Mar 2007 23:51:37 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id DE1A2129096; Thu, 29 Mar 2007 09:51:30 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 208B38C26; Thu, 29 Mar 2007 09:51:34 +1000 (EST) Date: Thu, 29 Mar 2007 09:51:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ulrich Spoerlein In-Reply-To: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Message-ID: <20070329080917.B3626@besplex.bde.org> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2007 23:51:37 -0000 On Wed, 28 Mar 2007, Ulrich Spoerlein wrote: > hostA # scp 500MB hostB:/net/share/ > ... > If I run the scp again, I can see X MB/s going out from HostA, 2*X > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > happening is, that HostB issues one NFS READ call for every WRITE > call. The traffic flows like this: > > -----> -----> > A B C > <----- > > If I rm(1) the file on the NFS share, then the first scp(1) will not > show this behaviour. It is only when overwritting files, that this > happens. At least under FreeBSD-~5.2 with an old version of scp, this is caused by blocksize bugs in the kernel and/or scp, and an open mode bug or feature in scp. The blocksize used by scp is 4K. This is smaller than the nfs block size of 8K, so nfs has to read-ahead 1 8K block for each pair of 4K- blocks written so as to have non-garbage in the top half of each 8K- block after writing 4K to the bottom half. It only has to read-ahead if there is something there, but repeated scp's ensure this by not truncating the file on open (open mode (O_WRONLY | O_CREAT) without O_TRUNC according to truss(1)). > The real weirdness comes into play, when I simply cp(1) from HostB > itself like this: > > hostB # cp 500MB /net/share/ > > I can do this over and over again, and _never_ get any noteworthy > amount of NFS READ calls, only WRITE. The network traffic is also, as > you would expect. > > Then I tested using ssh(1) instead of scp(1), like this: > > hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" > > This works, too. Probably, because sh(1) is truncating the file? cp truncates the file on open (open mode (O_WRONLY | O_TRUNC_ without O_CREAT according to truss(1)). cp also uses a block size of 64K, so it wouldn't cause read-ahead even if it didn't truncate. There are many possible wrong block sizes: - on my server, the block size according to st_blksize is 16K (ffs default). - on my client, the block size according to st_blksize is 512 due to bugs in nfs. There is an open PR or two about this. In nfs2, the file system's block size on the server is passed to the client for each file and used for st_blksize but nothing else, but in nfs3, the block size that is put in st_blksize by the client is hard-coded to the arbitrary (usually bad) value NFS_FABLKSIZE = 512. The correct block size to put in st_blksize in both cases seems to be the least common multiple of the nfs buffer size and the server block size, since if the application's i/o size is smaller than the nfs buffer size then there will be excessive block size conversions in the nfs client, and if the i/o size is smaller than the server's block size then there will be excessive block size conversions in the server's file system. nfs's buffer size is the maximum of the read size, the write size and the page size. This is usually 8K, so it is mismatched with the usual ffs server block size of 16K. The inefficiencies from this are less noticeable than the inefficiencies from a mismatch with the nfs buffer size. - scp for some reason doesn't use the advertised best blocksize of st_blksize = 512. It uses 4K, which is almost as bad since it is smaller than the nfs buffer size. - cp doesn't use the advertised best block size. It uses mmap() for regular files smaller than 8M and a hard-coded block size of MAXBSIZE = 64K for large regular files and all non-regular files. - the above is in FreeBSD-~5.2 (and FreeBSD-[1-4]). st_blksize is much more bogus and broken in -current. In -current, the value in va_blocksize that is carefully initialized for regular files by ffs and not so carefully initialized by nfs or for non-regular files, is not actually used even for regular files. vn_stat() now uses the hard-coded (usually bad) value of PAGE_SIZE. Thus st_blksize is useless, and ignoring it and using a larger hard-coded value in cp is a feature -- MAXBSIZE is too large in many cases, but a too-large value normally only wastes a little space while a too-small value normally wastes a lot of time. MAXBSIZE is a good value for large files (e.g., large regular files and raw disks). OTOH, even PAGE_SIZE is a waste of space for slow devices like keyboards. - stdio is the main thing that is naive enough to believe that st_blksize is still useful. The block size of BUFSIZ = 1024 in stdio.h is another way to get a pessimal block size, but stdio itself mainly uses it for strings and for what it thinks are. It misclassifies all cdevs as ttys and thus uses a better block size than st_blksize = for cdevs that are actually ttys and a slightly worse block size than st_blksize = and a much worse block size than cp's MAXBSIZE for cdevs that are actually disks. Not truncating the file in scp might be a feature for avoiding clobbering the whole file when the copying fails early, but it doesn't seem to be documented. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 00:11:53 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C83A16A402; Thu, 29 Mar 2007 00:11:53 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF4C13C45A; Thu, 29 Mar 2007 00:11:51 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2T0Bne3063747; Thu, 29 Mar 2007 04:11:49 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2T0BmQ7063746; Thu, 29 Mar 2007 04:11:48 +0400 (MSD) (envelope-from yar) Date: Thu, 29 Mar 2007 04:11:48 +0400 From: Yar Tikhiy To: Ulrich Spoerlein Message-ID: <20070329001148.GB59685@comp.chem.msu.su> References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 00:11:53 -0000 Greetings, On Wed, Mar 28, 2007 at 11:38:44AM +0200, Ulrich Spoerlein wrote: > > I observe a strange effect, when using the following setup: Three > FreeBSD 6.2[1] machines on Gigabit Ethernet using em(4) interfaces. > > HostC is the NFS server, HostB has /net/share mounted from HostC. I > will use HostA and HostB to demonstrate the issue. Picture this: > > hostA # scp 500MB hostB:/net/share/ > > Iff the file "500MB" does not yet exist on the NFS share, I can see X > MB/s going out of HostA, X MB/s coming in on HostB, X MB/s going out > on hostB again and finally X MB/s coming in on HostC. > > If I run the scp again, I can see X MB/s going out from HostA, 2*X > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > happening is, that HostB issues one NFS READ call for every WRITE > call. The traffic flows like this: > > -----> -----> > A B C > <----- > > If I rm(1) the file on the NFS share, then the first scp(1) will not > show this behaviour. It is only when overwritting files, that this > happens. > > The real weirdness comes into play, when I simply cp(1) from HostB > itself like this: > > hostB # cp 500MB /net/share/ > > I can do this over and over again, and _never_ get any noteworthy > amount of NFS READ calls, only WRITE. The network traffic is also, as > you would expect. > > Then I tested using ssh(1) instead of scp(1), like this: > > hostA # cat 500MB | ssh hostB "cat >/net/share/500MB" > > This works, too. Probably, because sh(1) is truncating the file? > > So, can someone please explain to me, what is happening and if/how it > can be avoided? My first guess is that scp and Samba use too small an I/O block size. Forget NFS and simply imagine that an application issues writes in 128-byte blocks while the disc block size is 512 bytes. If the OS is simple, like MS-DOS :-), then it will read the whole disc block each time and replace just 128 bytes in it on every application's write. If the OS is a bit more sophisticated, say FreeBSD ;-), it will use a buffer cache to alleviate the disc churn. However, it still will have to read the disc block once on the first small write to it because it has no way to know that the application is going to overwrite the whole of the disc block in a moment. So each disc block is read once and written once; but the OS still has to read it due to the poor choice of the write block size. Of course, my scenario implies that the file already contains data and the writes go over them, not beyond the end of file. Something similar (but maybe a bit more complex) should be going on in your case. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 08:19:37 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0512B16A403 for ; Thu, 29 Mar 2007 08:19:37 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 87EED13C457 for ; Thu, 29 Mar 2007 08:19:36 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so98708nfc for ; Thu, 29 Mar 2007 01:19:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EX0QeltM3FumVn335cZ9oUIz0Pahb4uigLFmM/UmgJe9YPICDVs1rLuu+L7PhvSb8GP7rE8wz4g1jIuKeDYNFVaBWZPsoTDJCNkOH/KMG2Y35K+Hkba3EPfG3x3fUZxe/4hwqK1w3EzLuAzZrHLrYT/VzNM3zxu8MN/DOR0keKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XD7m+S9QJkqL+sJghHZjVnl+6sXEmIe8TM9N8C4yQg6Jofs+dFfuM9bXogV2Z2rjske1DqNou+9ykcDCZ7MhxZ21hSYQ0rY4JyozONeeesDai2NkrDHqa961dZkx6FZI1dpn2nmMT3rXINtb5FlG1kOqsaHxoMvQQp5MP47m/eI= Received: by 10.82.104.18 with SMTP id b18mr918304buc.1175156374237; Thu, 29 Mar 2007 01:19:34 -0700 (PDT) Received: by 10.82.187.19 with HTTP; Thu, 29 Mar 2007 01:19:34 -0700 (PDT) Message-ID: <7ad7ddd90703290119i34b78d45s807659527d14478@mail.gmail.com> Date: Thu, 29 Mar 2007 10:19:34 +0200 From: "Ulrich Spoerlein" To: "Bruce Evans" In-Reply-To: <20070329080917.B3626@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7ad7ddd90703280238r5dd3f30ftc1641926ecdf44a8@mail.gmail.com> <20070329080917.B3626@besplex.bde.org> Cc: current@freebsd.org, net@freebsd.org Subject: Re: NFS write() calls lead to read() calls? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 08:19:37 -0000 On 3/29/07, Bruce Evans wrote: > On Wed, 28 Mar 2007, Ulrich Spoerlein wrote: > > > hostA # scp 500MB hostB:/net/share/ > > ... > > If I run the scp again, I can see X MB/s going out from HostA, 2*X > > MB/s coming in on HostB and X MB/s out plus X MB/s in on HostC. What's > > happening is, that HostB issues one NFS READ call for every WRITE > > call. The traffic flows like this: > > > > -----> -----> > > A B C > > <----- > > At least under FreeBSD-~5.2 with an old version of scp, this is caused > by blocksize bugs in the kernel and/or scp, and an open mode bug or > feature in scp. The blocksize used by scp is 4K. This is smaller > than the nfs block size of 8K, so nfs has to read-ahead 1 8K block for > each pair of 4K- blocks written so as to have non-garbage in the top > half of each 8K- block after writing 4K to the bottom half. It only > has to read-ahead if there is something there, but repeated scp's > ensure this by not truncating the file on open (open mode (O_WRONLY | > O_CREAT) without O_TRUNC according to truss(1)). > > [snip - all you ever wanted to know about block sizes] Thanks for the in-depth answer, Bruce. Greatly appreciated. I can now tweak all kinds of block sizes to make the final combination of Windows 2003, Samba and NFS work well. I hope that samba can be adjusted in the right places for this task. I'll post a summary, once I have it working. It seems that other people don't have these problems (as they are not running SMB+NFS) Uli From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 13:10:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 029F616A404 for ; Thu, 29 Mar 2007 13:10:57 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [194.126.106.100]) by mx1.freebsd.org (Postfix) with ESMTP id AD13913C4BE for ; Thu, 29 Mar 2007 13:10:56 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from localhost (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id DEC69B814 for ; Thu, 29 Mar 2007 15:40:28 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by localhost (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfyrY+QWYTYb for ; Thu, 29 Mar 2007 15:40:24 +0300 (EEST) Received: from raad.tartu.ee (lv.raad.tartu.ee [194.126.106.110]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 2797BB813 for ; Thu, 29 Mar 2007 15:40:24 +0300 (EEST) Received: from INFO/SpoolDir by raad.tartu.ee (Mercury 1.48); 29 Mar 07 15:40:24 +0300 Received: from SpoolDir by INFO (Mercury 1.48); 29 Mar 07 15:40:05 +0300 Received: from [172.26.1.3] (172.26.1.3) by raad.tartu.ee (Mercury 1.48) with ESMTP; 29 Mar 07 15:40:02 +0300 Message-ID: <460BB3A4.8020804@raad.tartu.ee> Date: Thu, 29 Mar 2007 15:40:04 +0300 From: Toomas Aas User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPSec tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 13:10:57 -0000 Hello! We have a central office which is separated from the Internet with firewall running Linux 2.4 and FreeSWAN. I'm trying to create an IPSec tunnel to the central office from another small branch office, using FreeBSD 6.2 with it's integrated IPSec and ipsec-tools. The tunneling is generally working, both internal networks can see each other, but I'm having some problems with traffic originating from the FreeBSD firewall itself. The central office has internal network 192.168.1.0/24 and firewall's external IP is, let's say, A.B.C.D. The branch office has internal network 192.168.5.0/24 and firewall's external IP is W.X.Y.Z. The policies in /etc/ipsec.conf are as follows. spdadd 192.168.5.0/24 192.168.1.0/24 any -P out ipsec \ esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd 192.168.1.0/24 192.168.5.0/24 any -P in ipsec \ esp/tunnel/A.B.C.D-W.X.Y.Z/require; The traffic between hosts in 192.168.1.0/24 and 192.168.5.0/24 is being correctly tunnelled, i.e. when I watch the traffic on firewall's external interface with tcpdump, I can see only ESP traffic between A.B.C.D and W.X.Y.Z, and the internal IPs don't appear anywhere. I can even successfully initiate *some* tunnelled traffic from the firewall machine itself, for example ping -S 192.168.5.1 192.168.1.3 works correctly, as does telnet -s 192.168.5.1 192.168.1.3 53 However, the main reason why I want to have internal traffic originating from the firewall host itself is that I'd like to run an internal DNS server with slave zones for my internal network (*.in-addr.arpa) so all the DNS traffic wouldn't go through the VPN. The master for these zones is 192.168.1.3. I've configured named.conf with following options { ... listen-on { 127.0.0.1; 192.168.5.1; }; query source address 192.168.5.1; forwarders { 192.168.1.3; }; ... }; ... zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.3; }; }; ... However, when I start named and watch the traffic on firewall's external interface with tcpdump, I can see actual packets between 192.168.5.1 and 192.168.1.3. What is the difference between this DNS traffic and things like telnet -s, which causes the DNS traffic to not be tunneled? -- Toomas Aas From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 18:59:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A87516A40E for ; Thu, 29 Mar 2007 18:59:46 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id B52A213C459 for ; Thu, 29 Mar 2007 18:59:45 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id 14B895000; Thu, 29 Mar 2007 21:23:32 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.64.98])by mx1.ethionet.et ( Postfix) with SMTP id C78454FE2;Thu, 29 Mar 2007 21:23:31 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id 81D9A17024; Thu, 29 Mar 2007 21:29:06 +0300 (EAT) Date: Thu, 29 Mar 2007 21:29:06 +0300 From: Mike Makonnen To: freebsd-rc@freebsd.org Message-ID: <20070329182906.GB38703@rogue.navcom.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Cc: freebsd-net@freebsd.org Subject: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 18:59:46 -0000 Hello folks, Ever since rc.d was brought into the tree we all agreed IPv6 needed to be integrated better. Well, I've finally gotten arround to it... several years later :-P The patch is at: http://people.freebsd.org/~mtm/src-etc.ipv6.diff What it does ------------ - rc.d/network_ipv6 is no longer necessary and can be removed - IPv6 configuration is done on each interface in rc.d/netif along with IPv4 - IPv6 routing and options processing is done in rc.d/routing along with IPv4 - You can now do things like: # Start/Stop IPv6 on all interfaces /etc/rc.d/netif (start|stop) ip6 # Start/Stop IPv6 only on interface rl0 /etc/rc.d/netif (start|stop) rl0 ip6 # Do IPv6 options processing /etc/rc.d/routing options ip6 Overview of the changes in src/etc ----------------------------------- - In order to differentiate between v4 and v6 configuration directives some knobs in rc.conf(5)have been renamed with an ipv4_ prefix: network_interfaces ifconfig_DEFAULT ifconfig_ ifconfig__aliasX defaultrouter gateway_enable static_routes etc... - Modify all scripts that reference old knobs (without ipv4_ prefix) to reference the new version of the knobs - Compatibility shims in rc.subr(8) so that old uses of knobs without an ipv4_ prefix work as expected. As part of this change split the code for this processing into its own function: old2new_knobs() - Modify some routines in etc/network.subr to take an additional argument to specify v4 or v6 configuration: _ifconfig_get_args ifconfig_getargs autoif wpaif - Move some invocations of route(8) and v6 options processing into rc.d/routing I'm using the patches on my main work machine without any problems, so I think it's ready for a wider review. Please try it out and send me any comments, bug-reports, etc. I would especially like feedback from folks more familiar with IPv6. One gotcha I've noticed is that if you boot with ipv6_enable turned off, then try to start IPv6 on an interface later on, it doesn't work because none of the interfaces (except lo0) has a link-local address (see rc.d/auto_linklocal). How can we fix this? Also, I would appreciate feedback on how stopping IPv6 on an interface should be handled. In rc.d/network_ipv6 it was handled at all. Currently, it goes through and deletes all IPv6 addresses on the interface. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mmakonnen@gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org | FreeBSD - Unleash the Daemon ! From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 19:32:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C91D016A401 for ; Thu, 29 Mar 2007 19:32:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9627613C455 for ; Thu, 29 Mar 2007 19:32:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 17FAD210F7C; Thu, 29 Mar 2007 15:32:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 29 Mar 2007 15:32:34 -0400 X-Sasl-enc: UJR41fubeW4EPjXzv65k9NawbDvS0UG5GYuijP4VdraI 1175196753 Received: from [192.168.124.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2B3E221EE9; Thu, 29 Mar 2007 15:32:33 -0400 (EDT) Message-ID: <460C144E.5000002@incunabulum.net> Date: Thu, 29 Mar 2007 20:32:30 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mike Makonnen References: <20070329182906.GB38703@rogue.navcom.lan> In-Reply-To: <20070329182906.GB38703@rogue.navcom.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 19:32:33 -0000 Mike Makonnen wrote: > I would > especially like feedback from folks more familiar with IPv6. One > gotcha I've noticed is that if you boot with ipv6_enable turned > off, then try to start IPv6 on an interface later on, it doesn't > work because none of the interfaces (except lo0) has a link-local > address (see rc.d/auto_linklocal). How can we fix this? Also, I > would appreciate feedback on how stopping IPv6 on an interface > should be handled. In rc.d/network_ipv6 it was handled at all. > Currently, it goes through and deletes all > IPv6 addresses on the interface. > I agree. We should be able to add/remove IPv6 link-local addresses somehow at runtime, after boot, without necessarily bringing up IPv6 on an interface during boot. I am thinking at some point it may be for the best if some of the code to do with address families is restructured so that the administrator is able to explicitly attach or detach protocol domains e.g. AF_INET, AF_INET6 to network interfaces on the command line, based on my experience of making the changes necessary for refcounting of various network stack structures. I'd like to get this fixed going forward, though, as ever, other work takes priority... Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 21:27:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E08A416A408; Thu, 29 Mar 2007 21:27:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9E49A13C484; Thu, 29 Mar 2007 21:27:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 778B22085; Thu, 29 Mar 2007 23:04:25 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 680ED2084; Thu, 29 Mar 2007 23:04:25 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 3BC88A1075; Thu, 29 Mar 2007 23:04:25 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Mike Makonnen References: <20070329182906.GB38703@rogue.navcom.lan> Date: Thu, 29 Mar 2007 23:04:25 +0200 In-Reply-To: <20070329182906.GB38703@rogue.navcom.lan> (Mike Makonnen's message of "Thu, 29 Mar 2007 21:29:06 +0300") Message-ID: <86abxvoj6u.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Merging rc.d/network_ipv6 into rc.d/netif X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 21:27:23 -0000 Mike Makonnen writes: > - You can now do things like: > # Start/Stop IPv6 on all interfaces > /etc/rc.d/netif (start|stop) ip6 > # Start/Stop IPv6 only on interface rl0 > /etc/rc.d/netif (start|stop) rl0 ip6 I hope we never get an if_ip NIC driver :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 23:55:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7A6216A400 for ; Thu, 29 Mar 2007 23:55:22 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 74D6213C4AD for ; Thu, 29 Mar 2007 23:55:22 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 016C21CC58; Fri, 30 Mar 2007 11:55:20 +1200 (NZST) Date: Fri, 30 Mar 2007 11:55:20 +1200 From: Andrew Thompson To: freebsd-net@freebsd.org Message-ID: <20070329235520.GD97061@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: CFT: new trunk(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 23:55:22 -0000 Hi, Here is a patch to add OpenBSD's trunk(4) interface, and also includes LACP support which came from agr(4) on NetBSD. Im interested in anyone who wants to test this and in particular lacp mode if you have a switch that supports it. http://people.freebsd.org/~thompsa/if_trunk-20070330b.diff The procedure to build this is (on an recent current) cd /usr/src patch -p0 < if_trunk-20070330b.diff build kernel and world... install kernel and world... To create a lacp trunk ifconfig trunk0 create ifconfig trunk0 up ifconfig trunk0 trunkproto lacp ifconfig trunk0 trunkport fxp0 ifconfig trunk0 trunkport fxp1 ifconfig will show you the status of the trunk, for lacp the port will be forwarding when it reaches COLLECTING and DISTRIBUTING. There are other trunk modes failover,loadbalance and roundrobin (see the man page). Any feedback would be great. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 16:45:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8398216A403 for ; Fri, 30 Mar 2007 16:45:58 +0000 (UTC) (envelope-from psrihari@in.ibm.com) Received: from ausmtp04.au.ibm.com (ausmtp04.au.ibm.com [202.81.18.152]) by mx1.freebsd.org (Postfix) with ESMTP id C203B13C4B0 for ; Fri, 30 Mar 2007 16:45:57 +0000 (UTC) (envelope-from psrihari@in.ibm.com) Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.8/8.13.8) with ESMTP id l2UGpFaB317202 for ; Sat, 31 Mar 2007 02:51:15 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2UGb1iD158154 for ; Sat, 31 Mar 2007 02:37:01 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2UGXUng017183 for ; Sat, 31 Mar 2007 02:33:30 +1000 Received: from d23ml068.in.ibm.com (d23ml068.in.ibm.com [9.124.105.45]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2UGXTPf017156 for ; Sat, 31 Mar 2007 02:33:30 +1000 From: Prithvi Srihari To: freebsd-net@freebsd.org Message-ID: Date: Fri, 30 Mar 2007 21:03:27 +0530 X-MIMETrack: Serialize by Router on d23ml068/23/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 30/03/2007 21:03:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Prithvi Srihari is out of the office. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 16:45:58 -0000 I will be out of the office starting 30/03/2007 and will not return until 06/04/2007. I will respond to your message when I return. In the meantime, please contact Richard Bloomer/Austin/IBM for urgent issues. From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 20:40:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE8C716A400 for ; Fri, 30 Mar 2007 20:40:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9E36A13C468 for ; Fri, 30 Mar 2007 20:40:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 13:11:33 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B1FF0125C26; Fri, 30 Mar 2007 13:40:47 -0700 (PDT) Message-ID: <460D75CE.70804@elischer.org> Date: Fri, 30 Mar 2007 13:40:46 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: ipfw@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 20:40:48 -0000 I have been looking at the IPFW code recently, especially with respect to locking. There are some things that could be done to improve IPFW's behaviour when processing packets, but some of these take a toll (there is always a toll) on the 'updating' side of things. For example. I can make IPFW lock-free during processing of packets (i.e. not holding any locks while traversing the list) which would solve problems we have with lock-order reversals when it needs to look at the socket layer (which needs socket layer locks). Unfortunatly this would make it a lot more expensive in the case where new rules are being added to the list. possibly a LOT more expensive. Now, this would only matter if one was adding (or deleting) hundreds of rules per second to the firewall, but as I've discovered, there's always SOMEONE that is doing the very thing you imagine that no-one would ever do. In my imagination, most of the people who did this sort of thing don't need to do it any more as tables obviate the need for that sort of thing. Is there anyone out there who is adding hundreds (or even dozens) of rules per second on a continuous basis, or who wants rule changing to be a really efficient operation? (does it matter to you if it takes a few milliSecs to add a rule?) Julian From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 21:02:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38EE516A400 for ; Fri, 30 Mar 2007 21:02:46 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0A28C13C48C for ; Fri, 30 Mar 2007 21:02:45 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id E2F2B2AD56A6; Fri, 30 Mar 2007 21:02:44 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 2D703A0A44E; Fri, 30 Mar 2007 21:02:43 +0000 (UTC) In-Reply-To: <460D75CE.70804@elischer.org> References: <460D75CE.70804@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Fri, 30 Mar 2007 16:02:43 -0500 To: Julian Elischer X-Mailer: Apple Mail (2.752.3) Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 21:02:46 -0000 On Mar 30, 2007, at 3:40 PM, Julian Elischer wrote: > I have been looking at the IPFW code recently, especially with > respect to locking. > There are some things that could be done to improve IPFW's > behaviour when processing packets, but some of these take a > toll (there is always a toll) on the 'updating' side of things. > > For example. I can make IPFW lock-free during processing of packets > (i.e. not holding any locks while traversing the > list) which would solve problems we have with lock-order reversals > when it needs to look at the socket layer (which needs socket layer > locks). Unfortunatly this would make it a lot more expensive > in the case where new rules are being added to the list. possibly a > LOT > more expensive. Now, this would only matter if one was adding (or > deleting) > hundreds of rules per second to the firewall, but as I've discovered, > there's always SOMEONE that is doing the very thing you imagine that > no-one would ever do. > > In my imagination, most of the people who did this sort of thing don't > need to do it any more as tables obviate the need for that sort of > thing. > > Is there anyone out there who is adding hundreds (or even dozens) > of rules > per second on a continuous basis, or who wants rule changing to > be a really efficient operation? > (does it matter to you if it takes a few milliSecs to add a rule?) > > Julian Would this apply to "dynamic rules", using the keep-state keyword? That'd be a killer for us. If not, the only problem I'd have is that my ipfw startup script adds about 20,000 rules on a reboot. 20,000 rules multiplied by any significant amount of time would be bad, just from a reboot-recovery- time angle. But, if it improved overall performance, I probably wouldn't mind too much. :) From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 21:59:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4830216A403 for ; Fri, 30 Mar 2007 21:59:41 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 364FD13C46E for ; Fri, 30 Mar 2007 21:59:41 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2ULxcP6088248; Fri, 30 Mar 2007 13:59:38 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2ULxckW088247; Fri, 30 Mar 2007 14:59:38 -0700 (PDT) (envelope-from rizzo) Date: Fri, 30 Mar 2007 14:59:38 -0700 From: Luigi Rizzo To: Julian Elischer Message-ID: <20070330145938.A88154@xorpc.icir.org> References: <460D75CE.70804@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <460D75CE.70804@elischer.org>; from julian@elischer.org on Fri, Mar 30, 2007 at 01:40:46PM -0700 Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 21:59:41 -0000 On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: > I have been looking at the IPFW code recently, especially > with respect to locking. > There are some things that could be done to improve IPFW's > behaviour when processing packets, but some of these take a > toll (there is always a toll) on the 'updating' side of things. certainly ipfw was not designed with SMP in mind. If you can tell us what is your plan to make the list lock free (which one, the static or dynamic ones ?) maybe we can comment more. E.g. one option could be the usual trick of adding refcounts to the individual rules, and then using an array of pointers to them. While processing you grab a refcount to the array, and release it once done with the packet. If there is an addition or removal, you duplicate the array (which may be expensive for the large 20k rules mentioned), manipulate the copy and then atomically swap the pointers to the head. This might even work for dynamic rules as the lists (the content of each hash bucket) are typically short. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:41:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FBDB16A404 for ; Fri, 30 Mar 2007 23:41:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7D23F13C45D for ; Fri, 30 Mar 2007 23:41:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 16:12:24 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 9B2BE125D4D; Fri, 30 Mar 2007 16:41:39 -0700 (PDT) Message-ID: <460DA02D.8010509@elischer.org> Date: Fri, 30 Mar 2007 16:41:33 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Kevin Day References: <460D75CE.70804@elischer.org> <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> In-Reply-To: <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 23:41:40 -0000 Kevin Day wrote: > > On Mar 30, 2007, at 3:40 PM, Julian Elischer wrote: > >> I have been looking at the IPFW code recently, especially with respect >> to locking. >> There are some things that could be done to improve IPFW's behaviour >> when processing packets, but some of these take a >> toll (there is always a toll) on the 'updating' side of things. >> >> For example. I can make IPFW lock-free during processing of packets >> (i.e. not holding any locks while traversing the >> list) which would solve problems we have with lock-order reversals >> when it needs to look at the socket layer (which needs socket layer >> locks). Unfortunatly this would make it a lot more expensive >> in the case where new rules are being added to the list. possibly a LOT >> more expensive. Now, this would only matter if one was adding (or >> deleting) >> hundreds of rules per second to the firewall, but as I've discovered, >> there's always SOMEONE that is doing the very thing you imagine that >> no-one would ever do. >> >> In my imagination, most of the people who did this sort of thing don't >> need to do it any more as tables obviate the need for that sort of thing. >> >> Is there anyone out there who is adding hundreds (or even dozens) of >> rules >> per second on a continuous basis, or who wants rule changing to >> be a really efficient operation? >> (does it matter to you if it takes a few milliSecs to add a rule?) >> >> Julian > > Would this apply to "dynamic rules", using the keep-state keyword? > That'd be a killer for us. > no, just to the main firewall list where rules a re put manually. > If not, the only problem I'd have is that my ipfw startup script adds > about 20,000 rules on a reboot. 20,000 rules multiplied by any > significant amount of time would be bad, just from a > reboot-recovery-time angle. But, if it improved overall performance, I > probably wouldn't mind too much. :) now, what could I add to the firewall to make that come down to, say, 100 rules? I have the following in my list of things to add: ** adding of 'variables (registers) to hold values for the duration of the filter run. ** ipfw add 100 set (register number) value ipfw add 100 set (register number) tablearg ip from table (x) to any ipfw [action] if (register number) gt value (lt,le,ge,eq,neq) ipfw [action] if (register number) in table (x) (registers and table values can be addresses) ** computed skipto ** ipfw skipto tablearg ip from table (2) to any ** adding items to tables automatically ** ipfw loadto table 3 (source, value) ip from any to table (3) ** ability to select WHICH table arg ** ipfw skipto tablearg2 ip from table (1) to table (2) > From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:50:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D50916A409 for ; Fri, 30 Mar 2007 23:50:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4B60013C4B0 for ; Fri, 30 Mar 2007 23:50:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 16:21:34 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 2E367125D68; Fri, 30 Mar 2007 16:50:49 -0700 (PDT) Message-ID: <460DA258.2030402@elischer.org> Date: Fri, 30 Mar 2007 16:50:48 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> In-Reply-To: <20070330145938.A88154@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 23:50:50 -0000 Luigi Rizzo wrote: > On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: >> I have been looking at the IPFW code recently, especially >> with respect to locking. >> There are some things that could be done to improve IPFW's >> behaviour when processing packets, but some of these take a >> toll (there is always a toll) on the 'updating' side of things. > > certainly ipfw was not designed with SMP in mind. > If you can tell us what is your plan to make the list lock free > (which one, the static or dynamic ones ?) maybe we can comment more. > > E.g. one option could be the usual trick of adding refcounts to > the individual rules, and then using an array of pointers to them. > While processing you grab a refcount to the array, and release it once > done with the packet. If there is an addition or removal, you duplicate > the array (which may be expensive for the large 20k rules mentioned), > manipulate the copy and then atomically swap the pointers to the head. This is pretty close.. I know I've mentioned this to people several times over the last year or so. the trick is to try do it in a way that the average packet doesn't need to do any locks to get in and the updater does more work. if you are willing to acquire a lock on both starting and ending the run through the firewall it is easy. (I already have code to do that..) (see http://www.freebsd.org/~julian/atomic_replace.c (untested but probably close.) doing it without requiring that each packet get those locks however is a whole new level of problem. > > This might even work for dynamic rules as the lists (the content of > each hash bucket) are typically short. yep > > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 01:58:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CA5E16A406 for ; Sat, 31 Mar 2007 01:58:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 17B7513C4C4 for ; Sat, 31 Mar 2007 01:58:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E666F210D70; Fri, 30 Mar 2007 21:58:22 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 30 Mar 2007 21:58:17 -0400 X-Sasl-enc: fIZOeGL99paFVTRW0YclOPZ+sqOIYGgajbkCnqb7+eXx 1175306297 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D33CBEF28; Fri, 30 Mar 2007 21:58:16 -0400 (EDT) Message-ID: <460DC036.40200@FreeBSD.org> Date: Sat, 31 Mar 2007 02:58:14 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Julian Elischer References: <460D75CE.70804@elischer.org> In-Reply-To: <460D75CE.70804@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 01:58:17 -0000 For what it's worth, the code I wrote for XORP is only for IPFW2, and uses its tables feature to atomically transcribe XORP rulesets to IPFW ones before swapping them in. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 08:21:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D7BB16A404 for ; Sat, 31 Mar 2007 08:21:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 687A213C4B9 for ; Sat, 31 Mar 2007 08:21:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 75338 invoked from network); 31 Mar 2007 07:48:11 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Mar 2007 07:48:11 -0000 Message-ID: <460E19EE.3020700@freebsd.org> Date: Sat, 31 Mar 2007 10:21:02 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Julian Elischer References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> In-Reply-To: <460DA258.2030402@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 08:21:01 -0000 Julian Elischer wrote: > Luigi Rizzo wrote: >> On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: >>> I have been looking at the IPFW code recently, especially with >>> respect to locking. >>> There are some things that could be done to improve IPFW's behaviour >>> when processing packets, but some of these take a >>> toll (there is always a toll) on the 'updating' side of things. >> >> certainly ipfw was not designed with SMP in mind. If you can tell us >> what is your plan to make the list lock free >> (which one, the static or dynamic ones ?) maybe we can comment more. >> >> E.g. one option could be the usual trick of adding refcounts to >> the individual rules, and then using an array of pointers to them. >> While processing you grab a refcount to the array, and release it once >> done with the packet. If there is an addition or removal, you duplicate >> the array (which may be expensive for the large 20k rules mentioned), >> manipulate the copy and then atomically swap the pointers to the head. > > This is pretty close.. I know I've mentioned this to people several > times over > the last year or so. the trick is to try do it in a way that the average > packet > doesn't need to do any locks to get in and the updater does more work. > if you are willing to acquire a lock on both starting and ending > the run through the firewall it is easy. > (I already have code to do that..) > (see http://www.freebsd.org/~julian/atomic_replace.c (untested but > probably close.) > doing it without requiring that each packet get those locks however is a > whole new level of problem. The locking overhead per packet in ipfw is by no means its limiting factor. Actually it's a very small part and pretty much any work on it is lost love. It would be much better spent time to optimize the main rule loop of ipfw to speed things up. I was profiling ipfw early last year with an Agilent packet generator and hwpmc. In the meantime the packet forwarding path (w/o ipfw) has been improved but relative to each other the number are still correct. Numbers pre-taskqueue improvements from early 2006: fastfwd 580357 pps fastfwd+pfil_pass 565477 pps (no rules, just pass packet on) fastfwd+ipfw_allow 505952 pps (one rule) fastfwd+ipfw_30rules 401768 pps (30 IP address non-matching rules) fastfwd+pf_pass 476190 pps (one rule) fastfwd+pf_30rules 342262 pps (30 IP address non-matching rules) The overhead per packet is big. Enabling of ipfw and the pfil/ipfw per packet and their indirect function calls cause a loss of only about 15'000 pps (0.9%). On the other hand the first rule costs 12.9% and each additional rule 0.6%. All this is without any complex rules like table lookups, state tracking, etc. idle fastfwd fastfwd+ipfw_allow fastfwd+ipfw_30rules cycles 2596685731 2598214743 2597973265 2596702381 cpu-clk-unhalted 7824023 2582240847 2518187670 2483904362 instructions 2317535 1324655330 1492363346 2026009148 branches 316786 174329367 191263118 294700024 branch-mispredicts 19757 2235749 10003461 8848407 dc-access 1417532 829159482 998427224 1235192770 dc-refill-from-l2 2124 4767395 4346738 4548311 dc-refill-from-system 89 803102 819658 654661 dtlb-l2-hit 626 10435843 9304448 12352018 dtlb-miss 129 255493 130998 112644 ic-fetch 804423 471138619 583149432 870371492 ic-miss 2358 34831 2505198 1947943 itlb-l2-hit 0 74 12 12 itlb-miss 42 92 82 82 lock-cycles 77 803 352 451 locked-instructions 4 19 2 4 lock-dc-access 6 20 6 7 lock-dc-miss 0 0 0 0 Hardware is a dual Opteron 852 at 2.6GHz on a Tyan 2882 mainboard with a dual Intel em network card plugged into a PCI64-133 slot. Packets are flowing from em0 -> em1. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 09:27:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4028516A403; Sat, 31 Mar 2007 09:27:43 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD8D13C4BA; Sat, 31 Mar 2007 09:27:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2V9Rfan095305; Sat, 31 Mar 2007 01:27:41 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2V9Rf54095304; Sat, 31 Mar 2007 02:27:41 -0700 (PDT) (envelope-from rizzo) Date: Sat, 31 Mar 2007 02:27:41 -0700 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20070331022741.A94927@xorpc.icir.org> References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> <460E19EE.3020700@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <460E19EE.3020700@freebsd.org>; from andre@freebsd.org on Sat, Mar 31, 2007 at 10:21:02AM +0200 Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 09:27:43 -0000 On Sat, Mar 31, 2007 at 10:21:02AM +0200, Andre Oppermann wrote: > Julian Elischer wrote: > > Luigi Rizzo wrote: > >> On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: > >>> I have been looking at the IPFW code recently, especially with > >>> respect to locking. > >>> There are some things that could be done to improve IPFW's behaviour ... > The locking overhead per packet in ipfw is by no means its limiting i think you and Julian are looking at different issues. if i understand julian's comment, the problem is that the list is protected by a single lock, so no hope of parallelising the work, and if one kernel thread is busy processing a packet in the filter, others might be blocked for a long time (in your case, the set of 30 rules is 765ns for ipfw and 1198ns for pf). Your tests presumably have little if any contention on the lock. Specifically, if you compute the difference of the inverses of those pps rates you see the following: +pfil_pass 45.3 ns per packet +ipfw_allow +253.4 ns/packet (setup and first rule) +ipfw_30 +17.67 ns/(packet * extra rule) +pf_pass +376.9 ns/packet (setup and first rule) +pf_30 +28.34 ns/(packet * extra rule) the lock acquisition cost is in the 'setup' part but i cannot tell how expensive it is. Julian's suggested change (and surely the one i described) replaces the lock/unlock pair on the rule list with a refcount add/dec pair (with uncontested locks the cost should be similar), but especially makes the operation non-blocking allowing running the input and output paths in parallel. > factor. Actually it's a very small part and pretty much any work on > it is lost love. It would be much better spent time to optimize the > main rule loop of ipfw to speed things up. I was profiling ipfw early > last year with an Agilent packet generator and hwpmc. In the meantime > the packet forwarding path (w/o ipfw) has been improved but relative > to each other the number are still correct. actually your numbers show that at least the rule setup (and the processing of simple rules) is significantly faster (50% or so) in ipfw2 than in pf. I know that the setup time is expensive, but i am not sure that one can save much - in both cases, you need to fetching a lot of information, which is scattered in variable locations in the mbuf and packet headers. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 10:47:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BF9516A405; Sat, 31 Mar 2007 10:47:48 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id ACCD413C459; Sat, 31 Mar 2007 10:47:46 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.190.188] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HXb7E1nZm-00065J; Sat, 31 Mar 2007 12:47:25 +0200 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Sat, 31 Mar 2007 11:47:12 +0100 User-Agent: KMail/1.9.5 References: <460D75CE.70804@elischer.org> <460E19EE.3020700@freebsd.org> <20070331022741.A94927@xorpc.icir.org> In-Reply-To: <20070331022741.A94927@xorpc.icir.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1702159.HoLqzXUo7s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703311247.19940.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18gzQ6r4Bp+mzp9HZNxTgLd2uL9toh+JlSVLwz Us1+F/8zYnpilPJtbFSEAvREfvXGMHWv4dvNi1LdddDJRjYkKN zJGUlDTmEDKAxLAhrbMaQ== Cc: Luigi Rizzo , Andre Oppermann , Julian Elischer , FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 10:47:48 -0000 --nextPart1702159.HoLqzXUo7s Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 31 March 2007 11:27, Luigi Rizzo wrote: > On Sat, Mar 31, 2007 at 10:21:02AM +0200, Andre Oppermann wrote: > > Julian Elischer wrote: > > > Luigi Rizzo wrote: > > >> On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: > > >>> I have been looking at the IPFW code recently, especially with > > >>> respect to locking. > > >>> There are some things that could be done to improve IPFW's > > >>> behaviour > > ... > > > The locking overhead per packet in ipfw is by no means its limiting > > i think you and Julian are looking at different issues. > if i understand julian's comment, the problem is that the list > is protected by a single lock, so no hope of parallelising ipfw uses rwlocks for the static rules quite some time now. In contrast=20 to Julian, I don't believe that the claimed lock order reversal with a=20 rlock() can be the cause of a deadlock (exclusiveness is a precondition). = =20 Haveing been involved in the hacks that went in and out of ipfw and pfil=20 locking over the last few years and the problems that went along with it,=20 I'd urge everybody to *not* rush any more hacks into this. > the work, and if one kernel thread is busy processing a packet > in the filter, others might be blocked for a long time > (in your case, the set of 30 rules is 765ns for ipfw and 1198ns > for pf). > > Your tests presumably have little if any contention on the lock. Most likely none at all, since the forwarding path takes care of=20 serialization. > Specifically, if you compute the difference of the inverses > of those pps rates you see the following: > > +pfil_pass 45.3 ns per packet > > +ipfw_allow +253.4 ns/packet (setup and first rule) > +ipfw_30 +17.67 ns/(packet * extra rule) > > +pf_pass +376.9 ns/packet (setup and first rule) > +pf_30 +28.34 ns/(packet * extra rule) > > > the lock acquisition cost is in the 'setup' part but i cannot tell > how expensive it is. > Julian's suggested change (and surely the one i described) > replaces the lock/unlock pair on the rule list with a refcount add/dec > pair (with uncontested locks the cost should be similar), but > especially makes the operation non-blocking allowing running the input > and output paths in parallel. See above, ipfw is working in parallel already. In addition to that,=20 using a ref-count would be worse! Instead of two atomic operations you'd=20 then have to pay for four: lock ref unlock work lock unref unlock All of=20 which can contentend each other. This will most likely cause more=20 serialization than we currently have. Again, please don't rush any=20 hacks! > > factor. Actually it's a very small part and pretty much any work on > > it is lost love. It would be much better spent time to optimize the > > main rule loop of ipfw to speed things up. I was profiling ipfw > > early last year with an Agilent packet generator and hwpmc. In the > > meantime the packet forwarding path (w/o ipfw) has been improved but > > relative to each other the number are still correct. > > actually your numbers show that at least the rule setup (and the > processing of simple rules) is significantly faster (50% or so) in > ipfw2 than in pf. Note that pf includes a plethora of sanity checks in the default rule=20 processing. Also note that pf - due to it's stateful design - does=20 a "check state" first for every packet. This gives a big mallus in this=20 test special test. > I know that the setup time is expensive, but i am not sure that > one can save much - in both cases, you need to fetching a lot > of information, which is scattered in variable locations in > the mbuf and packet headers. Agreed. For the ipfw case it *might* make sense to reach into the upper=20 layers only if requested - not at all sure about that, however. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1702159.HoLqzXUo7s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGDjw3XyyEoT62BG0RAovAAJ9/eLdEZfjHiEEwICMt4CQTGbH3BwCePJgT 4nAXEG6PMYYNEMmLp+gg1e8= =E5Tl -----END PGP SIGNATURE----- --nextPart1702159.HoLqzXUo7s-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 14:09:02 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2150916A402 for ; Sat, 31 Mar 2007 14:09:02 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: from sellinet.net (galileo.sellinet.net [82.199.192.2]) by mx1.freebsd.org (Postfix) with SMTP id 6A28113C448 for ; Sat, 31 Mar 2007 14:09:01 +0000 (UTC) (envelope-from ndenev@totalterror.net) Received: (qmail 29339 invoked by uid 1009); 31 Mar 2007 16:42:18 +0300 Received: from ndenev@totalterror.net by galileo by uid 1002 with qmail-scanner-1.22 (spamassassin: 3.0.3. Clear:RC:1(82.199.197.152):. Processed in 0.066695 secs); 31 Mar 2007 13:42:18 -0000 Received: from unknown (HELO ndenev.totalterror.net) (82.199.197.152) by galileo.sellinet.net with SMTP; 31 Mar 2007 16:42:18 +0300 Received: (qmail 38936 invoked from network); 31 Mar 2007 16:42:18 +0300 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by ndenev.totalterror.net with SMTP; 31 Mar 2007 16:42:18 +0300 Message-ID: <460E6536.7060805@totalterror.net> Date: Sat, 31 Mar 2007 16:42:14 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: Andrew Thompson References: <20070329235520.GD97061@heff.fud.org.nz> In-Reply-To: <20070329235520.GD97061@heff.fud.org.nz> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=F2DB7EB9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2E297DFB224E25355D9E3866" Cc: freebsd-net@freebsd.org Subject: Re: CFT: new trunk(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 14:09:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E297DFB224E25355D9E3866 Content-Type: multipart/mixed; boundary="------------010805010307080101020906" This is a multi-part message in MIME format. --------------010805010307080101020906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Thompson wrote: > Hi, >=20 >=20 > Here is a patch to add OpenBSD's trunk(4) interface, and also includes > LACP support which came from agr(4) on NetBSD. Im interested in anyone= > who wants to test this and in particular lacp mode if you have a switch= > that supports it.=20 >=20 > http://people.freebsd.org/~thompsa/if_trunk-20070330b.diff >=20 > The procedure to build this is (on an recent current) > cd /usr/src > patch -p0 < if_trunk-20070330b.diff > build kernel and world... > install kernel and world... >=20 > To create a lacp trunk > ifconfig trunk0 create > ifconfig trunk0 up > ifconfig trunk0 trunkproto lacp > ifconfig trunk0 trunkport fxp0 > ifconfig trunk0 trunkport fxp1 >=20 > ifconfig will show you the status of the trunk, for lacp the port will > be forwarding when it reaches COLLECTING and DISTRIBUTING. There are > other trunk modes failover,loadbalance and roundrobin (see the man > page). >=20 > Any feedback would be great. >=20 >=20 > cheers, > Andrew Hi, This is great news! I was waiting for this for ages :) I had to apply the attached to compile it on my 2 hour old -CURRENT, i'm not sure why single space before the tab confused Make... anyways it seems to work perfectly when i tested it on my laptop with the built in fxp0 interface and one cardbus xl0 adapter in failover mode. I'll try to setup next a wireless network so i can test the cool wired/wireless roaming example from the manual page. Thanks, Niki --------------010805010307080101020906 Content-Type: text/plain; name="if_trunk_space" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="if_trunk_space" --- if_trunk-20070330b.diff.orig Sat Mar 31 16:23:30 2007 +++ if_trunk-20070330b.diff Sat Mar 31 16:24:02 2007 @@ -440,7 +440,7 @@ + +.if ${MK_INET6_SUPPORT} !=3D "no" + opt_inet6.h: -+ echo "#define INET6 1" > ${.TARGET} ++ echo "#define INET6 1" > ${.TARGET} +.endif +.endif + --------------010805010307080101020906-- --------------enig2E297DFB224E25355D9E3866 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDmU6HNAJ/fLbfrkRAtULAJkBbInGV+aQeBKSENbTu37Wc0Nv6QCfRBo5 xiXdHHrmzux4tw+kswyI3Ew= =fx+3 -----END PGP SIGNATURE----- --------------enig2E297DFB224E25355D9E3866-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 16:04:02 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF95416A402 for ; Sat, 31 Mar 2007 16:04:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id BB8B213C43E for ; Sat, 31 Mar 2007 16:04:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 31 Mar 2007 08:34:26 -0700 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 60180125ADE; Sat, 31 Mar 2007 09:03:47 -0700 (PDT) Message-ID: <460E8663.9040309@elischer.org> Date: Sat, 31 Mar 2007 09:03:47 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Andre Oppermann References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> <460E19EE.3020700@freebsd.org> In-Reply-To: <460E19EE.3020700@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 16:04:03 -0000 Thanks for the information.. The main thrust for me is to make it not hold any locks during processing. performance is 2nd Andre Oppermann wrote: > Julian Elischer wrote: >> Luigi Rizzo wrote: >>> On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: >>>> I have been looking at the IPFW code recently, especially with >>>> respect to locking. >>>> There are some things that could be done to improve IPFW's behaviour >>>> when processing packets, but some of these take a >>>> toll (there is always a toll) on the 'updating' side of things. >>> >>> certainly ipfw was not designed with SMP in mind. If you can tell us >>> what is your plan to make the list lock free >>> (which one, the static or dynamic ones ?) maybe we can comment more. >>> >>> E.g. one option could be the usual trick of adding refcounts to >>> the individual rules, and then using an array of pointers to them. >>> While processing you grab a refcount to the array, and release it once >>> done with the packet. If there is an addition or removal, you duplicate >>> the array (which may be expensive for the large 20k rules mentioned), >>> manipulate the copy and then atomically swap the pointers to the head. >> >> This is pretty close.. I know I've mentioned this to people several >> times over >> the last year or so. the trick is to try do it in a way that the >> average packet >> doesn't need to do any locks to get in and the updater does more work. >> if you are willing to acquire a lock on both starting and ending >> the run through the firewall it is easy. >> (I already have code to do that..) >> (see http://www.freebsd.org/~julian/atomic_replace.c (untested but >> probably close.) >> doing it without requiring that each packet get those locks however is >> a whole new level of problem. > > The locking overhead per packet in ipfw is by no means its limiting > factor. Actually it's a very small part and pretty much any work on > it is lost love. It would be much better spent time to optimize the > main rule loop of ipfw to speed things up. I was profiling ipfw early > last year with an Agilent packet generator and hwpmc. In the meantime > the packet forwarding path (w/o ipfw) has been improved but relative > to each other the number are still correct. > > Numbers pre-taskqueue improvements from early 2006: > fastfwd 580357 pps > fastfwd+pfil_pass 565477 pps (no rules, just pass packet on) > fastfwd+ipfw_allow 505952 pps (one rule) > fastfwd+ipfw_30rules 401768 pps (30 IP address non-matching rules) > fastfwd+pf_pass 476190 pps (one rule) > fastfwd+pf_30rules 342262 pps (30 IP address non-matching rules) > > The overhead per packet is big. Enabling of ipfw and the pfil/ipfw > per packet and their indirect function calls cause a loss of only > about 15'000 pps (0.9%). On the other hand the first rule costs 12.9% > and each additional rule 0.6%. All this is without any complex rules > like table lookups, state tracking, etc. > > idle fastfwd fastfwd+ipfw_allow fastfwd+ipfw_30rules > cycles 2596685731 2598214743 2597973265 2596702381 > cpu-clk-unhalted 7824023 2582240847 2518187670 2483904362 > instructions 2317535 1324655330 1492363346 2026009148 > branches 316786 174329367 191263118 294700024 > branch-mispredicts 19757 2235749 10003461 8848407 > dc-access 1417532 829159482 998427224 1235192770 > dc-refill-from-l2 2124 4767395 4346738 4548311 > dc-refill-from-system 89 803102 819658 654661 > dtlb-l2-hit 626 10435843 9304448 12352018 > dtlb-miss 129 255493 130998 112644 > ic-fetch 804423 471138619 583149432 870371492 > ic-miss 2358 34831 2505198 1947943 > itlb-l2-hit 0 74 12 12 > itlb-miss 42 92 82 82 > lock-cycles 77 803 352 451 > locked-instructions 4 19 2 4 > lock-dc-access 6 20 6 7 > lock-dc-miss 0 0 0 0 > > Hardware is a dual Opteron 852 at 2.6GHz on a Tyan 2882 mainboard with > a dual Intel em network card plugged into a PCI64-133 slot. Packets > are flowing from em0 -> em1. > From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 16:06:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD30B16A409 for ; Sat, 31 Mar 2007 16:06:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id C851513C469 for ; Sat, 31 Mar 2007 16:06:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 31 Mar 2007 08:36:54 -0700 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 617F7125B02; Sat, 31 Mar 2007 09:06:15 -0700 (PDT) Message-ID: <460E86F7.9050104@elischer.org> Date: Sat, 31 Mar 2007 09:06:15 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> <460E19EE.3020700@freebsd.org> <20070331022741.A94927@xorpc.icir.org> In-Reply-To: <20070331022741.A94927@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org, Andre Oppermann Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 16:06:17 -0000 Luigi Rizzo wrote: > On Sat, Mar 31, 2007 at 10:21:02AM +0200, Andre Oppermann wrote: >> Julian Elischer wrote: >>> Luigi Rizzo wrote: >>>> On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote: >>>>> I have been looking at the IPFW code recently, especially with >>>>> respect to locking. >>>>> There are some things that could be done to improve IPFW's behaviour > ... >> The locking overhead per packet in ipfw is by no means its limiting > > i think you and Julian are looking at different issues. > if i understand julian's comment, the problem is that the list > is protected by a single lock, so no hope of parallelising > the work, and if one kernel thread is busy processing a packet > in the filter, others might be blocked for a long time > (in your case, the set of 30 rules is 765ns for ipfw and 1198ns > for pf). > > Your tests presumably have little if any contention on the lock. > > Specifically, if you compute the difference of the inverses > of those pps rates you see the following: > > +pfil_pass 45.3 ns per packet > > +ipfw_allow +253.4 ns/packet (setup and first rule) > +ipfw_30 +17.67 ns/(packet * extra rule) > > +pf_pass +376.9 ns/packet (setup and first rule) > +pf_30 +28.34 ns/(packet * extra rule) > > > the lock acquisition cost is in the 'setup' part but i cannot tell > how expensive it is. > Julian's suggested change (and surely the one i described) > replaces the lock/unlock pair on the rule list with a refcount add/dec > pair (with uncontested locks the cost should be similar), but especially > makes the operation non-blocking allowing running the input and > output paths in parallel. -current now used a read-write lock so this is theoretically already possible.. trouble is that the lock is held whioch produces LORs when you try access something that is further up the stack e.g. the UID rules. > >> factor. Actually it's a very small part and pretty much any work on >> it is lost love. It would be much better spent time to optimize the >> main rule loop of ipfw to speed things up. I was profiling ipfw early >> last year with an Agilent packet generator and hwpmc. In the meantime >> the packet forwarding path (w/o ipfw) has been improved but relative >> to each other the number are still correct. > > actually your numbers show that at least the rule setup (and the > processing of simple rules) is significantly faster (50% or so) in > ipfw2 than in pf. > > I know that the setup time is expensive, but i am not sure that > one can save much - in both cases, you need to fetching a lot > of information, which is scattered in variable locations in > the mbuf and packet headers. > > cheers > luigi > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 17:08:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 798F516A404; Sat, 31 Mar 2007 17:08:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 62AB213C484; Sat, 31 Mar 2007 17:08:47 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2VH8jkq000515; Sat, 31 Mar 2007 09:08:45 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2VH8jKH000514; Sat, 31 Mar 2007 10:08:45 -0700 (PDT) (envelope-from rizzo) Date: Sat, 31 Mar 2007 10:08:45 -0700 From: Luigi Rizzo To: Max Laier Message-ID: <20070331100845.A307@xorpc.icir.org> References: <460D75CE.70804@elischer.org> <460E19EE.3020700@freebsd.org> <20070331022741.A94927@xorpc.icir.org> <200703311247.19940.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200703311247.19940.max@love2party.net>; from max@love2party.net on Sat, Mar 31, 2007 at 11:47:12AM +0100 Cc: freebsd-ipfw@freebsd.org, Andre Oppermann , Julian Elischer , FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 17:08:47 -0000 On Sat, Mar 31, 2007 at 11:47:12AM +0100, Max Laier wrote: > On Saturday 31 March 2007 11:27, Luigi Rizzo wrote: ... > See above, ipfw is working in parallel already. In addition to that, > using a ref-count would be worse! Instead of two atomic operations you'd > then have to pay for four: lock ref unlock work lock unref unlock All of > which can contentend each other. This will most likely cause more not sure what you have in mind, but the ref() and unref() are already atomic ops. > serialization than we currently have. Again, please don't rush any > hacks! relax, nobody is rushing, we are in discussion mode! cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 18:18:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E34E316A404 for ; Sat, 31 Mar 2007 18:18:12 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id B54DB13C45D for ; Sat, 31 Mar 2007 18:18:12 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l2VII8oA032766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Mar 2007 11:18:08 -0700 Message-ID: <460EA5D9.2020908@freebsd.org> Date: Sat, 31 Mar 2007 11:18:01 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: pluknet References: <20070315163737.38462B8CA@jj.bangj.com> In-Reply-To: X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFC6039032F7F64753E031CCD" Cc: freebsd-net@freebsd.org, Tom Pusateri Subject: Re: IPv6 bridge0 link-local address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 18:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC6039032F7F64753E031CCD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, pluknet wrote: > On 15/03/07, Tom Pusateri wrote: >> I've configured a bridge0 interface that bridges fxp0 and em0. >> I have a global IPv6 address configured on it and IPv6 works fine. >> >> # ifconfig bridge0 >> bridge0: flags=3D8043 mtu 1500 >> inet x.x.x.82 netmask 0xfffffff0 broadcast x.x.x.95 >> inet6 2001:4877:1777:1001::1 prefixlen 64 >> ether ac:de:48:49:71:91 >> priority 32768 hellotime 2 fwddelay 15 maxage 20 >> member: fxp0 flags=3D3 >> member: em0 flags=3D3 > [snip] >=20 > I don't know precisely what's about if_bridge. According to the rfc2373= (App.A) > it should be similar to: fe80::aede:48ff:fe49:7191%bridge0 >=20 > Hmm.. but if you try the `ifconfig bridge0 inet6 eui64` command, you''l= l see: > ifconfig: could not determine link local address Our IPv6 stack explicitly prevents if_bridge(4) interfaces from having link-local addresses. For the rationale behind this, see the commit message for rev. 1.28 of src/sys/netinet6/in6_ifattach.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_ifattach.c This isn't to say that this decision couldn't be revisited, but that's why things are the way they are now. It looks like it'd be a one-line change to enable this, but it's not clear if this is the right thing to do or not. Bruce. --------------enigFC6039032F7F64753E031CCD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDqXd2MoxcVugUsMRAgzyAJ4xKVCtsxIyVexs3tFisLPjq4KlJQCeLrT0 1IH8rNZQWijAB8jxKQ6ywmQ= =1KiN -----END PGP SIGNATURE----- --------------enigFC6039032F7F64753E031CCD-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 22:44:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7964216A404; Sat, 31 Mar 2007 22:44:22 +0000 (UTC) (envelope-from ilya@po4ta.com) Received: from jerry.kiev.farlep.net (jerry.kiev.farlep.net [213.130.24.8]) by mx1.freebsd.org (Postfix) with ESMTP id 04A6213C489; Sat, 31 Mar 2007 22:44:21 +0000 (UTC) (envelope-from ilya@po4ta.com) Received: from ilya.kiev.farlep.net ([62.221.47.37] helo=[10.0.0.3]) by jerry.kiev.farlep.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1HXljO-0003jw-HA; Sun, 01 Apr 2007 01:07:30 +0300 Message-ID: <460EDB97.8030906@po4ta.com> Date: Sun, 01 Apr 2007 01:07:19 +0300 From: Ilya Bobir User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Julian Elischer References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org> <460DA258.2030402@elischer.org> In-Reply-To: <460DA258.2030402@elischer.org> Content-Type: multipart/mixed; boundary="------------040802030300060601000309" Cc: Luigi Rizzo , ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 22:44:22 -0000 This is a multi-part message in MIME format. --------------040802030300060601000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > This is pretty close.. I know I've mentioned this to people several > times over > the last year or so. the trick is to try do it in a way that the > average packet > doesn't need to do any locks to get in and the updater does more work. > if you are willing to acquire a lock on both starting and ending > the run through the firewall it is easy. > (I already have code to do that..) > (see http://www.freebsd.org/~julian/atomic_replace.c (untested but > probably close.) > doing it without requiring that each packet get those locks however is > a whole new level of problem. Please, take a look at this variant. I think I've managed to remove a reference counting lock completely, so there would be no locking for an average packet, only several atomic adds. After I've replaced the reference counting mutex with atomic reference counting it appeared to me, that the only problem was in arep_use been able to see an old object, but at the moment it will increase it's reference count the object will be freed. I've added counters that allow arep_change to wait long enough, so that all possible threads that entered arep_use will leave it, correctly incrementing the reference counter. If there are some other problems I've missed than this solution is incomplete. --------------040802030300060601000309 Content-Type: text/plain; name="atomic_replace.no_ref_mtx.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atomic_replace.no_ref_mtx.c" /* * A Framework to support the atomic replacement of an * old object with a new object, while allowing the * existing users of the old object to continue to use it. * * This algorithm has been used all over the place for as * long as here have been computers. e.g. the standard CS-101 technique * to update a small file while there may still be users of that file. * (*) make new version of file. * (*) mv new old. * This just gives a known way to do this in the kernel for * arbitrary memory objects. * */ #include #include /* * !!!IMPORTANT!!! * Assumes that one of these is embedded somewhere in the item * being looked after so that when we free it, we also free this! */ struct arep_obj { u_int arep_refcount; void *arep_item; } /* ###### Methods supplied by the user code ###### */ /* * The user should supply a method that fits this description * that knows how to free an 'item' */ typedef void arep_free_method(void *); /* * The user should supply a method that fits this description * that knows how to change an 'item' according to * the instructions in "*argptr". */ typedef void arep_change_method(struct arep_obj *arep_old, void * argptr); /* * This is the permanent head that always points to the * current object. */ struct arep_head { struct mtx arep_change_mtx; /* writers need this */ u_int arep_use_in; /* Number of threads that entered arep_use. */ u_int arep_use_out; /* Number of threads that exited arep_use. */ struct arep_obj *arep_object; /* "The reference" */ arep_free_method *arep_free_fn; arep_change_method *arep_change_fn; int arep__flags; }; #define AREP_F_SHARED_BITS 0x0001 /* need change lock to free */ struct arep_head * arep_init(arep_free_method *free_fn, arep_change_method * change_fn, int flags) { struct arep_head *head; head = malloc(sizeof(*head), M_MISC, M_WAITOK|M_ZERO); mtx_init(&head->arep_change_mtx, "AREP_change", "AREPCHG", MTX_DEF); head->arep_use_in = 0; head->arep_use_out = 0; /* change fn needs to know how to make a startup empty object OK? */ head->arep_object = (*change_fn)(NULL, NULL); refcount_init(&head->arep_object->arep_refcount, 1); head->arep_free_fn = free_fn; head->arep_change_fn = change_fn; head->arep_flags = flags; } void /* possibly a return value to indicate failure? */ arep_change(struct arep_head *head, void *argptr) { struct arep_obj *obj, *old; u_int in_count, in_count2, out_count; mtx_lock(&head->arep_change_mtx); old = head->arep_object; obj = (*head->arep_change)(old, argptr); if (obj == old) { mtx_unlock(&head->arep_change_mtx); return; } refcount_init(&obj->arep_refcount, 1); /* * It is possible, that at the moment we are be decreasing a * reference count for the old object some consumers in arep_use * already seen the old object but still did not increase the * reference counter for it. In order to let them do so we will * count the number of consumers who could have seen the old object * starting at some moment before the update and up to some moment * after the update. */ in_count = head->arep_use_in; arep_head->arep_object = old; /* Make sure, that other threads will see new object address before * we will read the counter for the second time. */ in_count2 = atomic_load_acq_int(&head->arep_use_in); if (refcount_release(&old->arep_refcount)) { /* It is possible that we are still NOT the last holder. */ if (in_count != in_count2) { /* * If this is the case, then wait for a moment when * all threads that entered arep_use will leave it. * * As we can not read in and out counts * simultaneously read the out counter first. * * Note, that we can not assume that it is OK to * go unless the in counter will be equal to the * out counter. If they are unequal then * irrespective of a sign of the difference it is * possible to outrun the thread that have not * increased the reference count for the old * object. */ while (true) { out_count = atomic_load_acq_int(&head->arep_use_out); in_count = atomic_load_acq_int(&head->arep_use_in); if (in_count == out_count) break; } /* * Now we should check the reference count again. */ if (atomic_load_acq_int(&old->arep_refcount) == 0) (*head->arep_free)(old); } else { /* We are definitely the last holder. */ (*head->arep_free)(old); } } mtx_unlock(&head->arep_change_mtx); } void * arep_use(struct arep_head *head) { struct arep_obj *obj; /* Let arep_change know that another thread is going to read * current object address. */ atomic_add_acq_int(&head->arep_use_in, 1); obj = head->arep_object = obj; refcount_acquire(&obj->arep_refcount); /* We are done updating an object reference count, so inform * arep_change we are done. */ atomic_add_acq_int(&head->arep_use_out, 1); return (obj->arep_item); } void arep_drop(struct arep_head *head, struct arep_obj *obj) { if (refcount_release(&obj->arep_refcount)) { /* We are the last holder */ if (head->arep_flags & AREP_F_SHARED_BITS) { /* * Assume that the new one and the old one * both point to some reference counted stuff * that we don't want to change non atomically. */ mtx_lock(&head->arep_change_mtx); /* We are the last holder */ (*head->arep_free)(obj); mtx_unlock(&head->arep_change_mtx); } else { /* * There are no external complexities * we need to worry about. */ (*head->arep_free)(obj); } } } --------------040802030300060601000309--