From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 17:01:31 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 84D6C16A407 for ; Thu, 12 Apr 2007 17:01:31 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1289613C45B for ; Thu, 12 Apr 2007 17:01:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.187.68] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1Hc2fn3RYc-000668; Thu, 12 Apr 2007 19:01:28 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org, yoitsmeremember@evil-geni.us Date: Thu, 12 Apr 2007 19:00:35 +0200 User-Agent: KMail/1.9.5 References: <200704121658.00621.max@love2party.net> 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="nextPart7792284.xIPRrjuzv8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704121901.26252.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18GIZtiTurPWKgNTSeD/TPvMZnPJHbfxg0NYjC H84xR2SGjDV8HAy/Szqrz7CIPayOioQj2HAqz+Hq8okvxy3SkZ emNl9S3E2ZAJQ5nHXG4Og== 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 17:01:31 -0000 --nextPart7792284.xIPRrjuzv8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 April 2007 18:06, Orum wrote: > On 4/12/07, Max Laier wrote: > > 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 sense in the ALTQ way of queueing) you can very well *classify* > > on vlan interfaces and queue on the physical interface. The second > > point about pf's NAT not working on vlan interfaces doesn't hold in > > my tests - can you provide more details? > > I'll double check it, but when I tried it with 6.2-RELEASE the packets > would leave the interface with the source address unchanged from the > private network. > > > 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 direct the traffic to the queue it belongs to. Your > > setup is broken without this anyway, as traffic in the vlan can > > suppress internet traffic and vice versa. If you really have only > > one physical interface you have 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 > > build you policy. > > Sounds like a good idea, but in my case I'm using priority queuing and > not class based queuing. I'm not sure how I would set the bandwidth > on the priority queue, since it only has one bandwidth option, and it > seems to be pretty critical to get it right when you're using altq to > prioritize empty TCP ACKs. How would I do this with a priq? You can combine cbq and priority scheduleing. Just look at the examples:=20 http://www.openbsd.org/faq/pf/queueing.html > > Note that the classification ("queue (q_lan)") is done on the vlan > > interface. The queueing happens later as the packet with the > > 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! > > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > Thanks, > Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =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 --nextPart7792284.xIPRrjuzv8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGHmXmXyyEoT62BG0RAnPiAJ0XiW+z/2IOL5oGANC5W0+JKFBPLACeKNaf ZaLW51LN5AnHKaf+UtV/iQs= =EEJF -----END PGP SIGNATURE----- --nextPart7792284.xIPRrjuzv8--