Date: Thu, 12 Apr 2007 16:57:50 +0200 From: Max Laier <max@love2party.net> To: freebsd-net@freebsd.org, yoitsmeremember@evil-geni.us Subject: Re: altq unfortunately queuing vlan traffic. Message-ID: <200704121658.00621.max@love2party.net> In-Reply-To: <f3ac6ca80704112010m4f440222lc9a47c490db92060@mail.gmail.com> References: <f3ac6ca80704112010m4f440222lc9a47c490db92060@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704121658.00621.max>