altq unfortunately queuing vlan traffic.

[Max Laier]

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 = 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?

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.

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 at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070412/b9dd6a89/attachment.pgp