[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: altq-(ipv6 tunnel|multiple ifs) questions

b bee wrote:

the router talks ipv6 to boxen behind three of the interfaces (not
$ext_if). my external ipv6 connectivity is via a tunnel over v4 (via
$ext_if, obviously). it is fairly simple to classify the traffic of
outgoing ipv6 connections (i just make a "pass out on gif0 ... queue
(q_on_ext_if)" rule, and it gets put in the right queue as it goes out on
$ext_if), but can't think of a way to do this for incoming v6 connections
(other than sticking the whole tunnel in the same queue, which would lump
all the v6 traffic together and that is not what i want). any hints?
i don't suppose pf can look "inside" the tunnel as the packets pass in on

Why can't you tag packets "in on gif0" into a queue that's been defined on one of the internal interfaces?

another altq question. i want to take this setup to the next level and make
altq partition my downlink as well. is this possible when there is more
than one "internal" interface? i need to make a queue that transcends the
interfaces, i.e. to cap bandwidth for a group of connections regardless of
what interface they live on.

If I understand correctly, you want to classify say all HTTP traffic regardless of which internal network the traffic is destined for, right? You could: decide how much aggregate bandwidth HTTP is to have and then create a queue on each internal interface giving each one third of that bandwidth. This bites though because one queue cannot borrow from another queue on a different interface; each internal network would be limited to 1/3 the aggregate HTTP bandwidth. The only way I can see is to queue on the upstream router.

even if this is possible, how will i classify this traffic? some of the
rules that create the relevant states already have queue keywords for the
altq on $ext_if...

You mean you're doing this?

	pass in on $int_if .... queue q_on_ext_if keep state
	pass out on $ext_if keep state

Do something like this instead:

	# takes care of return traffic from outside
	pass in on $int_if .... queue q_on_int_if keep state
	# takes care of traffic going towards outside
	pass out on $ext_if .... queue q_on_ext_if keep state

hmm, wouldn't this also be a problem in the case that there is only one
internal interface? unless you only classify traffic with rules that match
on the same if that the queue is attached to, which would severely limit
the usefulness of altq (atleast if you need to do nat, too)..
now that i think about it, packet tagging might solve that last problem.
i'll have to unfubar my tree and bump it to -current so i can play with

Yeah, that can be a problem when doing NAT but only if you're classifying traffic based on the source IP address or port. I suppose the alternative is not to keep state on $int_if?

	pass in on $int_if ... queue q_on_ext_if
	pass out on $int_if ... queue q_on_int_if