On Fri, 30 May 2003, j knight wrote: >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 >> $ext_if.. > >Why can't you tag packets "in on gif0" into a queue that's been defined >on one of the internal interfaces?
because the queue that i'd be tagging for lives on the external interface, and not the internal ones. i'm trying to partition my external uplink in this case, not the downlink. i need to put ipv6 connections to servers in the same queue as the ipv4 connections. "pass in on gif0 ... queue (q_on_ext_if)" would not work, right? since the state it creates lives on gif0 and the queue lives on $ext_if, which is "upstream".. i haven't tried this though, i just thought it wouldn't work. > >> 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. exactly, and i don't want it to bite like that :( queueing on an upstream router (i'd have to build one though) would indeed work if i make it (rather than the first router) do the nat (since what i want to do is more complicated than just "give traffic that comes from port 80 priority"). but throwing extra hardware at a perfectly leet setup is ugly. i don't suppose something that'd make the extra router unnecessary is in the works? i don't think trans-interface queues are likely, but i do still have the old altq manpages around, what's this "conditioner" altq.conf(5) talks about? "a queueing discipline ... to meter ... incoming packets". devs? > >> 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 that won't work, because $ext_if is being nat'ed. i need to use seperate queues for some of the internal hosts (p2p host, server subnet, wireless clients), and since nat comes before filtering, i would have no way to distinguish between the hosts once the packets hit the filter. > >> 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 >> tagging.. > >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 > i thought you needed to keep state to do queueing? btw, "only if"? classifying by source ip or port is pretty much the only way altq is useful/sane if you have anything other than servers around.. ahh, the intricate delights of doing nat.. makes me want to migrate to ipv6-only. assuming i can get the tunnel queueing thing to work.. > > >.joel > anyway. thanks for your reply. b bee
