From owner-freebsd-ipfw@FreeBSD.ORG Sun May 4 16:07:59 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D4121065676 for ; Sun, 4 May 2008 16:07:59 +0000 (UTC) (envelope-from budiyt@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBA28FC12 for ; Sun, 4 May 2008 16:07:58 +0000 (UTC) (envelope-from budiyt@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so250319wah.3 for ; Sun, 04 May 2008 09:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=40cXzaGxBU9XGh6xRpEqbQshLnPE3EYipn0eCa2e/VQ=; b=YxNFXWZ/i+LdEcVVTlkW8YLUMv49zzn/bm4vlHPYIGZQSh324bNwrabOMuYoHF6OtqqG15gzHen/pXnyqYrgtaQvTwtoKfKN4Iet1of+WAoKfeuGpzhcMKuLvA/lKgDNOFz/elALs7dNBII40pQzzyXTlVuoD32A9T1QLzyTnPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qN+w7HS4n/VFoMlol9msEHNkoezKTec/f72YG/6x7NxO09c7eVPZgGj1GCYWv7D8riFWpHXS4oF1ziCPicqhacK3tCdIba1JLZBa6Jf5LKFsl5oZUtz2lT2ol4NZZHgRpNLOTiaxSO5j7GXr+yepH1jXC3AT5ha/aLveY0cNZQo= Received: by 10.114.171.1 with SMTP id t1mr4826384wae.83.1209915624050; Sun, 04 May 2008 08:40:24 -0700 (PDT) Received: by 10.114.131.6 with HTTP; Sun, 4 May 2008 08:40:24 -0700 (PDT) Message-ID: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> Date: Sun, 4 May 2008 22:40:24 +0700 From: budsz To: freebsd-ipfw@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Syntax base IP 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: Sun, 04 May 2008 16:07:59 -0000 Hallo, I've rule in /etc/rc.firewall like this: ifint0="rl0" ippriviix="192.168.0.0/24" ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" portlim="20-21,80,88,443,2009,8080,8088,10007,18755" bwunlimit="197Kbit/s" ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } ${portlim} via ${ifint0} ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to ${ippriviix} via ${ifint0} ${fwcmd} pipe 1 config bw ${bwunlimit} Executing firewall I got error message like this: #sh /etc/rc.firewall ipfw: opcode 6 size 33 wrong ipfw: getsockopt(IP_FW_ADD): Invalid argument ipfw: opcode 2 size 33 wrong ipfw: getsockopt(IP_FW_ADD): Invalid argument This error happened after I adding new IP Address 202.93.247.28/32 on $ipunlimit variable. It that correct to add 202.93.247.26/32 and 202.93.247.28/32 together? or I should rewrite like 202.93.247.26/29?. But already same on $ipunlimit variable like 202.93.20.22/32 and 202.93.20.23/32 this is no problem. Any clue or suggestion about this syntax? Thanks You -- budsz From owner-freebsd-ipfw@FreeBSD.ORG Mon May 5 11:07:07 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D8D10656BA for ; Mon, 5 May 2008 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E17418FC29 for ; Mon, 5 May 2008 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m45B76Eh070730 for ; Mon, 5 May 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m45B76p1070726 for freebsd-ipfw@FreeBSD.org; Mon, 5 May 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2008 11:07:06 GMT Message-Id: <200805051107.m45B76p1070726@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org 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, 05 May 2008 11:07:07 -0000 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 [ipfw] [patch] ipfw verbosity locks machine if /etc/rc 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 30 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 09:00:48 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F18811065672 for ; Tue, 6 May 2008 09:00:48 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3.yandex.ru (smtp3.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD998FC2D for ; Tue, 6 May 2008 09:00:48 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:17613 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S4748060AbYEFJAl (ORCPT ); Tue, 6 May 2008 13:00:41 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp3 X-Yandex-TimeMark: 1210064441 X-MsgDayCount: 2 X-Comment: RFC 2476 MSA function at smtp3.yandex.ru logged sender identity as: bu7cher Message-ID: <48201E0D.60803@yandex.ru> Date: Tue, 06 May 2008 12:59:57 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: budsz References: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> In-Reply-To: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org Subject: Re: Syntax base IP 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: Tue, 06 May 2008 09:00:49 -0000 budsz wrote: > ipunlimit="192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ > 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ > 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ > 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ > 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" > ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } > ${portlim} via ${ifint0} > ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to > ${ippriviix} via ${ifint0} > Executing firewall I got error message like this: > #sh /etc/rc.firewall > ipfw: opcode 6 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > ipfw: opcode 2 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument It means that your src and dst addresses are too long. > Any clue or suggestion about this syntax? Try to use lookup tables. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 11:50:56 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1928106564A for ; Tue, 6 May 2008 11:50:56 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 141C08FC1A for ; Tue, 6 May 2008 11:50:55 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m46Ajfjh061032 for ; Tue, 6 May 2008 07:45:41 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Tue, 6 May 2008 07:48:18 -0300 User-Agent: KMail/1.9.7 References: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> In-Reply-To: <4d4dc3640805040840t5725fb4ejfd19da3c3f78ec73@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200805060748.18487.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: Syntax base IP 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: Tue, 06 May 2008 11:50:56 -0000 On Sunday 04 May 2008 12:40:24 budsz wrote: > Hallo, > > I've rule in /etc/rc.firewall like this: > > ifint0=3D"rl0" > ippriviix=3D"192.168.0.0/24" > ipunlimit=3D"192.168.0.100/32,10.35.4.1/32,202.129.189.42/32,\ > 202.129.189.45/32,125.163.77.180/32,202.43.167.70/32,\ > =20 > 202.43.167.72/32,202.43.161.119/32,202.10.32.10/32,202.93.20.22/32,\ > 202.93.20.23/32,202.93.20.24/32,122.102.49.132/32,\ > 202.43.161.124/32,202.93.247.26/32,202.93.247.28/32" if you can not use tables you can write a for loop with skipto pefore the p= ipe for items in $ipunlimit; do ipfw add 100 skipto $rulenumber_after_pipe ip from $items to any done pipe rules (where you like to add in or out to via) > portlim=3D"20-21,80,88,443,2009,8080,8088,10007,18755" > bwunlimit=3D"197Kbit/s" > > ${fwcmd} add 100 pipe 1 ip from ${ippriviix} to { not ${ipunlimit} } > ${portlim} via ${ifint0} > ${fwcmd} add 101 pipe 1 ip from { not ${ipunlimit} } ${portlim} to > ${ippriviix} via ${ifint0} > ${fwcmd} pipe 1 config bw ${bwunlimit} > > Executing firewall I got error message like this: > #sh /etc/rc.firewall > ipfw: opcode 6 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > ipfw: opcode 2 size 33 wrong > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > This error happened after I adding new IP Address 202.93.247.28/32 on > $ipunlimit variable. > It that correct to add 202.93.247.26/32 and 202.93.247.28/32 together? > or I should rewrite like > 202.93.247.26/29?. But already same on $ipunlimit variable like > 202.93.20.22/32 and 202.93.20.23/32 this is no problem. > > Any clue or suggestion about this syntax? > > Thanks You =2D-=20 Participe no BAIXO ASSINADO SCM: http://info.matik.com.br =2D- Atenciosamente, J.M. Respons=E1vel Plant=E3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =A0(18)8112.7007 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 19:25:15 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 823D71065671 for ; Tue, 6 May 2008 19:25:15 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from mail.oanda.com (q9.oanda.com [216.220.44.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF108FC20 for ; Tue, 6 May 2008 19:25:14 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from localhost (localhost [127.0.0.1]) by mail.oanda.com (Postfix) with ESMTP id 5BA35EC07E for ; Tue, 6 May 2008 15:03:44 -0400 (EDT) Received: from mail.oanda.com ([127.0.0.1]) by localhost (mail.q9.oanda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28775-09 for ; Tue, 6 May 2008 15:03:44 -0400 (EDT) Received: from gateway.oanda.com (unknown [216.235.10.210]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oanda.com (Postfix) with ESMTP id 47F92EC020 for ; Tue, 6 May 2008 15:03:44 -0400 (EDT) Received: from [10.1.5.123] (mpope.dev.oanda.com [10.1.5.123]) by eddie.dev.oanda.com (Postfix) with ESMTP id 2AE2364063 for ; Tue, 6 May 2008 15:03:44 -0400 (EDT) Message-ID: <4820AB8F.2000204@oanda.com> Date: Tue, 06 May 2008 15:03:43 -0400 From: Matthew Pope User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: dummynet queue size relative to bw setting? 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: Tue, 06 May 2008 19:25:15 -0000 Hello, I've been reading about dummynet for 2 weeks, including the seminal ACM paper & I'm very impressed. I've configured and run some preliminary simulations that have my colleagues quite interested too. However, I'm finding my delay settings are yielding delays of about two orders of magnitude larger that requested. I believe I don't understand the relationship very well that defines the setting of the queue size to relative to the bandwidth setting (and plr?) Can someone explain or point me to a source for this? I recall reading that with lower bandwidths one should use lower queue sizes to avoid long queuing delays. So I presume that is why my delays are so long. So I've run some tests with various queue sizes. With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm consistently getting RT delays of 500-600ms with a ping test, packet loss does come out around 5%. The target I'm pinging is normally a 40 ms latency. At Queue size 120 I get 100% packet loss (but I can ignore that). I am not a networking specialist, so I realize my question is ignorant :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB RAM using a modification of the dummynet test network design described at codefromthe70s.org Thanks, Matthew From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 19:34:24 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF3C106566B for ; Tue, 6 May 2008 19:34:24 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from mail.oanda.com (q9.oanda.com [216.220.44.222]) by mx1.freebsd.org (Postfix) with ESMTP id 268EB8FC22 for ; Tue, 6 May 2008 19:34:23 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from localhost (localhost [127.0.0.1]) by mail.oanda.com (Postfix) with ESMTP id 8593DEC07E for ; Tue, 6 May 2008 15:34:23 -0400 (EDT) Received: from mail.oanda.com ([127.0.0.1]) by localhost (mail.q9.oanda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00970-04 for ; Tue, 6 May 2008 15:34:23 -0400 (EDT) Received: from gateway.oanda.com (unknown [216.235.10.210]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oanda.com (Postfix) with ESMTP id 6F839EC027 for ; Tue, 6 May 2008 15:34:23 -0400 (EDT) Received: from [10.1.5.123] (mpope.dev.oanda.com [10.1.5.123]) by eddie.dev.oanda.com (Postfix) with ESMTP id 2B73F64063 for ; Tue, 6 May 2008 15:34:23 -0400 (EDT) Message-ID: <4820B2BF.6090608@oanda.com> Date: Tue, 06 May 2008 15:34:23 -0400 From: Matthew Pope User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4820AB8F.2000204@oanda.com> In-Reply-To: <4820AB8F.2000204@oanda.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: dummynet queue size relative to bw setting? 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: Tue, 06 May 2008 19:34:24 -0000 I must correct my test parameters: In one of the two pipes, the bw was 4K, not 48K as stated. When I just now moved it up to 48K to match the other pipe size, my ping times plummeted to 129-139ms throughout the Queue sizes listed below, again with Q=120 getting total packet loss. I thought a ping sent packets slowly, so that the 4K bw on the one pipe would not slow things down, but it seems I was wrong. Still I'm wondering why the measured delay is 130, without dummynet its 40, and I've set it to 5ms in each direction, so it should be measured as 50, not 130. Thx, Matthew > Hello, > I've been reading about dummynet for 2 weeks, including the seminal > ACM paper & I'm very impressed. I've configured and run some > preliminary simulations that have my colleagues quite interested too. > > However, I'm finding my delay settings are yielding delays of about > two orders of magnitude larger that requested. I believe I don't > understand the relationship very well that defines the setting of the > queue size to relative to the bandwidth setting (and plr?) Can > someone explain or point me to a source for this? > > I recall reading that with lower bandwidths one should use lower queue > sizes to avoid long queuing delays. So I presume that is why my > delays are so long. So I've run some tests with various queue sizes. > > With Queue sizes of 100, 80, 60, 40, 10 slots on a pipe with a bw of > 48Kbits/s, delay of 5ms, and plr 0.025 defined in each direction, I'm > consistently getting RT delays of 500-600ms with a ping test, packet > loss does come out around 5%. The target I'm pinging is normally a 40 > ms latency. At Queue size 120 I get 100% packet loss (but I can > ignore that). > > I am not a networking specialist, so I realize my question is ignorant > :-) I'm running this in VMWare Server on a dual core 2 GHz with 2 GB > RAM using a modification of the dummynet test network design described > at codefromthe70s.org > Thanks, > Matthew > > From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 20:21:52 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 439D41065671 for ; Tue, 6 May 2008 20:21:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id F31B08FC33 for ; Tue, 6 May 2008 20:21:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D4DEB731A6; Tue, 6 May 2008 22:06:51 +0200 (CEST) Date: Tue, 6 May 2008 22:06:51 +0200 From: Luigi Rizzo To: Matthew Pope Message-ID: <20080506200651.GA57251@onelab2.iet.unipi.it> References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4820B2BF.6090608@oanda.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: dummynet queue size relative to bw setting? 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: Tue, 06 May 2008 20:21:52 -0000 On Tue, May 06, 2008 at 03:34:23PM -0400, Matthew Pope wrote: > I must correct my test parameters: In one of the two pipes, the bw was > 4K, not 48K as stated. > When I just now moved it up to 48K to match the other pipe size, my ping > times plummeted to 129-139ms throughout the Queue sizes listed below, > again with Q=120 getting total packet loss. > I thought a ping sent packets slowly, so that the 4K bw on the one pipe > would not slow things down, but it seems I was wrong. Still I'm > wondering why the measured delay is 130, without dummynet its 40, and > I've set it to 5ms in each direction, so it should be measured as 50, > not 130. Thx, Matthew part of the delay is the time it takes for the bits of the packet to go through the bandwidth-limited channel - this is called "transmission delay" and is transmission_delay = packet_size_in_bits/bandwidth_in_bits_per_second Also, depending on how you configure dummynet, your ping request and response can go through a pipe multiple times (for a proper configuration, usually you traverse one pipe downstream and one pipe upstream; if the system is misconfigured, e.g. as a router with dummynet intercepting traffic on both interfaces, you will traverse two pipes on each direction). The typical ping packet is around 64 bytes or 512 bits, at 48Kbit/s this makes an additional 12ms each way, so you should see no less than 40+(5+12)*2 = 74 ms for a proper configuration, and 40+(5+12)*4 = 108 ms if misconfigured, the latter is very similar to the numbers you are seeing. On top of this, VMware doesn't emulate well enough the timing, so it is likely that the clock ticks every 10ms instead of the 1ms expected by the hardware, so some of the individual delays (5ms for the pipe, 12ms for the transmission time) could be further rounded to the next multiple of the clock tick, which would increase the delay even further. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 20:31:47 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01AE0106564A for ; Tue, 6 May 2008 20:31:47 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from mail.oanda.com (q9.oanda.com [216.220.44.222]) by mx1.freebsd.org (Postfix) with ESMTP id A934B8FC15 for ; Tue, 6 May 2008 20:31:46 +0000 (UTC) (envelope-from mpope@oanda.com) Received: from localhost (localhost [127.0.0.1]) by mail.oanda.com (Postfix) with ESMTP id 02E1FEC083; Tue, 6 May 2008 16:31:46 -0400 (EDT) Received: from mail.oanda.com ([127.0.0.1]) by localhost (mail.q9.oanda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24669-04; Tue, 6 May 2008 16:31:45 -0400 (EDT) Received: from gateway.oanda.com (unknown [216.235.10.210]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oanda.com (Postfix) with ESMTP id DBED2EC07E; Tue, 6 May 2008 16:31:45 -0400 (EDT) Received: from [10.1.5.123] (mpope.dev.oanda.com [10.1.5.123]) by eddie.dev.oanda.com (Postfix) with ESMTP id BB71A64063; Tue, 6 May 2008 16:31:45 -0400 (EDT) Message-ID: <4820C031.4000707@oanda.com> Date: Tue, 06 May 2008 16:31:45 -0400 From: Matthew Pope User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Luigi Rizzo References: <4820AB8F.2000204@oanda.com> <4820B2BF.6090608@oanda.com> <20080506200651.GA57251@onelab2.iet.unipi.it> In-Reply-To: <20080506200651.GA57251@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: dummynet queue size relative to bw setting? 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: Tue, 06 May 2008 20:31:47 -0000 Luigi Rizzo wrote: > On Tue, May 06, 2008 at 03:34:23PM -0400, Matthew Pope wrote: > >> I must correct my test parameters: In one of the two pipes, the bw was >> 4K, not 48K as stated. >> When I just now moved it up to 48K to match the other pipe size, my ping >> times plummeted to 129-139ms throughout the Queue sizes listed below, >> again with Q=120 getting total packet loss. >> I thought a ping sent packets slowly, so that the 4K bw on the one pipe >> would not slow things down, but it seems I was wrong. Still I'm >> wondering why the measured delay is 130, without dummynet its 40, and >> I've set it to 5ms in each direction, so it should be measured as 50, >> not 130. Thx, Matthew >> > > part of the delay is the time it takes for the bits of the packet > to go through the bandwidth-limited channel - this is called > "transmission delay" and is > > transmission_delay = packet_size_in_bits/bandwidth_in_bits_per_second > > Also, depending on how you configure dummynet, your ping request > and response can go through a pipe multiple times (for a proper > configuration, usually you traverse one pipe downstream and one > pipe upstream; if the system is misconfigured, e.g. as a router > with dummynet intercepting traffic on both interfaces, > you will traverse two pipes on each direction). > > > The typical ping packet is around 64 bytes or 512 bits, at 48Kbit/s > this makes an additional 12ms each way, so you should see > no less than 40+(5+12)*2 = 74 ms for a proper configuration, and > 40+(5+12)*4 = 108 ms if misconfigured, the latter is very similar to > the numbers you are seeing. > > On top of this, VMware doesn't emulate well enough the timing, > so it is likely that the clock ticks every 10ms instead of the 1ms > expected by the hardware, so some of the individual delays > (5ms for the pipe, 12ms for the transmission time) could be > further rounded to the next multiple of the clock tick, > which would increase the delay even further. > > cheers > luigi > > Thanks so much Luigi! This little tutorial (and VMWare comment) is exactly what I needed to understand what was going on. And thank you for Dummynet, a very significant contribution to multi-cast routing and simulation. Matthew From owner-freebsd-ipfw@FreeBSD.ORG Tue May 6 21:11:55 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E7B4106564A for ; Tue, 6 May 2008 21:11:55 +0000 (UTC) (envelope-from marconemlt@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id 210B08FC17 for ; Tue, 6 May 2008 21:11:54 +0000 (UTC) (envelope-from marconemlt@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so241992wra.13 for ; Tue, 06 May 2008 14:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=pHGt+7Kp5npE+vvvveSm89fOUydMMNogz8rYITdXbo8=; b=KIC8gA743aXmtwOQO81um7/XqkbG99WtVEZnVeMB+eAE4DI8nDmQ4XgKI2NYLhdnHGAUOUwrBESknmxjr+pXd3D7vvZPTM8uaGAG12EI8VfZAxh7MkB/F2+mYQvXRoqj5eXtAEr7qCK48HDSdr8sHxN3g39Div3f+MadMmo4Axc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=vCoDJHp/pOL6fbdRcv4u5p8u2Yu0FBF9HHu/hM67cPRixfjndFKjfgYI3qEhssMZ72b23uzHKH3D7uSaXp/psn8KAf85vP9beerE4QA2LM0YTJf4RxvTNY1wl/pzzvK/JIutwK8SfFhFfsqJPQoYEdyMtBtk3thmyJisb5VnzYA= Received: by 10.143.36.15 with SMTP id o15mr520898wfj.182.1210106766318; Tue, 06 May 2008 13:46:06 -0700 (PDT) Received: by 10.142.240.21 with HTTP; Tue, 6 May 2008 13:46:06 -0700 (PDT) Message-ID: Date: Tue, 6 May 2008 17:46:06 -0300 From: "Marcone Theisen" To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Redirect internal traffic (only port 80) to another link 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: Tue, 06 May 2008 21:11:55 -0000 Hi, I have 2 links, one em0 and other in vlan2 interface. My default route is em0. The problem is: I want to direct all internal Internet traffic (port 80) for the link in vlan2 interface. How to do it with the IPFW? Some information: Link em0 interface - 10.40.1.0 Interna network: em1 interface - 10.10.18.0 Link vlan2 interface - 192.168.7.0 The vlan2 interface is on Trunk port in switch. It's work. We have tried the following alternatives: I created another route: Route ADD 192.168.7.107 192.168.7.105 ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 Traffic continued through dedicated link. ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 redirect the traffic on the link vlan2, but did not return anything. ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 natd-s-m-n-vlan2 p 8669 Anything! All attempts without success. Thus, how I can redirect my internal Internet traffic to the VLAN2 link with IPFW ? Thank's, Marcone From owner-freebsd-ipfw@FreeBSD.ORG Wed May 7 09:57:07 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C52F106566C for ; Wed, 7 May 2008 09:57:07 +0000 (UTC) (envelope-from eenpint@hotmail.com) Received: from blu139-omc1-s26.blu139.hotmail.com (blu139-omc1-s26.blu139.hotmail.com [65.55.175.166]) by mx1.freebsd.org (Postfix) with ESMTP id 59DBF8FC1C for ; Wed, 7 May 2008 09:57:06 +0000 (UTC) (envelope-from eenpint@hotmail.com) Received: from BLU122-W33 ([65.55.162.182]) by blu139-omc1-s26.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 02:45:05 -0700 Message-ID: X-Originating-IP: [193.190.253.144] From: Tom Wuyts To: Marcone Theisen , Date: Wed, 7 May 2008 11:45:06 +0200 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2008 09:45:05.0991 (UTC) FILETIME=[07BA1D70:01C8B027] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Redirect internal traffic (only port 80) to another link 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, 07 May 2008 09:57:07 -0000 set in your rc.conf next line natd_flags=3D"-f /etc/natd.conf" and then add the file natd.conf in your etc/ folder interface em0 (if i'm not mistaking, i don't completely get your question) use_sockets yes dynamic yes redirect_port tcp 192.168.7.105:80 80 this should send all packets arriving at port 80 from your 10.0.0.0 network= to 192.168.7.105 and then restart your network /etc/netstart restart if he complains about natd, while restarting your network, kill natd with "= pkill natd" and then restart your network hope it helps, tom > Date: Tue, 6 May 2008 17:46:06 -0300 > From: marconemlt@gmail.com > To: freebsd-ipfw@freebsd.org > Subject: Redirect internal traffic (only port 80) to another link >=20 > Hi, >=20 > I have 2 links, one em0 and other in vlan2 interface. > My default route is em0. >=20 > The problem is: > I want to direct all internal Internet traffic (port 80) for the link in > vlan2 interface. > How to do it with the IPFW? >=20 > Some information: >=20 > Link em0 interface - 10.40.1.0 > Interna network: em1 interface - 10.10.18.0 > Link vlan2 interface - 192.168.7.0 >=20 > The vlan2 interface is on Trunk port in switch. It's work. >=20 > We have tried the following alternatives: >=20 > I created another route: > Route ADD 192.168.7.107 192.168.7.105 >=20 > ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 > Traffic continued through dedicated link. >=20 > ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 > redirect the traffic on the link vlan2, but did not return anything. >=20 > ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 > natd-s-m-n-vlan2 p 8669 > Anything! >=20 > All attempts without success. > Thus, how I can redirect my internal Internet traffic to the VLAN2 link w= ith > IPFW ? >=20 > Thank's, > Marcone > _______________________________________________ > 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" _________________________________________________________________ Nieuwe lente...Een nieuw online leven...Gratis dankzij Windows Live http://get.live.com= From owner-freebsd-ipfw@FreeBSD.ORG Wed May 7 21:55:28 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7FA3106564A for ; Wed, 7 May 2008 21:55:28 +0000 (UTC) (envelope-from marconemlt@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5D08FC12 for ; Wed, 7 May 2008 21:55:28 +0000 (UTC) (envelope-from marconemlt@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so263729wra.13 for ; Wed, 07 May 2008 14:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=ve2cOdED9/6YA3e4xmenZB72O6cJJEIiQIypqY0VIzo=; b=fussm9fXk6GzkHceTMPyWwiCoZJ9DYKBlsW+GGGo8WJgN0HrpqRkM9dQt9vKD71LYJbqTh5XrIjj7oeHzULmVjdL1/leBoEhY8zX5gZma793Vl+FHWfjNbnhLBND1BOBW1qQqNPEPS84Pogo9SfMiuqONggTt+vflFfBi7pPNZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CX4SDZy9uNLiXEbqq1mCJ5c7agfekMCZOVwCFZ4L2kncI5SiLvvvb+v4pxpB0gljHJjFEVOVxaK+7vGYjJrsIB1ksIwJZfC/X8ehU9DKvucYy0QKva6MMPZTNpkzJBA+whK3hpJw3Og/p3L/iqlI/oqzK4U4AD4VecZrEGD/fLA= Received: by 10.142.53.11 with SMTP id b11mr1066244wfa.314.1210197326752; Wed, 07 May 2008 14:55:26 -0700 (PDT) Received: by 10.142.240.21 with HTTP; Wed, 7 May 2008 14:55:26 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 18:55:26 -0300 From: "Marcone Theisen" To: "Tom Wuyts" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org Subject: Re: Redirect internal traffic (only port 80) to another link 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, 07 May 2008 21:55:28 -0000 Hi Tom, Thank's for the help, but not worked with the procedures below. The natd.conf file is ok, I'm restart the netstart and the natd. I think it may be the vlan. It's works fine, I can ping the gateway. But, I can route my internal traffic by vlan? With the command "trafshow -i vlan2" anything I can see. em0: flags=8843 mtu 1500 options=b inet6 fe80::211:43ff:fefd:3ff6%em0 prefixlen 64 scopeid 0x1 inet 10.40.4.1 netmask 0xffffff00 broadcast 10.40.4.255 ether 00:11:43:fd:3f:f6 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 mtu 1500 options=b inet 10.10.18.3 netmask 0xffffff00 broadcast 10.10.18.255 inet6 fe80::211:43ff:fefd:3ff7%em1 prefixlen 64 scopeid 0x2 ether 00:11:43:fd:3f:f7 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 vlan2: flags=8843 mtu 1500 inet6 fe80::211:43ff:fefd:3ff6%vlan2 prefixlen 64 duplicated scopeid 0x4 inet 192.168.7.106 netmask 0xfffffff8 broadcast 192.168.7.111 ether 00:11:43:fd:3f:f7 media: Ethernet autoselect (1000baseTX ) status: active vlan: 2 parent interface: em1 portal# ping 192.168.7.105 PING 192.168.7.105 (192.168.7.105): 56 data bytes 64 bytes from 192.168.7.105: icmp_seq=0 ttl=30 time=0.839 ms 64 bytes from 192.168.7.105: icmp_seq=1 ttl=30 time=0.763 ms Have any other alternative to test ? Thank's, Marcone 2008/5/7 Tom Wuyts : > set in your rc.conf next line > > natd_flags="-f /etc/natd.conf" > > and then add the file natd.conf in your etc/ folder > > interface em0 (if i'm not mistaking, i don't completely get your question) > use_sockets yes > dynamic yes > redirect_port tcp 192.168.7.105:80 80 > > this should send all packets arriving at port 80 from your 10.0.0.0network to > 192.168.7.105 > > and then restart your network > /etc/netstart restart > > if he complains about natd, while restarting your network, kill natd with > "pkill natd" and then restart your network > > hope it helps, > > tom > > > > ------------------------------ > > Date: Tue, 6 May 2008 17:46:06 -0300 > > From: marconemlt@gmail.com > > To: freebsd-ipfw@freebsd.org > > Subject: Redirect internal traffic (only port 80) to another link > > > > Hi, > > > > I have 2 links, one em0 and other in vlan2 interface. > > My default route is em0. > > > > The problem is: > > I want to direct all internal Internet traffic (port 80) for the link in > > vlan2 interface. > > How to do it with the IPFW? > > > > Some information: > > > > Link em0 interface - 10.40.1.0 > > Interna network: em1 interface - 10.10.18.0 > > Link vlan2 interface - 192.168.7.0 > > > > The vlan2 interface is on Trunk port in switch. It's work. > > > > We have tried the following alternatives: > > > > I created another route: > > Route ADD 192.168.7.107 192.168.7.105 > > > > ipfw add 00019 divert from 8668 ip 10.10.18.0/24 to any 80 via vlan2 > > Traffic continued through dedicated link. > > > > ipfw add 00019 fwd 192.168.7.105 tcp from 10.10.18.0/24 to any 80 > > redirect the traffic on the link vlan2, but did not return anything. > > > > ipfw add 00019 divert from 8669 ip 10.10.18.0/24 to any 80 via vlan2 > > natd-s-m-n-vlan2 p 8669 > > Anything! > > > > All attempts without success. > > Thus, how I can redirect my internal Internet traffic to the VLAN2 link > with > > IPFW ? > > > > Thank's, > > Marcone > > _______________________________________________ > > 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" > > ------------------------------ > Nieuwe lente...Een nieuw online leven...Helemaal gratis! Windows Live > > From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 01:42:28 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D55C106566C for ; Thu, 8 May 2008 01:42:28 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id D70028FC19 for ; Thu, 8 May 2008 01:42:27 +0000 (UTC) (envelope-from 482254ac@razorfever.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAEf3IUhMCrCL/2dsb2JhbACBUxqrXg X-IronPort-AV: E=Sophos;i="4.27,451,1204520400"; d="scan'208";a="20058721" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 07 May 2008 21:41:24 -0400 Received: from server.razorfever.net ([76.10.176.139]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id OGX12524 for ; Wed, 07 May 2008 21:41:24 -0400 Received: from [192.168.0.10] (newskool.razorfever.net [192.168.0.10]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id m481fNWv055027 for ; Wed, 7 May 2008 21:41:23 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <48225A43.3080909@razorfever.net> Date: Wed, 07 May 2008 21:41:23 -0400 From: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Dummynet, gif, and ipsec 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: Thu, 08 May 2008 01:42:28 -0000 Hello, I am trying to do some traffic shaping on my router using dummynet. The router is one endpoint in an ipsec tunnel (configured as the handbook suggests). I'm running voip inside ipsec, so the goal here is to minimize the delay in transmitting the encapsulated voip packets. I'd like to be able to classify other traffic inside ipsec as well. I currently have my outgoing pipe configured with 5 queues: pipe 10 config delay 0 #outgoing pipe send queue 101 config pipe 10 weight 100 #highest priority queue 102 config pipe 10 weight 20 queue 103 config pipe 10 weight 5 queue 104 config pipe 10 weight 1 #lowest priority I have all of my outgoing ipsec queued into queue 101, with most of my other traffic hitting the other queues. I have set up additional queues to run over top of my gif interfaces: pipe 20 config delay 0 #VPN outgoing pipe (gif*) send queue 201 config pipe 20 weight 100 #highest priority queue 202 config pipe 20 weight 20 queue 203 config pipe 20 weight 5 queue 204 config pipe 20 weight 1 #lowest priority As I'm running a tunnel, I have specific subnets that are communicating over the gif interfaces. If I simply allow the traffic, everything works fine: add 7200 allow ip from table(1) to table(1) If I try to queue traffic going out, packets disappear right after the queue: add 7020 queue 203 ip from table(1) to table(1) out via gif* add 7025 count ip from table(1) to table(1) out via gif* add 7200 allow ip from table(1) to table(1) I zero my stats, and let the traffic run for a little while. When I show my stats again, there is a gross discrepancy in the counts at 7020, and 7025. Packets that normally show up on the other end of the tunnel, don't. If I remove the count, the packets still don't show up. If anyone can recognize why this is happening, or provide suggestions on how to troubleshoot it, I'd greatly appreciate it. If your are doing a similar approach successfully, I'd like to know. If you have alternative suggestions on how to shape traffic based on what is inside an ipsec tunnel, that is also appreciated. I tried using IPFW's tag command, and I think that is the best way to do what I want to do, period. Tag the unencrypted data as it is going out the gif interface, and queue the IPSEC traffic based on the packet tag, but the tag disappears after IPSEC processing. Also, I'm aware of using the IP TOS flags for this, and I may have to go that route (based on the research I've done), but I want to know why what I'm currently is failing the way it is. The TOS flags don't seem as flexible, as there are only a few classes that I can use, and there isn't any built-in way to modify these flags. I'd have to use netgraph, or divert, and I'm not too keen on either of these approaches right now. Best regards, and thanks! -- Derek More details about the machine: Running 6.3-RELEASE /etc/sysctl.conf: net.inet.ip.fw.one_pass=0 Kernel: include SMP ident GW2 options MPTABLE_FORCE_HTT options NO_F00F_HACK options DEVICE_POLLING options AUTO_EOI_1 options IPSEC options IPSEC_ESP options IPSEC_FILTERGIF device carp device disc options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPDIVERT options IPSTEALTH options TCP_DROP_SYNFIN options DUMMYNET options ZERO_COPY_SOCKETS options HZ=1000 device snp From owner-freebsd-ipfw@FreeBSD.ORG Thu May 8 16:12:19 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B77106566B for ; Thu, 8 May 2008 16:12:19 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 081738FC17 for ; Thu, 8 May 2008 16:12:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1389267rvf.43 for ; Thu, 08 May 2008 09:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=8RyzlQs4cc5WdFiv4FdT9s5NP2JzE6GA3Mcdl7pebj8=; b=f1a66W7ZXL9Kg9C/f5v5LRxiUe/ciuO9bIYXMiP+sNWdh58GAcKkrc4s445LNPIQ1YvnQ6DbgbpcNjlE7OGnMO6va5kaMweMrM1YCS2efUI/mXwn7OQYJo5yC4OmCk2r+d2u9HxDWaduNsB2SbSBw5QMt7t94Wz/7PsK/rYKhjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Cnmf625WJmuSpx4MbgCC0g3m4K7NMGoCCIMH2Oqoz5Ba6qHb2ltxrK6iJ8m0D2NzC52MfImxmZXpwqdlO8Y1GSJzOQ0DAhdDEwqGOPry1ayOwI8rcdRt9odycuALpTfW6nI9cvwjL8d2pyTTDlO7dL2Gnh2KDRdxFuQkICPgh0U= Received: by 10.140.177.15 with SMTP id z15mr1596138rve.70.1210261499819; Thu, 08 May 2008 08:44:59 -0700 (PDT) Received: by 10.140.135.3 with HTTP; Thu, 8 May 2008 08:44:59 -0700 (PDT) Message-ID: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> Date: Thu, 8 May 2008 17:44:59 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: 482254ac@razorfever.net Subject: Re: Dummynet, gif, and ipsec 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: Thu, 08 May 2008 16:12:19 -0000 > Date: Wed, 07 May 2008 21:41:23 -0400 > From: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> > Subject: Dummynet, gif, and ipsec > To: freebsd-ipfw@freebsd.org > Message-ID: <48225A43.3080909@razorfever.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I am trying to do some traffic shaping on my router using dummynet. The > router is one endpoint in an ipsec tunnel (configured as the handbook > suggests). > > I'm running voip inside ipsec, so the goal here is to minimize the delay > in transmitting the encapsulated voip packets. I'd like to be able to > classify other traffic inside ipsec as well. > > I currently have my outgoing pipe configured with 5 queues: > > pipe 10 config delay 0 #outgoing pipe send > queue 101 config pipe 10 weight 100 #highest priority > queue 102 config pipe 10 weight 20 > queue 103 config pipe 10 weight 5 > queue 104 config pipe 10 weight 1 #lowest priority > > I have all of my outgoing ipsec queued into queue 101, with most of my > other traffic hitting the other queues. > > I have set up additional queues to run over top of my > gif interfaces: > > pipe 20 config delay 0 #VPN outgoing pipe (gif*) send > queue 201 config pipe 20 weight 100 #highest priority > queue 202 config pipe 20 weight 20 > queue 203 config pipe 20 weight 5 > queue 204 config pipe 20 weight 1 #lowest priority > > As I'm running a tunnel, I have specific subnets that are communicating > over the gif interfaces. > > If I simply allow the traffic, everything works fine: > > add 7200 allow ip from table(1) to table(1) > > If I try to queue traffic going out, packets disappear right after the > queue: > > add 7020 queue 203 ip from table(1) to table(1) out via gif* > add 7025 count ip from table(1) to table(1) out via gif* > add 7200 allow ip from table(1) to table(1) > > I zero my stats, and let the traffic run for a little while. When I > show my stats again, there is a gross discrepancy in the counts at 7020, > and 7025. Packets that normally show up on the other end of the tunnel, > don't. If I remove the count, the packets still don't show up. > > If anyone can recognize why this is happening, or provide suggestions on > how to troubleshoot it, I'd greatly appreciate it. > > If your are doing a similar approach successfully, I'd like to know. > > If you have alternative suggestions on how to shape traffic based on > what is inside an ipsec tunnel, that is also appreciated. > > I tried using IPFW's tag command, and I think that is the best way to do > what I want to do, period. Tag the unencrypted data as it is going out > the gif interface, and queue the IPSEC traffic based on the packet tag, > but the tag disappears after IPSEC processing. > > Also, I'm aware of using the IP TOS flags for this, and I may have to go > that route (based on the research I've done), but I want to know why > what I'm currently is failing the way it is. The TOS flags don't seem > as flexible, as there are only a few classes that I can use, and there > isn't any built-in way to modify these flags. I'd have to use netgraph, > or divert, and I'm not too keen on either of these approaches right now. > Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 as you are running. It is another alternative to dummynet though it have been tested with pf but should work with ipfw too since it knows about ALTQ. Hope it helps! Ermal Index: sys/net/if_enc.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/net/if_enc.c,v retrieving revision 1.5.2.2.2.1 diff -u -r1.5.2.2.2.1 if_enc.c --- sys/net/if_enc.c 29 Dec 2007 17:29:11 -0000 1.5.2.2.2.1 +++ sys/net/if_enc.c 10 Feb 2008 01:19:41 -0000 @@ -48,6 +48,8 @@ #include #include +#include + #include #include #include @@ -194,10 +196,12 @@ } int -ipsec_filter(struct mbuf **mp, int dir) +ipsec_filter(struct mbuf **mp, struct secasindex *saidx, int dir) { int error, i; struct ip *ip; + struct m_tag *t; + struct altq_tag *atag; KASSERT(encif != NULL, ("%s: encif is null", __func__)); @@ -267,6 +271,11 @@ if (error != 0) goto bad; + if (saidx && (t = m_tag_find(*mp, PACKET_TAG_PF_QID, NULL)) != NULL) { + atag = (struct altq_tag *)(t + 1); + saidx->qid = atag->qid; + } + return (error); bad: Index: sys/netipsec/ipsec.h =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec.h,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 ipsec.h --- sys/netipsec/ipsec.h 24 Jul 2006 23:20:59 -0000 1.8.2.2 +++ sys/netipsec/ipsec.h 8 Feb 2008 17:13:03 -0000 @@ -413,7 +413,7 @@ extern struct mbuf *m_makespace(struct mbuf *m0, int skip, int hlen, int *off); extern caddr_t m_pad(struct mbuf *m, int n); extern int m_striphdr(struct mbuf *m, int skip, int hlen); -extern int ipsec_filter(struct mbuf **, int); +extern int ipsec_filter(struct mbuf **, struct secasindex *, int); extern void ipsec_bpf(struct mbuf *, struct secasvar *, int); #endif /* _KERNEL */ Index: sys/netipsec/ipsec_input.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec_input.c,v retrieving revision 1.9.2.2 diff -u -r1.9.2.2 ipsec_input.c --- sys/netipsec/ipsec_input.c 24 Jul 2006 23:20:59 -0000 1.9.2.2 +++ sys/netipsec/ipsec_input.c 8 Feb 2008 16:53:05 -0000 @@ -451,7 +451,7 @@ ipsec_bpf(m, sav, AF_INET); if (prot != IPPROTO_IPIP) - if ((error = ipsec_filter(&m, 1)) != 0) + if ((error = ipsec_filter(&m, &sav->sah->saidx, 1)) != 0) return (error); #endif Index: sys/netipsec/ipsec_output.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/ipsec_output.c,v retrieving revision 1.10.8.1 diff -u -r1.10.8.1 ipsec_output.c --- sys/netipsec/ipsec_output.c 24 Jul 2006 23:20:59 -0000 1.10.8.1 +++ sys/netipsec/ipsec_output.c 9 Feb 2008 17:49:47 -0000 @@ -44,6 +44,9 @@ #include #include +#ifdef DEV_ENC +#include +#endif #include #include @@ -160,6 +163,25 @@ } key_sa_recordxfer(sav, m); /* record data transfer */ +#ifdef DEV_ENC + /* + * Restore previous queue selected by the classifier for the + * packet. + */ + if (saidx->qid) { + mtag = m_tag_get(PACKET_TAG_PF_QID, sizeof(struct altq_tag), + M_NOWAIT); + if (mtag != NULL) { /* Safe to ignore */ + struct altq_tag *atag; + atag = (struct altq_tag *)(mtag + 1); + atag->qid = saidx->qid; + /* add hints for ecn */ + atag->af = saidx->dst.sa.sa_family; + atag->hdr = NULL; /* This should be safe! */ + m_tag_prepend(m, mtag); + } + } +#endif /* * We're done with IPsec processing, transmit the packet using the * appropriate network protocol (IP or IPv6). SPD lookup will be @@ -362,7 +384,7 @@ #ifdef DEV_ENC /* pass the mbuf to enc0 for packet filtering */ - if ((error = ipsec_filter(&m, 2)) != 0) + if ((error = ipsec_filter(&m, &sav->sah->saidx, 2)) != 0) goto bad; #endif Index: sys/netipsec/keydb.h =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/keydb.h,v retrieving revision 1.5 diff -u -r1.5 keydb.h --- sys/netipsec/keydb.h 7 Jan 2005 01:45:46 -0000 1.5 +++ sys/netipsec/keydb.h 8 Feb 2008 17:12:01 -0000 @@ -58,6 +58,9 @@ u_int8_t mode; /* mode of protocol, see ipsec.h */ u_int32_t reqid; /* reqid id who owned this SA */ /* see IPSEC_MANUAL_REQID_MAX. */ + u_int32_t qid; /* used for ALTQ shaping inside */ + /* tunnel */ + }; /* Security Association Data Base */ Index: sys/netipsec/xform_ipip.c =================================================================== RCS file: /home/eri/FreeBSD/src/sys/netipsec/xform_ipip.c,v retrieving revision 1.11.2.2 diff -u -r1.11.2.2 xform_ipip.c --- sys/netipsec/xform_ipip.c 24 Jul 2006 23:20:59 -0000 1.11.2.2 +++ sys/netipsec/xform_ipip.c 8 Feb 2008 16:54:41 -0000 @@ -348,7 +348,7 @@ #ifdef DEV_ENC /* pass the mbuf to enc0 for packet filtering */ - if (ipsec_filter(&m, 1) != 0) + if (ipsec_filter(&m, NULL, 1) != 0) return; #endif > Best regards, and thanks! > -- Derek > > > > More details about the machine: > > Running 6.3-RELEASE > > /etc/sysctl.conf: > net.inet.ip.fw.one_pass=0 > > Kernel: > include SMP > ident GW2 > > options MPTABLE_FORCE_HTT > options NO_F00F_HACK > options DEVICE_POLLING > options AUTO_EOI_1 > > options IPSEC > options IPSEC_ESP > options IPSEC_FILTERGIF > > device carp > device disc > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_FORWARD > options IPDIVERT > options IPSTEALTH > options TCP_DROP_SYNFIN > options DUMMYNET > options ZERO_COPY_SOCKETS > options HZ=1000 From owner-freebsd-ipfw@FreeBSD.ORG Fri May 9 16:17:07 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712C9106564A for ; Fri, 9 May 2008 16:17:07 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33BCC8FC14 for ; Fri, 9 May 2008 16:17:06 +0000 (UTC) (envelope-from 482254ac@razorfever.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFABcWJEhMCrCL/2dsb2JhbACBUxqpSg X-IronPort-AV: E=Sophos;i="4.27,461,1204520400"; d="scan'208";a="20190245" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 09 May 2008 12:17:06 -0400 Received: from server.razorfever.net ([76.10.176.139]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id PVA03206; Fri, 09 May 2008 12:17:06 -0400 Received: from [192.168.0.10] (newskool.razorfever.net [192.168.0.10]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id m49GH5To069783; Fri, 9 May 2008 12:17:05 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <48247901.3000706@razorfever.net> Date: Fri, 09 May 2008 12:17:05 -0400 From: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> In-Reply-To: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: Dummynet, gif, and ipsec 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: Fri, 09 May 2008 16:17:07 -0000 Ermal Luçi wrote: > Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 > as you are running. It is another alternative to dummynet though it > have been tested with pf but should work with ipfw too since it knows > about ALTQ. > Hope it helps! > Hi Ermal, Thanks for the response! I'm looking to roll this out on 5-7 machines, so I'm really looking for a solution where we wouldn't have to make changes to the kernel code and would be supported by the base system moving forward. Are you planning to submit a PR with this patch? Also are the m_tag, or altq_tag the same tags created with the ipfw tag command? -- Derek From owner-freebsd-ipfw@FreeBSD.ORG Fri May 9 16:36:52 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDCAC1065673 for ; Fri, 9 May 2008 16:36:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id B10D98FC12 for ; Fri, 9 May 2008 16:36:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2169263rvf.43 for ; Fri, 09 May 2008 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=O2FZVl01MnieqbXpDbcj11E69G0cXc3MHJEY5DJG9DI=; b=W/jVpaJRBI1ZmexjKmkbzjKSv8vaxsiiOiF78/tXA51i7Cre4SiOHyC1jheSeGSy8t7/9ZICeYuucfxY6y72RrcphBVY6LfDssy2lpvXpeuiMvp1P/1bRTjHl3r/F4dzIZ3vLF6fLIlcD/mdWIc9Rh3v02nx/PcQyvGEuKBOt9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wTITpz8W70BbAvvy+0xSEs3WsrTiQSgPuWNWU2wTfBE5Cyurm/64l0jPwI9FfTLGW0+3WdXs8TLK9M6y0YwhetU6MM7h6O1/MJvH5B7i1EfLrhrcP8RxkfYoLmzqDyebDmJ/N6QmzKnjbMsA5GfoXGRTRHxERU+apuGvWmaJfgU= Received: by 10.141.76.21 with SMTP id d21mr2249445rvl.242.1210351012287; Fri, 09 May 2008 09:36:52 -0700 (PDT) Received: by 10.140.135.3 with HTTP; Fri, 9 May 2008 09:36:52 -0700 (PDT) Message-ID: <9a542da30805090936l222a58bcy5b926cba01d62ce6@mail.gmail.com> Date: Fri, 9 May 2008 18:36:52 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> In-Reply-To: <48247901.3000706@razorfever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> <48247901.3000706@razorfever.net> Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Dummynet, gif, and ipsec 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: Fri, 09 May 2008 16:36:53 -0000 On Fri, May 9, 2008 at 6:17 PM, Derek (freebsd-ipfw) <482254ac@razorfever.net> wrote: > Ermal Lu=E7i wrote: >> >> Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 >> as you are running. It is another alternative to dummynet though it >> have been tested with pf but should work with ipfw too since it knows >> about ALTQ. >> Hope it helps! >> > > Hi Ermal, > > Thanks for the response! > > I'm looking to roll this out on 5-7 machines, so I'm really looking for a > solution where we wouldn't have to make changes to the kernel code and wo= uld > be supported by the base system moving forward. > > Are you planning to submit a PR with this patch? > > Also are the m_tag, or altq_tag the same tags created with the ipfw tag > command? > As far as i am aware this should be transparent to ipfw. Meaning it should work since ipfw speaks ALTQ tags so no problems should arise. It is in use in production machines as a patch so you can be sure it works reliably. I can submit the PR but i think it is better if somebody with ipsec competence comments about its eligibility. I CC'd freebsd-net@ so somebody will speak for this more rather than place it on PR that nobody would look at. Ermal > -- Derek > From owner-freebsd-ipfw@FreeBSD.ORG Sat May 10 06:13:43 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB03106564A for ; Sat, 10 May 2008 06:13:43 +0000 (UTC) (envelope-from mpope@teksavvy.com) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4253D8FC1A for ; Sat, 10 May 2008 06:13:43 +0000 (UTC) (envelope-from mpope@teksavvy.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAMrZJEhFHOS9/2dsb2JhbACBU6lZ X-IronPort-AV: E=Sophos;i="4.27,464,1204520400"; d="scan'208";a="20214049" Received: from mail.pppoe.ca (HELO mail.teksavvy.com) ([65.39.192.132]) by ironport2-out.teksavvy.com with ESMTP; 10 May 2008 02:12:39 -0400 Received: from [192.168.111.174] ([69.28.228.189]) by mail.teksavvy.com (Internet Mail Server v1.0) with ASMTP id QLW04739 for ; Sat, 10 May 2008 02:12:39 -0400 Message-ID: <48253CDD.6090702@teksavvy.com> Date: Sat, 10 May 2008 02:12:45 -0400 From: Matthew User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Dummynet on Bridge on FreeBSD in VMware, its possible right? 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: Sat, 10 May 2008 06:13:43 -0000 Hello, I have been pointed in the right direction that I need to run dummynet in a bridge configuration rather than a router configuration. I have carefully followed the instructions for setting up a bridge in http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html and read numerous man pages, Usenet postings, internet postings, etc. Here's a crude schematic of my setup: (switch to fixed width font) [gateway(.1)]--ether--[le0 (.175) FreeBSD bridge le1]<-->VMNet2<-->[(.176)Ubuntu client] |---------------- H O S T Ubuntu P C at (.174)-------------------| The (left) outside end of the bridge (le0) has IP 192.168.111.175 gw 192.168.111.1, using a VMware Bridged Adapter. The inside end of the bridge (on right side) does not have an IP (le1) and is a VMNet2 adaptor. My (VMware) Ubuntu client connects to the inside end of the bridge via its own VMNet2 adapter at 192.168.111.176. The bridge is up with both interfaces promiscuous, and in discovery mode. Indeed I can: - ping OK from the FreeBSD-vm to the gateway(.1), to the Ubuntu client (.176), and to the host PC (.174) - ping OK from the Ubuntu client to the outside end of the bridge (.175), and no further - ping OK from the host PC (.174) to the bridge outside IP (.175) but not further to the client I tried an experiment of using VMNet1 host-only networking for the outside-end of the bridge, and adding 3 lines of undecipherable iptable commands that had the effect of making the host pc act as a gateway. It worked, but I got exactly the same results as above (except gateway was local PC (.174)), so I reverted to the more straightforward VMNet Bridged adapter architecture for the outside end of the bridge(.175). I am running 7.0-RELEASE #0, original kernel. /boot/loader.conf loads these modules only: if_bridge_load="YES" dummynet_load="YES" /etc/sysctl.conf: sysctl net.inet.ip.fw.enable=1 sysctl net.link.bridge.ipfw=1 sysctl net.inet.ip.fw.one_pass=1 /etc/rc.conf: (relevant parts) hostname="freebsdvm" defaultrouter="192.168.111.1" gateway_enable="NO" cloned_interfaces="bridge0" ifconfig_bridge0="addm le0 addm le1 up" ifconfig_le0="inet 192.168.111.175 netmask 255.255.255.0 up" ifconfig_le1="up" firewall_enable="YES" firewall_type="open" firewall_logging="YES" ifconfig output: le0: flags=8943 metric 0 mtu 1500 options=8 ether 00:50:56:84:52:ac inet 192.168.111.175 netmask 0xffffff00 broadcast 192.168.111.255 media: Ethernet autoselect status: active le1: flags=8943 metric 0 mtu 1500 options=8 ether 00:0c:29:5c:5e:7f media: Ethernet autoselect status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 7a:e4:f7:21:7a:14 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: le1 flags=143 netstat -rn (ipv4 part only): Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.111.1 UGS 0 52 le0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.111.0/24 link#1 UC 0 0 le0 192.168.111.1 00:0b:46:57:c7:bc UHLW 2 2 le0 1037 192.168.111.174 00:1d:60:b9:40:07 UHLW 1 98 le0 1199 192.168.111.175 00:50:56:84:52:ac UHLW 1 4 lo0 192.168.111.176 00:0c:29:96:6c:59 UHLW 1 7 le0 1064 The only thing that seems amiss to me is the above routes indicate the Ubuntu client (.176) was reached by the bridge via le0 (outside interface) rather than le1 (inside interface) to which the Ubuntu client is directly connected via a VMNet2 adapter. Since the Ubuntu client has only the single (VMnet2) interface, it seems impossible, or at least undesired, that the FreeBSD bridge host reached the Ubuntu client via the outside interface (le0) as indicated in the 'netstat -rn' output, but I'm not a networking specialist so its quite possible I'm missing something here. I've regressed from specifying dummynet pipes and queues to plain firewall rules (canned from the article quoted above) until I can solve this 'FreeBSD bridge on VMWare' networking working. rc.firewall: ipfw add 100 pass all from any to any via lo0 ipfw add 200 deny all from any to 127.0.0.0/8 ipfw add 300 deny ip from 127.0.0.0/8 to any # allow bridge machine to say anything it wants ipfw add pass tcp from 192.168.111.175 to any setup keep-state ipfw add pass ip from 192.168.111.175 to any # allow the inside hosts to say anything they want ipfw add pass tcp from any to any in via le1 setup keep-state ipfw add pass ip from any to any in via le1 # UDP section # allow DNS only toward the name server ipfw add pass udp from any to 69.39.192.130 53 in via le1 keep-state # ICMP section # pass ping ipfw add pass icmp from any to any icmptypes 8 keep-state # pass error messages generated by 'traceroute' ipfw add pass icmp from any to any icmptypes 3 ipfw add pass icmp from any to any icmptypes 11 ipfw add 65000 allow log all from any to any BTW, when I say some pings fail, I mean they return the message: 'Destination Host Unreachable' Thank you, Matthew (in Toronto) From owner-freebsd-ipfw@FreeBSD.ORG Sat May 10 14:11:56 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7320C1065677 for ; Sat, 10 May 2008 14:11:56 +0000 (UTC) (envelope-from mpope@teksavvy.com) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 27B7A8FC19 for ; Sat, 10 May 2008 14:11:55 +0000 (UTC) (envelope-from mpope@teksavvy.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAEtKJUhFHOS9/2dsb2JhbACBU6ki X-IronPort-AV: E=Sophos;i="4.27,464,1204520400"; d="scan'208";a="20219158" Received: from mail.pppoe.ca (HELO mail.teksavvy.com) ([65.39.192.132]) by ironport2-out.teksavvy.com with ESMTP; 10 May 2008 10:11:54 -0400 Received: from [192.168.111.174] ([69.28.228.189]) by mail.teksavvy.com (Internet Mail Server v1.0) with ASMTP id QTV17254 for ; Sat, 10 May 2008 10:11:54 -0400 Message-ID: <4825AD32.9040309@teksavvy.com> Date: Sat, 10 May 2008 10:12:02 -0400 From: Matthew User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <48253CDD.6090702@teksavvy.com> In-Reply-To: <48253CDD.6090702@teksavvy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Dummynet on Bridge on FreeBSD in VMware, its possible right? 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: Sat, 10 May 2008 14:11:56 -0000 I should add that the Ubuntu VMware client has its gateway set to 192.168.111.1 Also below I've added a line I missed when pasting in the ifconfig output. -Thx, Matthew > Hello, > I have been pointed in the right direction that I need to run dummynet > in a bridge configuration rather than a router configuration. I have > carefully followed the instructions for setting up a bridge in > http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html > and read numerous man pages, Usenet postings, internet postings, etc. > Here's a crude schematic of my setup: (switch to fixed width font) > > [gateway(.1)]--ether--[le0 (.175) FreeBSD bridge > le1]<-->VMNet2<-->[(.176)Ubuntu client] > |---------------- H O S T Ubuntu P C at > (.174)-------------------| > > The (left) outside end of the bridge (le0) has IP 192.168.111.175 gw > 192.168.111.1, using a VMware Bridged Adapter. The inside end of the > bridge (on right side) does not have an IP (le1) and is a VMNet2 > adaptor. My (VMware) Ubuntu client connects to the inside end of the > bridge via its own VMNet2 adapter at 192.168.111.176. > > The bridge is up with both interfaces promiscuous, and in discovery > mode. Indeed I can: > - ping OK from the FreeBSD-vm to the gateway(.1), to the Ubuntu client > (.176), and to the host PC (.174) > - ping OK from the Ubuntu client to the outside end of the bridge > (.175), and no further > - ping OK from the host PC (.174) to the bridge outside IP (.175) but > not further to the client > > I tried an experiment of using VMNet1 host-only networking for the > outside-end of the bridge, and adding 3 lines of undecipherable > iptable commands that had the effect of making the host pc act as a > gateway. It worked, but I got exactly the same results as above > (except gateway was local PC (.174)), so I reverted to the more > straightforward VMNet Bridged adapter architecture for the outside end > of the bridge(.175). > > I am running 7.0-RELEASE #0, original kernel. /boot/loader.conf loads > these modules only: > if_bridge_load="YES" > dummynet_load="YES" > > /etc/sysctl.conf: > sysctl net.inet.ip.fw.enable=1 > sysctl net.link.bridge.ipfw=1 > sysctl net.inet.ip.fw.one_pass=1 > > /etc/rc.conf: (relevant parts) > hostname="freebsdvm" > defaultrouter="192.168.111.1" > gateway_enable="NO" > cloned_interfaces="bridge0" > ifconfig_bridge0="addm le0 addm le1 up" > ifconfig_le0="inet 192.168.111.175 netmask 255.255.255.0 up" > ifconfig_le1="up" > firewall_enable="YES" > firewall_type="open" > firewall_logging="YES" > > ifconfig output: > le0: flags=8943 metric > 0 mtu 1500 > options=8 > ether 00:50:56:84:52:ac > inet 192.168.111.175 netmask 0xffffff00 broadcast 192.168.111.255 > media: Ethernet autoselect > status: active > le1: flags=8943 metric > 0 mtu 1500 > options=8 > ether 00:0c:29:5c:5e:7f > media: Ethernet autoselect > status: active > plip0: flags=108810 metric 0 > mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8843 metric 0 > mtu 1500 > ether 7a:e4:f7:21:7a:14 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: le1 flags=143 and member: le0 flags=143 > > > netstat -rn (ipv4 part only): > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.111.1 UGS 0 52 le0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 192.168.111.0/24 link#1 UC 0 0 le0 > 192.168.111.1 00:0b:46:57:c7:bc UHLW 2 2 le0 > 1037 > 192.168.111.174 00:1d:60:b9:40:07 UHLW 1 98 le0 > 1199 > 192.168.111.175 00:50:56:84:52:ac UHLW 1 4 lo0 > 192.168.111.176 00:0c:29:96:6c:59 UHLW 1 7 le0 > 1064 > > The only thing that seems amiss to me is the above routes indicate the > Ubuntu client (.176) was reached by the bridge via le0 (outside > interface) rather than le1 (inside interface) to which the Ubuntu > client is directly connected via a VMNet2 adapter. Since the Ubuntu > client has only the single (VMnet2) interface, it seems impossible, or > at least undesired, that the FreeBSD bridge host reached the Ubuntu > client via the outside interface (le0) as indicated in the 'netstat > -rn' output, but I'm not a networking specialist so its quite possible > I'm missing something here. > > I've regressed from specifying dummynet pipes and queues to plain > firewall rules (canned from the article quoted above) until I can > solve this 'FreeBSD bridge on VMWare' networking working. > > rc.firewall: > ipfw add 100 pass all from any to any via lo0 > ipfw add 200 deny all from any to 127.0.0.0/8 > ipfw add 300 deny ip from 127.0.0.0/8 to any > # allow bridge machine to say anything it wants > ipfw add pass tcp from 192.168.111.175 to any setup keep-state > ipfw add pass ip from 192.168.111.175 to any > > # allow the inside hosts to say anything they want > ipfw add pass tcp from any to any in via le1 setup keep-state > ipfw add pass ip from any to any in via le1 > > # UDP section > # allow DNS only toward the name server > ipfw add pass udp from any to 69.39.192.130 53 in via le1 keep-state > > # ICMP section > # pass ping > ipfw add pass icmp from any to any icmptypes 8 keep-state > # pass error messages generated by 'traceroute' > ipfw add pass icmp from any to any icmptypes 3 > ipfw add pass icmp from any to any icmptypes 11 > > ipfw add 65000 allow log all from any to any > > BTW, when I say some pings fail, I mean they return the message: > 'Destination Host Unreachable' > Thank you, > Matthew (in Toronto) > > > > > > > > > > > > _______________________________________________ > 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" >