Date: Thu, 12 Apr 2007 19:00:35 +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: <200704121901.26252.max@love2party.net> In-Reply-To: <f3ac6ca80704120906x4ed6efe3t7c20499ac5218f3a@mail.gmail.com> References: <f3ac6ca80704112010m4f440222lc9a47c490db92060@mail.gmail.com> <200704121658.00621.max@love2party.net> <f3ac6ca80704120906x4ed6efe3t7c20499ac5218f3a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <max@love2party.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704121901.26252.max>