From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 14:58:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C32016A406 for ; Thu, 12 Apr 2007 14:58:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id DF43013C4D1 for ; Thu, 12 Apr 2007 14:58:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.68] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Hc0kM39Wy-00048A; Thu, 12 Apr 2007 16:58:05 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org, yoitsmeremember@evil-geni.us Date: Thu, 12 Apr 2007 16:57:50 +0200 User-Agent: KMail/1.9.5 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4218025.m8SSxj5Hkn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704121658.00621.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+cpkJAMnKs2cct6ZRf4PVAzU3UN3j9HkGbrhm 3w5ccHrbShKvXqCMQfEOqBIyVd5rntR9WBCGMCNL8RFU9Unr+I O8Kks/n2qzCxAnEAIhoKQ== Cc: Subject: Re: altq unfortunately queuing vlan traffic. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 14:58:07 -0000 --nextPart4218025.m8SSxj5Hkn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 April 2007 05:10, Orum wrote: > I just recently configured altq to run on my vge0 interface. The > machine is running FreeBSD 6-STABLE (6.2-RELEASE doesn't have altq > support in the vge driver). Before I go any further, let me show you a > tiny diagram of my network: > > Private LAN ]----[vlan2, parent if =3D vge0] FreeBSD router [vge0 (doing > nat via pf)]----[ Internet > > I'm using pf for nat on vge0, and would like to also like to use altq > on that interface (no queuing is needed on the vlan2 interface). But, > shortly after enabling it I noticed that my SSH session to that machine > started to lag greatly. After going through and making a few sanity > checks (cpu usage, disabling altq, etc.), I'm pretty sure I discovered > that the problem is that altq is queuing packets destined for the vlan > in vge0's queue because it is the parent interface. > > Ideally I would just add another interface, but unfortunately that's > not possible. I also can't put the internet connection on a vlan for > two reasons; 1) altq is not supported on vlan devices (I think I know > why now too!), and 2) pf's nat does not work on vlan devices (probably > for the same reason altq doesn't work on them). While queueing on vlan interfaces is not supported (as it doesn't make=20 sense in the ALTQ way of queueing) you can very well *classify* on vlan=20 interfaces and queue on the physical interface. The second point about=20 pf's NAT not working on vlan interfaces doesn't hold in my tests - can=20 you provide more details? What you'd do for your setup is the following: Define two (or more) queues on vge0 say q_lan and q_inet, then classify to= =20 direct the traffic to the queue it belongs to. Your setup is broken=20 without this anyway, as traffic in the vlan can suppress internet traffic=20 and vice versa. If you really have only one physical interface you have=20 to do queueing in any case. The setup in a nutshell looks like: altq on vge0 cbq bandwidth XXXMb queue { q_lan, q_wan } queue q_lan bandwidth YYYMb queue q_wan bandwidth ZZZMb cbq(default) pass on vlan0 .... keep state queue (q_lan) pass on vge0 ... to $next_hop keep state queue (q_wan) Of course you'd need to add child queues to the wan queue in order to=20 build you policy. Note that the classification ("queue (q_lan)") is done on the vlan=20 interface. The queueing happens later as the packet with the=20 classification tag hits the physical interface that defines the queue. > I guess this leaves me with two options. I can either make it so that > altq will not queue packets on an interface for packets destined for a > vlan that has that interface as a parent, or I can try and make altq > work on the vlan interface, and modify pf's nat to work on vlan > interfaces as well, thus eliminating the need to differentiate between > those packets destined for a vlan and those for the untagged physical > interface. The former seems like it would be the easier of the two, > though neither option seems easy to me. > > Where would I go about making these modifications? In altq? Or does > this have to do with the TCP/IP stack? Or something to do with the > driver itself (to make matters more complicated, it uses > VLAN_HWTAGGING)? I really have no idea where to begin. Or, if you can > think of another easier solution to this problem, let me know! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4218025.m8SSxj5Hkn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGHkj4XyyEoT62BG0RAj7wAJ0TxFXdZEYP/Lv+3TS4EQugWs2nhQCdHWxq NBglOFvsT5H3Nhhh80Jt2oc= =o3Y1 -----END PGP SIGNATURE----- --nextPart4218025.m8SSxj5Hkn--