altq unfortunately queuing vlan traffic.

Thu Apr 12 17:01:31 UTC 2007

On Thursday 12 April 2007 18:06, Orum wrote:
> On 4/12/07, Max Laier <max at 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 = 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: 
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 at freebsd.org
> > \ /  Max Laier                          | ICQ #67774661
> > X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
> > / \  ASCII Ribbon Campaign              | Against HTML Mail and News
>
> Thanks,
> Ian
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"

-- 
/"\  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/4e02bcee/attachment.pgp