Re: altq unfortunately queuing vlan traffic.
- From: Orum <yoitsmeremember@xxxxxxxxx>
- Date: Thu, 12 Apr 2007 11:06:51 -0500
On 4/12/07, Peter Jeremy <peterjeremy@xxxxxxxxxxxxxxxx> wrote:
On 2007-Apr-12 11:20:29 +0100, "Bruce M. Simpson" <bms@xxxxxxxxxxx> wrote:
>I can't speak for ALTQ at the moment however I believe dummynet may work
>on vlan devices.
dummynet definitely does work on vlan devices. I use it extensively at work.
--
Peter Jeremy
Dummynet is unfortunately not an option as I will need to be able to
run redundant stateful firewalls, unless there is something that
allows you to do this with ipfw (I'm embarrased to say I don't know it
that well).
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?
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"
- Follow-Ups:
- Re: altq unfortunately queuing vlan traffic.
- From: Max Laier
- Re: altq unfortunately queuing vlan traffic.
- References:
- altq unfortunately queuing vlan traffic.
- From: Orum
- Re: altq unfortunately queuing vlan traffic.
- From: Max Laier
- altq unfortunately queuing vlan traffic.
- Prev by Date: Re: altq unfortunately queuing vlan traffic.
- Next by Date: Re: altq unfortunately queuing vlan traffic.
- Previous by thread: Re: altq unfortunately queuing vlan traffic.
- Next by thread: Re: altq unfortunately queuing vlan traffic.
- Index(es):
Relevant Pages
|
