Re: altq unfortunately queuing vlan traffic.

On Thursday 12 April 2007 18:06, Orum wrote:
On 4/12/07, Max Laier <max@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Thanks,
Ian
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgpMyJSUwjLUX.pgp
Description: PGP signature

Relevant Pages

  • Re: altq unfortunately queuing vlan traffic.
    ... dummynet definitely does work on vlan devices. ... > I just recently configured altq to run on my vge0 interface. ... > on that interface. ... > in vge0's queue because it is the parent interface. ...
    (freebsd-net)
  • Re: altq for vlans?
    ... >> gather that since tun works, so should vlan. ... Max> interface does not support ALTQ it must be patched. ... you seem to be saying that if the queue is attached to (in this ...
    (freebsd-net)
  • altq and IPsec - queue on incoming interface
    ... Sometimes there is really need for ALTQ on incoming traffic: ... There is problem on queue on $ext_if. ... Use route-to loopback interface ... Then apply queue on outgoing traffic from lo0. ...
    (comp.unix.bsd.openbsd.misc)
  • Re: altq unfortunately queuing vlan traffic.
    ... I'm using pf for nat on vge0, and would like to also like to use altq ... on that interface. ... that the problem is that altq is queuing packets destined for the vlan ... in vge0's queue because it is the parent interface. ...
    (freebsd-net)
  • altq unfortunately queuing vlan traffic.
    ... I just recently configured altq to run on my vge0 interface. ... I also can't put the internet connection on a vlan for two ... Or something to do with the driver itself ...
    (freebsd-net)