From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 10 11:03:14 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3033816A506 for ; Mon, 10 Jul 2006 11:03:14 +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 3C0E843D5F for ; Mon, 10 Jul 2006 11:03:05 +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 k6AB35bb055655 for ; Mon, 10 Jul 2006 11:03:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6AB34ZJ055651 for freebsd-ipfw@freebsd.org; Mon, 10 Jul 2006 11:03:04 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jul 2006 11:03:04 GMT Message-Id: <200607101103.k6AB34ZJ055651@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 11:03:14 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/04/22] kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules f [2003/04/24] kern/51341 ipfw [ipfw] [patch] ipfw rule 'deny icmp from o [2004/11/13] kern/73910 ipfw [ipfw] serious bug on forwarding of packe o [2004/11/19] kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or r o [2005/03/13] conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should exce o [2005/05/11] bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC o [2005/11/08] kern/88659 ipfw [modules] ipfw and ip6fw do not work prop o [2006/02/13] kern/93300 ipfw ipfw pipe lost packets o [2006/03/29] kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/v o [2006/05/19] kern/97504 ipfw [ipfw] IPFW Rules bug o [2006/05/26] kern/97951 ipfw [ipfw] [patch] ipfw does not tie interfac o [2006/06/11] kern/98831 ipfw [ipfw] ipfw has UDP hickups 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/u o [2002/12/10] kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetim o [2003/02/11] kern/48172 ipfw [ipfw] [patch] ipfw does not log size and o [2003/03/10] kern/49086 ipfw [ipfw] [patch] Make ipfw2 log to differen o [2003/04/09] bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses p o [2003/08/26] kern/55984 ipfw [ipfw] [patch] time based firewalling sup o [2003/12/30] kern/60719 ipfw [ipfw] Headerless fragments generate cryp o [2004/08/03] kern/69963 ipfw [ipfw] install_state warning about alread o [2004/09/04] kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites dest o [2004/10/22] kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [B o [2004/10/29] kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parse o [2005/03/13] bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machi o [2005/05/05] kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RUL o [2005/06/28] kern/82724 ipfw [ipfw] [patch] Add setnexthop and default o [2005/10/05] kern/86957 ipfw [ipfw] [patch] ipfw mac logging o [2005/10/07] kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface imple o [2006/01/16] kern/91847 ipfw [ipfw] ipfw with vlanX as the device o [2006/02/16] kern/93422 ipfw ipfw divert rule no longer works in 6.0 ( o [2006/03/31] bin/95146 ipfw [ipfw][patch]ipfw -p option handler is bo 19 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 12 18:13:44 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3DD316A4E0 for ; Wed, 12 Jul 2006 18:13:44 +0000 (UTC) (envelope-from adamt@commspeed.net) Received: from es1.corp.commspeed.net (es1.corp.commspeed.net [216.19.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF11A43D7D for ; Wed, 12 Jul 2006 18:13:16 +0000 (GMT) (envelope-from adamt@commspeed.net) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Jul 2006 11:13:11 -0700 Message-ID: <48DC429CB053B64EAD91BDD1DE106A11675DAE@es1.corp.commspeed.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFW Dummynet Bridge Limiting Thread-Index: Acal3tXug0ySFVeITS279NU1/82DSg== From: "Adam M. Towarnyckyj" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPFW Dummynet Bridge Limiting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 18:13:44 -0000 Hey all, =20 I have searched and searched and searched and can't seem to come up with the answer to this little mystery I have going on here. Maybe I could get some help from this large group of people who are much smarter than I am. I have a FreeBSD machine running 6.1-RC that has three NICs, two of which are acting as a bridge. It's a pretty standard setup. What I am attempting to accomplish is bandwidth limiting using dummynet over this bridge. Here's the network layout: =20 INTERNET ---- Core Router ---- Bridge (limiter) ---- Border Router ---- Customer Base =20 The reason for the bridge between two routers is because we also have our server farm between those routers. The customer base consists of multiple routed networks and they all get public IPs. The problem I'm having is that the bridge is not limiting any of the customer IPs. I see packets flowing through the IPFW rules but they're not being passed to the pipes. I will show the configuration momentarily. The weird thing is, I am able to unplug the Border Router from this whole setup and plug a laptop in to the bridge and set it up so the laptop IP is limited. This setup works fine and I can limit the laptop the way I expect the rest of the network to be. Here's my configuration with the Border Router plugged in and the 216.19.50.37 IP being used in the "Customer Base": =20 ---Kernel Config--- options SMP # Symmetric MultiProcessor Kernel options IPFIREWALL # Firewall support options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET # Traffic limiting options BRIDGE options HZ=3D1000 # strongly recommended by dummynet(4) device apic # I/O APIC =20 ---Sysctl--- net.inet.ip.fw.enable=3D1 net.inet.ip.fw.one_pass=3D1 net.link.ether.bridge_cfg=3Dem0,em1 net.link.ether.bridge.enable=3D1 net.link.ether.bridge_ipfw=3D1 net.inet.ip.fw.dyn_buckets=3D256 net.inet.ip.fw.curr_dyn_buckets=3D256 =20 ---rc.conf--- defaultrouter=3D"[mydefaultrouter]" hostname=3D"[myhostname]" ifconfig_bge0=3D"[mymanagementinterface]" cloned_interfaces=3D"bridge0" ifconfig_bridge0=3D"addm em0 addm em1 up" ifconfig_em0=3D"up" ifconfig_em1=3D"up" sshd_enable=3D"YES" firewall_enable=3D"YES" firewall_script=3D"/etc/rc.firewall.bwmg" # this just runs ipfw with the rules supplied in custom_firewall below firewall_quiet=3D"NO" firewall_logging=3D"YES" firewall_flags=3D"" =20 ---ifconfig---- -snip- em0: flags=3D8943 mtu = 1500 options=3D8 ether 00:04:23:cb:60:aa media: Ethernet autoselect (100baseTX ) status: active em1: flags=3D8943 mtu = 1500 options=3D8 ether 00:04:23:cb:60:ab media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 bridge0: flags=3D8043 mtu 1500 ether ac:de:48:ce:fe:5c priority 32768 hellotime 2 fwddelay 15 maxage 20 member: em1 flags=3D3 member: em0 flags=3D3 =20 ---custom_firewall--- -q flush -q queue flush -q pipe flush add 1 allow all from any to any via lo0 add 2 deny all from any to 127.0.0.0/8 add 3 deny all from 127.0.0.0/8 to any add 4 skipto 65534 all from any to any via bge0 add 65534 allow all from any to any add 100 pipe 100 config bw 100Kbit/s add 10 pipe 100 all from any to 216.19.50.37 recv em0 =20 # ipfw show 10 00010 11430 925353 pipe 100 all from any to 216.19.50.37 recv em0 =20 # ipfw pipe show 100 00100: 100.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 216.109.112.135/0 216.19.50.37/0 11434 925679 0 0 0 =20 I have tried many different configurations including changing net.inet.ip.fw.one_pass to 0, changing the ipfw rule to recv and xmit on BOTH devices of the bridge, changing the ipfw rule from all to tcp and ip, and changing the rule from "any to 216.19.50.37" to "216.19.50.37 to any" (recv and xmit on both interfaces). I've also tried the kernel without IPDIVERT and with if_bridge. As I stated before, the odd thing is that when I plug directly into it with an IP of 216.19.0.225 (can't use the other one here) and modify the rules to reflect the new IP, the limiting works just fine. I have a feeling this is where the problem is, but I can't quite think of any reason why this wouldn't work. Previously, I had a Linux machine running TC installed in place of this machine but I personally prefer FreeBSD and feel ipfw is easier to configure than tc. The Linux machine worked just fine. =20 Could anyone possibly help with this little problem? I'm stuck. Also, if I forgot to include any information, I apologize. I'm a bit spacey when I write emails. Just let me know what I missed and I can explain further. Thanks. =20 Adam From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 12 22:48:34 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C2C16A4DE for ; Wed, 12 Jul 2006 22:48:34 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51AC743D46 for ; Wed, 12 Jul 2006 22:48:30 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from localhost (unknown [88.158.112.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id C8DC224C6CA for ; Thu, 13 Jul 2006 00:13:05 +0200 (CEST) Date: Thu, 13 Jul 2006 01:48:26 +0300 From: vladone X-Mailer: The Bat! (v3.80.03) Professional X-Priority: 3 (Normal) Message-ID: <19183199.20060713014826@spaingsm.com> To: ipfw@freebsd.org In-Reply-To: <48DC429CB053B64EAD91BDD1DE106A11675DAE@es1.corp.commspeed.net> References: <48DC429CB053B64EAD91BDD1DE106A11675DAE@es1.corp.commspeed.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: IPFW Dummynet Bridge Limiting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 22:48:34 -0000 Hello Adam, Wednesday, July 12, 2006, 9:13:11 PM, you wrote: > Hey all, > > I have searched and searched and searched and can't seem to > come up with the answer to this little mystery I have going on here. > Maybe I could get some help from this large group of people who are much > smarter than I am. I have a FreeBSD machine running 6.1-RC that has > three NICs, two of which are acting as a bridge. It's a pretty standard > setup. What I am attempting to accomplish is bandwidth limiting using > dummynet over this bridge. Here's the network layout: > > INTERNET ---- Core Router ---- Bridge (limiter) ---- Border Router ---- > Customer Base > > The reason for the bridge between two routers is because we > also have our server farm between those routers. The customer base > consists of multiple routed networks and they all get public IPs. The > problem I'm having is that the bridge is not limiting any of the > customer IPs. I see packets flowing through the IPFW rules but they're > not being passed to the pipes. I will show the configuration > momentarily. The weird thing is, I am able to unplug the Border Router > from this whole setup and plug a laptop in to the bridge and set it up > so the laptop IP is limited. This setup works fine and I can limit the > laptop the way I expect the rest of the network to be. Here's my > configuration with the Border Router plugged in and the 216.19.50.37 IP > being used in the "Customer Base": > > ---Kernel Config--- > options SMP # Symmetric MultiProcessor > Kernel > options IPFIREWALL # Firewall support > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT > options DUMMYNET # Traffic limiting > options BRIDGE > options HZ=1000 # strongly recommended by > dummynet(4) > device apic # I/O APIC > > ---Sysctl--- > net.inet.ip.fw.enable=1 > net.inet.ip.fw.one_pass=1 > net.link.ether.bridge_cfg=em0,em1 > net.link.ether.bridge.enable=1 > net.link.ether.bridge_ipfw=1 > net.inet.ip.fw.dyn_buckets=256 > net.inet.ip.fw.curr_dyn_buckets=256 > > ---rc.conf--- > defaultrouter="[mydefaultrouter]" > hostname="[myhostname]" > ifconfig_bge0="[mymanagementinterface]" > cloned_interfaces="bridge0" > ifconfig_bridge0="addm em0 addm em1 up" > ifconfig_em0="up" > ifconfig_em1="up" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall.bwmg" # this just runs ipfw with > the rules supplied in custom_firewall below > firewall_quiet="NO" > firewall_logging="YES" > firewall_flags="" > > ---ifconfig---- > -snip- > em0: flags=8943 mtu 1500 > options=8 > ether 00:04:23:cb:60:aa > media: Ethernet autoselect (100baseTX ) > status: active > em1: flags=8943 mtu 1500 > options=8 > ether 00:04:23:cb:60:ab > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8043 mtu 1500 > ether ac:de:48:ce:fe:5c > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: em1 flags=3 > member: em0 flags=3 > > ---custom_firewall--- > -q flush > -q queue flush > -q pipe flush > add 1 allow all from any to any via lo0 > add 2 deny all from any to 127.0.0.0/8 > add 3 deny all from 127.0.0.0/8 to any > add 4 skipto 65534 all from any to any via bge0 > add 65534 allow all from any to any > add 100 pipe 100 config bw 100Kbit/s > add 10 pipe 100 all from any to 216.19.50.37 recv em0 > > # ipfw show 10 > 00010 11430 925353 pipe 100 all from any to 216.19.50.37 > recv em0 > > # ipfw pipe show 100 > 00100: 100.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 icmp 216.109.112.135/0 216.19.50.37/0 11434 925679 0 > 0 0 > > I have tried many different configurations including > changing net.inet.ip.fw.one_pass to 0, changing the ipfw rule to recv > and xmit on BOTH devices of the bridge, changing the ipfw rule from all > to tcp and ip, and changing the rule from "any to 216.19.50.37" to > "216.19.50.37 to any" (recv and xmit on both interfaces). I've also > tried the kernel without IPDIVERT and with if_bridge. As I stated > before, the odd thing is that when I plug directly into it with an IP of > 216.19.0.225 (can't use the other one here) and modify the rules to > reflect the new IP, the limiting works just fine. I have a feeling this > is where the problem is, but I can't quite think of any reason why this > wouldn't work. Previously, I had a Linux machine running TC installed in > place of this machine but I personally prefer FreeBSD and feel ipfw is > easier to configure than tc. The Linux machine worked just fine. > > Could anyone possibly help with this little problem? I'm > stuck. Also, if I forgot to include any information, I apologize. I'm a > bit spacey when I write emails. Just let me know what I missed and I can > explain further. Thanks. > > Adam > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" I dont't use it bridge but some thinks that can help u: 1. use corect syctl variables form: net.link.ether.bridge.ipfw instead net.link.ether.bridge_ipfw (probably an wrong typing) 2. read the end from man page about bridge, and net.inet.ip.fw.one_pass variable. "Also remember that bridged packets are accepted after the first pass through the firewall irrespective of the setting of the sysctl variable net.inet.ip.fw.one_pass, and that some ipfw(8) actions such as divert do not apply to bridged packets. It might be useful to have a rule of the form skipto 20000 ip from any to any bridged " 3. Luigi Rizzo say in his documentation: "there is always one pass for bridged packets" -- Best regards, vladone mailto:vladone@spaingsm.com From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 12 23:37:21 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD1C16A4DD for ; Wed, 12 Jul 2006 23:37:21 +0000 (UTC) (envelope-from adamt@commspeed.net) Received: from es1.corp.commspeed.net (es1.corp.commspeed.net [216.19.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79AED43D46 for ; Wed, 12 Jul 2006 23:37:21 +0000 (GMT) (envelope-from adamt@commspeed.net) 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, 12 Jul 2006 16:37:19 -0700 Message-ID: <48DC429CB053B64EAD91BDD1DE106A11675DE6@es1.corp.commspeed.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFW Dummynet Bridge Limiting Thread-Index: AcamCKO7OnOu5WbHS4+Rf18Xu3YaZwAAK6bw From: "Adam M. Towarnyckyj" To: Cc: Subject: RE: IPFW Dummynet Bridge Limiting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 23:37:21 -0000 Vladone, Thanks much for the response. I looked into what you were telling me and here are the results: 1) This wasn't a typo. Apparently, after looking into it, I've seen both options used on different websites and setups. Either way though, I checked these both with sysctl and they are both set to 1. 2) I missed that part of the man page and thanks for clarifying. This is where I get confused. Am I using DIVERT to get packets to the proper pipe? If so, then how can I get it to work properly with many many many rules (one for each customer IP)? If not, then does this option really matter? 3) This part I did read and I'm still slightly confused. Once placed into the proper pipe, I don't want it to continue down the line of rules to search for another match. I like it where it is because it matched the IP and should be limited, correct? Also, I have tried my setup with the one_pass variable on and off. Neither way worked for me anyways. Upon further investigation, I noticed when I set up my laptop with the 216.19.50.37 address and add the rule to match "all" to the pipe, I lose all connectivity. I am unable to ping or pull web pages. Somehow, I originally thought the problem was that there was no limiting going on. This must be because I had a ping running in the background and had the rule set up to limit ip. Now I think what is happening is the packets are getting dropped or not arriving at the destination like they're supposed to. Thanks again. Adam -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of vladone Sent: Wednesday, July 12, 2006 3:48 PM To: ipfw@freebsd.org Subject: Re: IPFW Dummynet Bridge Limiting Hello Adam, I dont't use it bridge but some thinks that can help u: 1. use corect syctl variables form: net.link.ether.bridge.ipfw instead net.link.ether.bridge_ipfw (probably an wrong typing) 2. read the end from man page about bridge, and net.inet.ip.fw.one_pass variable. "Also remember that bridged packets are accepted after the first pass through the firewall irrespective of the setting of the sysctl variable net.inet.ip.fw.one_pass, and that some ipfw(8) actions such as divert do not apply to bridged packets. It might be useful to have a rule of the form skipto 20000 ip from any to any bridged " 3. Luigi Rizzo say in his documentation: "there is always one pass for bridged packets" --=20 Best regards, vladone mailto:vladone@spaingsm.com _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Fri Jul 14 09:21:22 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E30316A4DD for ; Fri, 14 Jul 2006 09:21:22 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3D6843D53 for ; Fri, 14 Jul 2006 09:21:20 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from localhost (unknown [88.158.112.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id 3E11B24C692 for ; Fri, 14 Jul 2006 10:45:45 +0200 (CEST) Date: Fri, 14 Jul 2006 12:21:09 +0300 From: vladone X-Mailer: The Bat! (v3.80.03) Professional X-Priority: 3 (Normal) Message-ID: <1406932981.20060714122109@spaingsm.com> To: ipfw@freebsd.org In-Reply-To: <48DC429CB053B64EAD91BDD1DE106A11675DE6@es1.corp.commspeed.net> References: <48DC429CB053B64EAD91BDD1DE106A11675DE6@es1.corp.commspeed.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re[2]: IPFW Dummynet Bridge Limiting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 09:21:22 -0000 Hello Adam, Thursday, July 13, 2006, 2:37:19 AM, you wrote: > Vladone, > Thanks much for the response. I looked into what you were > telling me and here are the results: > 1) This wasn't a typo. Apparently, after looking into it, I've seen both > options used on different websites and setups. Either way though, I > checked these both with sysctl and they are both set to 1. > 2) I missed that part of the man page and thanks for clarifying. This is > where I get confused. Am I using DIVERT to get packets to the proper > pipe? If so, then how can I get it to work properly with many many many > rules (one for each customer IP)? If not, then does this option really > matter? > 3) This part I did read and I'm still slightly confused. Once placed > into the proper pipe, I don't want it to continue down the line of rules > to search for another match. I like it where it is because it matched > the IP and should be limited, correct? > Also, I have tried my setup with the one_pass variable on and off. > Neither way worked for me anyways. > Upon further investigation, I noticed when I set up my laptop with the > 216.19.50.37 address and add the rule to match "all" to the pipe, I lose > all connectivity. I am unable to ping or pull web pages. Somehow, I > originally thought the problem was that there was no limiting going on. > This must be because I had a ping running in the background and had the > rule set up to limit ip. Now I think what is happening is the packets > are getting dropped or not arriving at the destination like they're > supposed to. > Thanks again. > Adam > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org > [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of vladone > Sent: Wednesday, July 12, 2006 3:48 PM > To: ipfw@freebsd.org > Subject: Re: IPFW Dummynet Bridge Limiting > Hello Adam, > I dont't use it bridge but some thinks that can help u: > 1. use corect syctl variables form: net.link.ether.bridge.ipfw > instead net.link.ether.bridge_ipfw (probably an wrong typing) > 2. read the end from man page about bridge, and > net.inet.ip.fw.one_pass variable. > "Also remember that bridged packets are accepted after the first pass > through the firewall irrespective of the setting of the sysctl > variable > net.inet.ip.fw.one_pass, and that some ipfw(8) actions such as > divert do > not apply to bridged packets. It might be useful to have a rule of > the > form > skipto 20000 ip from any to any bridged > " > 3. Luigi Rizzo say in his > documentation: "there is always one pass for bridged packets" First: if u want to apply aan queue or pipe, for many IP's, u can use option mask in pipe or queue. U can get examples about that in dummynet documentation. For bridge, try to use "bridge" option in ipfw rules, to match packtets that are bridged. If u want to pass packetes across multiple pipe or queue, then need to set net.inet.ip.fw.one_pass=0 For clients that have public IP's, natd have an option to not translate this adresses. Recomandation: Begin with very simple rules, without any pipe or queue, only count option, and see what is happening. Then grow complexity, in this mode u can find where u wrong. -- Best regards, vladone mailto:vladone@spaingsm.com From owner-freebsd-ipfw@FreeBSD.ORG Fri Jul 14 09:23:10 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F63116A4DA for ; Fri, 14 Jul 2006 09:23:10 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id A38BA43D45 for ; Fri, 14 Jul 2006 09:23:09 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from localhost (unknown [88.158.112.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id CAA9724C692 for ; Fri, 14 Jul 2006 10:47:34 +0200 (CEST) Date: Fri, 14 Jul 2006 12:23:03 +0300 From: vladone X-Mailer: The Bat! (v3.80.03) Professional X-Priority: 3 (Normal) Message-ID: <1855971350.20060714122303@spaingsm.com> To: ipfw@freebsd.org In-Reply-To: <1406932981.20060714122109@spaingsm.com> References: <48DC429CB053B64EAD91BDD1DE106A11675DE6@es1.corp.commspeed.net> <1406932981.20060714122109@spaingsm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re[3]: IPFW Dummynet Bridge Limiting X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 09:23:10 -0000 Hello vladone, Friday, July 14, 2006, 12:21:09 PM, you wrote: > Hello Adam, > Thursday, July 13, 2006, 2:37:19 AM, you wrote: >> Vladone, >> Thanks much for the response. I looked into what you were >> telling me and here are the results: >> 1) This wasn't a typo. Apparently, after looking into it, I've seen both >> options used on different websites and setups. Either way though, I >> checked these both with sysctl and they are both set to 1. >> 2) I missed that part of the man page and thanks for clarifying. This is >> where I get confused. Am I using DIVERT to get packets to the proper >> pipe? If so, then how can I get it to work properly with many many many >> rules (one for each customer IP)? If not, then does this option really >> matter? >> 3) This part I did read and I'm still slightly confused. Once placed >> into the proper pipe, I don't want it to continue down the line of rules >> to search for another match. I like it where it is because it matched >> the IP and should be limited, correct? >> Also, I have tried my setup with the one_pass variable on and off. >> Neither way worked for me anyways. >> Upon further investigation, I noticed when I set up my laptop with the >> 216.19.50.37 address and add the rule to match "all" to the pipe, I lose >> all connectivity. I am unable to ping or pull web pages. Somehow, I >> originally thought the problem was that there was no limiting going on. >> This must be because I had a ping running in the background and had the >> rule set up to limit ip. Now I think what is happening is the packets >> are getting dropped or not arriving at the destination like they're >> supposed to. >> Thanks again. >> Adam >> -----Original Message----- >> From: owner-freebsd-ipfw@freebsd.org >> [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of vladone >> Sent: Wednesday, July 12, 2006 3:48 PM >> To: ipfw@freebsd.org >> Subject: Re: IPFW Dummynet Bridge Limiting >> Hello Adam, >> I dont't use it bridge but some thinks that can help u: >> 1. use corect syctl variables form: net.link.ether.bridge.ipfw >> instead net.link.ether.bridge_ipfw (probably an wrong typing) >> 2. read the end from man page about bridge, and >> net.inet.ip.fw.one_pass variable. >> "Also remember that bridged packets are accepted after the first pass >> through the firewall irrespective of the setting of the sysctl >> variable >> net.inet.ip.fw.one_pass, and that some ipfw(8) actions such as >> divert do >> not apply to bridged packets. It might be useful to have a rule of >> the >> form >> skipto 20000 ip from any to any bridged >> " >> 3. Luigi Rizzo say in his >> documentation: "there is always one pass for bridged packets" > First: if u want to apply aan queue or pipe, for many IP's, u can use option mask > in pipe or queue. U can get examples about that in dummynet > documentation. > For bridge, try to use "bridge" option in ipfw rules, to match packtets > that are bridged. > If u want to pass packetes across multiple pipe or queue, then need > to set net.inet.ip.fw.one_pass=0 > For clients that have public IP's, natd have an option to not > translate this adresses. > Recomandation: > Begin with very simple rules, without any pipe or queue, only count > option, and see what is happening. Then grow complexity, in this mode > u can find where u wrong. Sorry, for my mistake, option for ipfw is named "bridged". -- Best regards, vladone mailto:vladone@spaingsm.com From owner-freebsd-ipfw@FreeBSD.ORG Sat Jul 15 19:00:28 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4297216A4DA for ; Sat, 15 Jul 2006 19:00:28 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from mail.spaingsm.com (llwb135.servidoresdns.net [217.76.137.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF17943D4C for ; Sat, 15 Jul 2006 19:00:02 +0000 (GMT) (envelope-from vladone@spaingsm.com) Received: from localhost (unknown [88.158.112.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.spaingsm.com (Postfix) with ESMTP id 2A68C24C658 for ; Sat, 15 Jul 2006 20:24:14 +0200 (CEST) Date: Sat, 15 Jul 2006 21:59:58 +0300 From: vladone X-Mailer: The Bat! (v3.80.03) Professional X-Priority: 3 (Normal) Message-ID: <58885595.20060715215958@spaingsm.com> To: ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: about hash_size, max_chain_len and buckets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vladone List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 19:00:28 -0000 Hi! I have some questions about this parameters. Default value for this are: net.inet.ip.dummynet.hash_size: 64 net.inet.ip.dummynet.max_chain_len: 16 I want understand some thinks! 64X16=1024 (this is right :) ) Now questions: 1. If i have more than 1024 pipe or queue, what is happening? 2. if pipe or queue are dropped when exceed this value (1024), what need to increase, hash_size or max_chain_len? 3. I have for example this situation: one pipe, with two queue connected, with mask option this is what show command "ipfw queue show": q00001: weight 1 pipe 1 20 sl. 45 queues (64 buckets) droptail q00002: weight 10 pipe 1 20 sl. 44 queues (64 buckets) droptail a) how many queue can have with default settings? b) how many queue are in pipe 1? 45+44? c)if i have this situation: q00001: weight 1 pipe 1 20 sl. 3000 queues (64 buckets) droptail q00002: weight 10 pipe 1 20 sl. 3000 queues (64 buckets) droptail what settings need to make for pipe 1 and queue's 1 and 2 (refering to buckets parameter, that is same with hash_size but affect only pipe or queue where are defined), or to hash_size respectively max_chain_len, in order to work right? Thanks anticipate anyone for reply, and i think that disscution is good to clear up this elements! -- Best regards, vladone mailto:vladone@spaingsm.com