From bugmaster at FreeBSD.org Mon Jul 7 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 7 11:08:22 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200807071107.m67B70cw062068@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip 29 problems total. From sem at FreeBSD.org Mon Jul 7 14:06:32 2008 From: sem at FreeBSD.org (sem@FreeBSD.org) Date: Mon Jul 7 14:06:43 2008 Subject: bin/125370: [ipfw] increase a line buffer limit Message-ID: <200807071406.m67E6W3X083728@freefall.freebsd.org> Synopsis: [ipfw] increase a line buffer limit Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: sem Responsible-Changed-When: Mon Jul 7 14:06:09 UTC 2008 Responsible-Changed-Why: Over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=125370 From bu7cher at yandex.ru Wed Jul 9 07:24:30 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jul 9 07:24:37 2008 Subject: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION In-Reply-To: <20080313094356.GA9219@tin.it> References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> Message-ID: <487464E0.3090909@yandex.ru> Paolo Pisati wrote: >> add packet counter as well. That's all possible with one opcode, though... > > if anyone post an updated patch, i'll commit it. Hi, Paolo. Any progress in this? I updated patch: http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff -- WBR, Andrey V. Elsukov From nickhardcore at gmail.com Fri Jul 11 10:57:34 2008 From: nickhardcore at gmail.com (nickhardcore) Date: Fri Jul 11 10:57:40 2008 Subject: unknown option IPV6FIREWALL_VERBOSE when compiling Message-ID: <48773733.6040709@gmail.com> Hi list. I was following this guide (http://www.freebsd.org/doc/en/books/handbook/firewalls-ipfw.html) to configure and use IPFW on my FreeBSD 7 (is a vmware virtual machine but I don't think this is a problem) [root@hyperion /usr/src]$ uname -a FreeBSD hyperion.xxx.org 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #1: Wed Jul 2 19:48:58 CEST 2008 root@hyperion.xxx.org:/usr/obj/usr/src/sys/CUSTOM i386 But when compiling the kernel I have the following error: [root@hyperion /usr/src]# make buildkernel KERNCONF=CUSTOM -------------------------------------------------------------- >>> Kernel build for CUSTOM started on Thu Jul 10 23:21:45 CEST 2008 -------------------------------------------------------------- ===> CUSTOM mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/CUSTOM /usr/src/sys/i386/conf/CUSTOM /usr/src/sys/i386/conf/CUSTOM: unknown option "IPV6FIREWALL_VERBOSE" *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. The kernel configuration is a "GENERIC" with this few customizations: options ACCEPT_FILTER_HTTP options ACCEPT_FILTER_DATA options DEVICE_POLLING options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT I tried to update through cvsup the system and then recompile the kernel with the new options but the error is still there. Any idea? nick From az at FreeBSD.org Sat Jul 12 11:06:47 2008 From: az at FreeBSD.org (az@FreeBSD.org) Date: Sat Jul 12 11:06:53 2008 Subject: kern/106534: [ipfw] [panic] ipfw + dummynet Message-ID: <200807121106.m6CB6kl1092529@freefall.freebsd.org> Synopsis: [ipfw] [panic] ipfw + dummynet State-Changed-From-To: open->closed State-Changed-By: az State-Changed-When: Sat Jul 12 11:06:46 UTC 2008 State-Changed-Why: No way to repeat such panic http://www.freebsd.org/cgi/query-pr.cgi?pr=106534 From bugmaster at FreeBSD.org Mon Jul 14 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 14 11:08:02 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200807141106.m6EB6x0C014446@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From mragusa at gmail.com Wed Jul 16 20:39:35 2008 From: mragusa at gmail.com (Mike Ragusa) Date: Wed Jul 16 20:39:41 2008 Subject: ipfw and dynamic rulesets Message-ID: <523561090807161313l17d01288g29b4c7545d10d0d0@mail.gmail.com> I am using fwknop 1.9.5 and freebsd 7-stable with ipfw compiled into the kernel. I am currently unable to get ipfw to update the dynamic rulesets after i knock on the firewall and open up the ssh port. My ruleset is as follows ipfw add 010 allow from any to any via lo0 ipfw add 200 check-state ipfw add 203 allow all from any to any out keep-state setup 00010 allow ip from any to any via lo0 00200 check-state 00203 allow ip from any to any out setup keep-state 65535 deny ip from any to any fwknop uses rule 201 to add to the firewall and adds the rule 00201 allow tcp from 156.132.40.212 to any dst-port 22 keep-state when i run ipfw list or ipfw show, i see my ruleset but i do not see the dynamic rules which causes the connection to die once the fwknopd reaches its 30 second time out because nothing has been added to the state table/dynamic ruleset. Suggestions are welcome :) Thank You, Mike From kazi.sharif at aonb.com.bd Sun Jul 20 05:33:37 2008 From: kazi.sharif at aonb.com.bd (Kazi A. Sharif) Date: Sun Jul 20 05:33:45 2008 Subject: IPFW+Dummynet Capability Message-ID: <4882C7E6.8010604@aonb.com.bd> Hello Guys, I was planning to install a heavy duty bandwidth manager for my ISP. I went through some documentation and installed IPFW and Dummynet in FreeBSD 7.0. Before I spent so much time on this I need to know the limitations that are already noticed: 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies Bandwidth manager, how efficient is the IPFW+Dummynet? 2. Is it possible to control/throttle 800/900Mbps bandwidth using recommended hardware? 3. Can I shape bandwidth for 3000 to 5000 clients with Dummynet where concurrent connectivity would be 2000 to 3000? 4. If I can serve 5000 users then what would be the performance decreasing ratio? 5. If I can not use Dummynet for my requirement then what are the recommendations? Thanks in advance. Sharif From freebsdlists at bsdunix.ch Sun Jul 20 12:41:52 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Sun Jul 20 12:41:59 2008 Subject: IPFW+Dummynet Capability In-Reply-To: <4882C7E6.8010604@aonb.com.bd> References: <4882C7E6.8010604@aonb.com.bd> Message-ID: <03690B01-2B1A-4AC0-88BC-3C0504C5B9B3@bsdunix.ch> Hello Am 20.07.2008 um 01:06 schrieb Kazi A. Sharif: > Hello Guys, > I was planning to install a heavy duty bandwidth manager for my ISP. > I went through some documentation and installed IPFW and Dummynet in > FreeBSD 7.0. Before I spent so much time on this I need to know the > limitations that are already noticed: > > 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies > Bandwidth manager, how efficient is the IPFW+Dummynet? > 2. Is it possible to control/throttle 800/900Mbps bandwidth using > recommended hardware? We use something similiar to make sure that certain ip ranges always get the best performance. Simulating some kind of QoS and set a max bandwidth for everything. We figured out that the limit with this Xeon is somewhere between 200-300Mbps with a few IPFW+Dummynet rules. We also tested a slower quad cores but the performance was even worse. UP systems with fast CPU where the best choice so far for us. At the moment our system runs with 6.2 but to be honest i don't belive that the performance gets trippled with FreeBSD 7. Our hardware: Intel(R) Xeon(TM) CPU 3.20GHz (3199.10-MHz 686-class CPU) and intel em cards ( References: <4882C7E6.8010604@aonb.com.bd> <03690B01-2B1A-4AC0-88BC-3C0504C5B9B3@bsdunix.ch> Message-ID: <48835C35.3010707@aonb.com.bd> Hello Thomas, Thanks for the reply. It seems I am not in the right track. I used Emerging Technologies commercial bandwidth manager. It was tested with 2000 rules and the total traffic was 25Mbps. It is build on UNIX OS. I heard that Allot is also able to use many rules. In Mikrotik we can create Queue/Queue group/Firewall/IP based MRTG Graph/Time-based QoS and they say that it is tested with Gigabit traffic. My current requirement is bellow 100Mbps but there will have at least 4000 clients that means 4000 IPs. We use the packages 64, 96, 128, 256, 512, 1024/1024kbps and so on. We used to create 2 rules for each user, one for bandwidth and another for firewall or MAC binding with IP. After a lot of searching on IPFW+Dummynet I didn't find a good IP based in/out traffic graphing way through SNMP or something like that, I checked for Time-based QoS on IPFW+Dummynet and saw a patch but its not granted, I wanted to use name with rule number but I don't think uid/gid is what I was looking for. So do you think there is a way to use IPFW+Dummynet using table to reduce number of rules and for at least 100Mbps traffic? You may have other suggestions to use Altq+PF or something similar. I think I should spent time on this if my above requirements are achievable. Thanking Sharif Thomas Vogt wrote: > Hello > > Am 20.07.2008 um 01:06 schrieb Kazi A. Sharif: >> Hello Guys, >> I was planning to install a heavy duty bandwidth manager for my ISP. >> I went through some documentation and installed IPFW and Dummynet in >> FreeBSD 7.0. Before I spent so much time on this I need to know the >> limitations that are already noticed: >> >> 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies >> Bandwidth manager, how efficient is the IPFW+Dummynet? >> 2. Is it possible to control/throttle 800/900Mbps bandwidth using >> recommended hardware? > > We use something similiar to make sure that certain ip ranges always > get the best performance. Simulating some kind of QoS and set a max > bandwidth for everything. > > > We figured out that the limit with this Xeon is somewhere between > 200-300Mbps with a few IPFW+Dummynet rules. We also tested a slower > quad cores but the performance was even worse. UP systems with fast > CPU where the best choice so far for us. At the moment our system runs > with 6.2 but to be honest i don't belive that the performance gets > trippled with FreeBSD 7. > > Our hardware: > Intel(R) Xeon(TM) CPU 3.20GHz (3199.10-MHz 686-class CPU) and intel em > cards ( > In the past Ian Freislich mentioned at performance@ that AMD Opterons > are maybe faster because of the bigger L1 cache. You will get less > cache misses with it. > > We could squeeze a bit more speed with ipfw table keyword. In > gerneral, the less rule you have the better performance you will get. > > There is also an dummynet issue with FreeBSD 7.0. We just used > dummynet to limit a ftp server to 500Mpbs and had a lot of kernel > panics. Oleg Bulyzhin wrote a patch: > http://www.freebsd.org/cgi/query-pr.cgi?prp=113548-3-diff > > As far as i know this patch is not included in 7.0-Release and i'm not > sure if it was ever commited to -stable or -head. > > Regards, > Thomas Vogt > _______________________________________________ > 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 julian at elischer.org Sun Jul 20 18:21:28 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Jul 20 18:21:35 2008 Subject: IPFW+Dummynet Capability In-Reply-To: <4882C7E6.8010604@aonb.com.bd> References: <4882C7E6.8010604@aonb.com.bd> Message-ID: <48838230.40608@elischer.org> Kazi A. Sharif wrote: > Hello Guys, > I was planning to install a heavy duty bandwidth manager for my ISP. I > went through some documentation and installed IPFW and Dummynet in > FreeBSD 7.0. Before I spent so much time on this I need to know the > limitations that are already noticed: > 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies > Bandwidth manager, how efficient is the IPFW+Dummynet? probably not as efficient.. > 2. Is it possible to control/throttle 800/900Mbps bandwidth using > recommended hardware? It'll be pushing hard to do that. > 3. Can I shape bandwidth for 3000 to 5000 clients with Dummynet where > concurrent connectivity would be 2000 to 3000? "maybe" > 4. If I can serve 5000 users then what would be the performance > decreasing ratio? no idea > 5. If I can not use Dummynet for my requirement then what are the > recommendations? a dedicated load controlling device. You are going to have to do significant tuning with FreeBSD to be able to do this, and if you do not want to become a guru in ipfw and network processing in the BSD kernel then it is a much better use of your time to research some dedicated hardware. If my boss told me I had to do this, I'd say, "I don't know if it's possible with FreeBSD.. I'll need to do some testing" and if it was close I'd consider doing it because I have confidencein my knowledge of the networking code, that I cold probably hack the kernel enough to give me a specdial purpose kernel that could do it, but if it wasn't close I wouldn't bother. My suspicion is that it won't be "close" at this time, but the only thing you can try is to simulate it. > Thanks in advance. > Sharif > > > _______________________________________________ > 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 ganbold at micom.mng.net Mon Jul 21 03:11:04 2008 From: ganbold at micom.mng.net (Ganbold) Date: Mon Jul 21 03:11:11 2008 Subject: IPFW+Dummynet Capability In-Reply-To: <48835C35.3010707@aonb.com.bd> References: <4882C7E6.8010604@aonb.com.bd> <03690B01-2B1A-4AC0-88BC-3C0504C5B9B3@bsdunix.ch> <48835C35.3010707@aonb.com.bd> Message-ID: <4883F4E8.30909@micom.mng.net> Kazi A. Sharif wrote: > Hello Thomas, > Thanks for the reply. It seems I am not in the right track. I used > Emerging Technologies commercial bandwidth manager. It was tested with > 2000 rules and the total traffic was 25Mbps. It is build on UNIX OS. Emerging technologies use FreeBSD. See the FAQ: http://www.etinc.com/index.php?page=bwmgrfaq.htm > I heard that Allot is also able to use many rules. In Mikrotik we can > create Queue/Queue group/Firewall/IP based MRTG Graph/Time-based QoS > and they say that it is tested with Gigabit traffic. > My current requirement is bellow 100Mbps but there will have at least > 4000 clients that means 4000 IPs. We use the packages 64, 96, 128, > 256, 512, 1024/1024kbps and so on. We used to create 2 rules for each > user, one for bandwidth and another for firewall or MAC binding with IP. > After a lot of searching on IPFW+Dummynet I didn't find a good IP > based in/out traffic graphing way through SNMP or something like that, > I checked for Time-based QoS on IPFW+Dummynet and saw a patch but its > not granted, I wanted to use name with rule number but I don't think > uid/gid is what I was looking for. > So do you think there is a way to use IPFW+Dummynet using table to > reduce number of rules and for at least 100Mbps traffic? You may have > other suggestions to use Altq+PF or something similar. > I think I should spent time on this if my above requirements are > achievable. > Thanking > Sharif > > > > Thomas Vogt wrote: >> Hello >> >> Am 20.07.2008 um 01:06 schrieb Kazi A. Sharif: >>> Hello Guys, >>> I was planning to install a heavy duty bandwidth manager for my ISP. >>> I went through some documentation and installed IPFW and Dummynet in >>> FreeBSD 7.0. Before I spent so much time on this I need to know the >>> limitations that are already noticed: >>> >>> 1. If we compare IPFW+Dummynet with Allot or Emerging Technologies >>> Bandwidth manager, how efficient is the IPFW+Dummynet? >>> 2. Is it possible to control/throttle 800/900Mbps bandwidth using >>> recommended hardware? >> >> We use something similiar to make sure that certain ip ranges always >> get the best performance. Simulating some kind of QoS and set a max >> bandwidth for everything. >> >> >> We figured out that the limit with this Xeon is somewhere between >> 200-300Mbps with a few IPFW+Dummynet rules. We also tested a slower >> quad cores but the performance was even worse. UP systems with fast >> CPU where the best choice so far for us. At the moment our system >> runs with 6.2 but to be honest i don't belive that the performance >> gets trippled with FreeBSD 7. >> >> Our hardware: >> Intel(R) Xeon(TM) CPU 3.20GHz (3199.10-MHz 686-class CPU) and intel >> em cards (> >> In the past Ian Freislich mentioned at performance@ that AMD >> Opterons are maybe faster because of the bigger L1 cache. You will >> get less cache misses with it. >> >> We could squeeze a bit more speed with ipfw table keyword. In >> gerneral, the less rule you have the better performance you will get. >> >> There is also an dummynet issue with FreeBSD 7.0. We just used >> dummynet to limit a ftp server to 500Mpbs and had a lot of kernel >> panics. Oleg Bulyzhin wrote a patch: >> http://www.freebsd.org/cgi/query-pr.cgi?prp=113548-3-diff >> >> As far as i know this patch is not included in 7.0-Release and i'm >> not sure if it was ever commited to -stable or -head. >> >> Regards, >> Thomas Vogt >> _______________________________________________ >> 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" >> >> > > _______________________________________________ > 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" > > > -- ONE THING KIDS LIKE is to be tricked. For instance, I was going to take my little nephew to Disneyland, but instead I drove him to a burned-out warehouse. "Oh, oh," I said. "Disneyland burned down." He cried and cried, but I think that deep down he thought it was a pretty good joke. I started to drive over to the real Disneyland, but it was getting pretty late. -- Jack Handey, The New Mexican, 1988 From bugmaster at FreeBSD.org Mon Jul 21 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 21 11:07:55 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200807211106.m6LB6uwS031900@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From bugmaster at FreeBSD.org Mon Jul 28 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 28 11:08:01 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200807281106.m6SB6wus078938@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From jeff+freebsd at wagsky.com Tue Jul 29 16:01:14 2008 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Tue Jul 29 16:01:21 2008 Subject: ipfw "bug" - recv any = not recv any Message-ID: <488F3A23.7070203@wagsky.com> The "recv any" = "not recv any" = noop behavior got me this weekend, even after careful reading of the man page. My situation is attempting to use "not recv any" to discriminate between packets generated by the host from those being routed through the host. It is reasonably easy to confirm that, at least in 7.0-RELEASE-p3, "recv any" and "not recv any" are both behaving as no-ops in the ipfw syntax. This was discussed to some extent in the post and related thread: Luigi Rizzo wrote: > ok, so the problem is the following: when i implemented ipfw2 > i thought that 'recv any' or 'xmit any' were effectively NOPs > so the parser erroneously removes them, together with any 'not' prefix > (which is processed before). > > To fix this one should > - patch the function ipfw2.c:fill_iface() > so that an argument of 'any' puts some special pattern > in the ipfw_insn_if (e.g. an * in the first char of name[] > should suffice as i doubt it is a legal interface name). > > [...] While there are ways to do this (e.g., tagging, or "[not] recv *"), I would suggest at least clarification of the documentation. At this point, I suspect that there are enough "overly cautious" rule writers that have included "recv any" in their now-deployed rules that (properly for them) match both externally and internally generated packets that changing "recv any" to only match packets that were received would break more things than it fixes. Changing the parsing of "not recv any" to produce the code behind "not recv *" would be "less dangerous" and might be considered at some time. Let me preface this by saying that I don't know the internals of ipfw2 well enough to confirm that a doc change like this matches the operation of the code, but something along the lines of: recv | xmit | via {ifX | if* | ipno | * } Matches packets received, transmitted or going through, respec- tively, the interface specified by exact name (ifX), by device name (if*), by IP address, or through some interface (*). The via keyword causes the interface to always be checked. If recv or xmit is used instead of via, then only the receive or transmit interface (respectively) is checked. By specifying both, it is possible to match packets based on both receive and transmit interface, e.g.: ipfw add deny ip from any to any out recv ed0 xmit ed1 The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in is invalid) whenever xmit is used. A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface. To match packets that have no receive interface, the construct "not recv *" may be used. The constructs "recv any" and "not recv any" are presently both treated equivalently as a match-all condition and both are stripped during parsing. This behavior, especially of the latter, is subject to change in future releases, and is not suggested for new rule sets. I hope this post at least helps the next person who trips across this. I'm very open to ideas on how to clarify and/or improve the behavior. I haven't looked into the other "any" matches to see if they have similar behavior that would benefit from additional documentation Jeff P.S. Thanks to Julian Elischer for suggesting "not recv *" as an approach.