Date: Tue, 25 Oct 2005 11:24:32 +1000 From: "Josh Finlay" <montarotech@optusnet.com.au> To: "Bruno Afonso" <brunomiguel@dequim.ist.utl.pt> Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD + MPD + PF + ALTQ Message-ID: <001301c5d902$db39d6d0$0132a8c0@delta> References: <000b01c5d644$54527f20$0132a8c0@delta><4359ED5B.7010303@dequim.ist.utl.pt><55e8a96c0510220651t47fa063ayefd1dcffd63950a6@mail.gmail.com><435A6025.5060602@dequim.ist.utl.pt><55e8a96c0510221659g7ac457b1gc696f392a249fee3@mail.gmail.com> <010001c5d7e0$8669bd50$6200a8c0@delta> <008f01c5d8e3$308c15f0$0132a8c0@delta> <435D85A6.7020106@dequim.ist.utl.pt>
next in thread | previous in thread | raw e-mail | index | archive | help
Looking forward to 6.0 :)
Any idea on a release date?
It will certainly make my life so much easier.
----- Original Message -----
From: "Bruno Afonso" <brunomiguel@dequim.ist.utl.pt>
To: "Josh Finlay" <montarotech@optusnet.com.au>
Cc: <freebsd-pf@freebsd.org>
Sent: Tuesday, October 25, 2005 11:08 AM
Subject: Re: FreeBSD + MPD + PF + ALTQ
> Josh Finlay wrote:
>> Just giving this message a bit of a bump.
>>
>> I've looked into:
>>
>> route add -net 192.168.0.0/24 192.168.1.1
>> in an attempt to route between the two interfaces
>> but i just get "file exists" errors, even if i "route flush" before hand.
>>
>> like I said earlier, routing is -not- my forte.
>
> Do yourself a favour, use current or wait for 6.0 to come out or ask for
> patches :-)
>
> BA
>
>>
>> ----- Original Message ----- From: "Josh Finlay"
>> <montarotech@optusnet.com.au>
>> To: "Bill Marquette" <bill.marquette@gmail.com>
>> Cc: <freebsd-pf@freebsd.org>
>> Sent: Monday, October 24, 2005 12:46 AM
>> Subject: Re: FreeBSD + MPD + PF + ALTQ
>>
>>
>>> Ok I've tried to study the PF FAQ on OpenBSD.org and learn a few things
>>> from some of the rules you've given.
>>>
>>> Here is my current pf.conf to date:
>>> (note: de0 goes to my lan, vr0 goes to my modem, mpd still uses ng0 but
>>> the traffic is still essentially coming in/out on vr0 right?)
>>>
>>> ExtIF="vr0"
>>> IntIF="de0"
>>>
>>> set loginterface $ExtIF
>>> scrub in all
>>> scrub out all random-id max-mss 1440
>>>
>>> altq on $ExtIF priq bandwidth 128Kb queue { std_out, ssh_im_out,
>>> dns_out, tcp_ack_out }
>>> queue std_out priq(default)
>>> queue ssh_im_out priority 4 priq(red)
>>> queue dns_out priority 5
>>> queue tcp_ack_out priority 6
>>>
>>> altq on $IntIF cbq bandwidth 512Kb queue { std_in, ssh_im_in, dns_in }
>>> queue std_in bandwidth 384Kb cbq(default)
>>> queue ssh_im_in bandwidth 64Kb priority 4
>>> queue dns_in bandwidth 64Kb priority 5
>>>
>>> local_net = "192.168.0.0/24"
>>> ssh_ports = "{ 22 }"
>>> im_ports = "{ 1863 5190 5222 }"
>>>
>>> nat on $IntIF from $local_net to any -> ($ExtIF)
>>> pass in quick on lo0 all
>>> pass out quick on lo0 all
>>>
>>> pass out on $ExtIF inet proto tcp from ($ExtIF) to any flags S/SA \
>>> keep state queue(std_out, tcp_ack_out)
>>> pass out on $ExtIF inet proto { udp icmp } from ($ExtIF) to any keep
>>> state
>>> pass out on $ExtIF inet proto { tcp udp } from ($ExtIF) to any port
>>> domain \
>>> keep state queue dns_out
>>> pass out on $ExtIF inet proto tcp from ($ExtIF) to any port $ssh_ports
>>> \
>>> flags S/SA keep state queue(std_out, ssh_im_out)
>>> pass out on $ExtIF inet proto tcp from ($ExtIF) to any port $im_ports \
>>> flags S/SA keep state queue(ssh_im_out, tcp_ack_out)
>>>
>>> pass in on $IntIF from $local_net
>>> pass out on $IntIF proto { tcp udp } from any port domain to $local_net
>>> \
>>> queue dns_in
>>> pass out on $IntIF proto tcp from any port $ssh_ports to $local_net \
>>> queue(std_in, ssh_im_in)
>>> pass out on $IntIF proto tcp from any port $im_ports to $local_net \
>>> queue ssh_im_in
>>>
>>> --end
>>>
>>> I have also only just installed the second nic in the machine
>>> before that, de0 was doing all the work.
>>> i am stuck with a small problem, which ive had no experience with, once
>>> i tell mpd to connect via vr0, i get connectivity on the router but not
>>> on any other machines on the network.
>>> they are still using de0's ip (192.168.0.101) as their gateway, but its
>>> not able to do any internet traffic.
>>> this is the same if i bind a ping to 192.168.0.101 (ie. ping -S
>>> 192.168.0.101 host.name) i get no response while mpd is using vr0, but
>>> if its using de0 like before it works fine.
>>>
>>> is this something in pf i need to fix? or do I need to somehow route
>>> traffic from de0 to vr0, im in the dark about this, like I said ive had
>>> no experience with a second nic.
>>>
>>> this rules apply fine. but with the above problem on hand, i havent been
>>> able to see if they actually work yet. let me know if I messed it all up
>>> or not ;)
>>>
>>> ----- Original Message ----- From: "Bill Marquette"
>>> <bill.marquette@gmail.com>
>>> To: "Bruno Afonso" <brunomiguel@dequim.ist.utl.pt>
>>> Cc: <freebsd-pf@freebsd.org>
>>> Sent: Sunday, October 23, 2005 9:59 AM
>>> Subject: Re: FreeBSD + MPD + PF + ALTQ
>>>
>>>
>>>> On 10/22/05, Bruno Afonso <brunomiguel@dequim.ist.utl.pt> wrote:
>>>>> Bill Marquette wrote:
>>>>> > On 10/22/05, Bruno Afonso <brunomiguel@dequim.ist.utl.pt> wrote:
>>>>> >> The download part is the problematic one IF they're not all
>>>>> connected >> to
>>>>> >> the same network interface. Why ? Because altq only works PER >>
>>>>> interface
>>>>> >> and tun0, tun1, tun2, etc are each and single one, one interface
>>>>> on >> its own.
>>>>> >>
>>>>> >> You basically have to
>>>>> >>
>>>>> >> altq on tun0
>>>>> >>
>>>>> >> altq on tun1, etc..
>>>>> >>
>>>>> >> What we would need in this case would be a meta-interface that altq
>>>>> >> would work on, but that is not available. Bottom line: you can't
>>>>> >> control
>>>>> >> with PF global bw over an interface-span. This is probably
>>>>> necessary >> for
>>>>> >> a full commercial deployment. Don't know of any plans to
>>>>> implement >> this...
>>>>> >>
>>>>> >> meta_if <meta_1> {tun0, tun1}
>>>>> >>
>>>>> >> altq on meta_1 ...
>>>>> >>
>>>>> >> would be nice. :-)
>>>>> >
>>>>> > You mean something like:
>>>>> > altq on { fxp0 fxp1 } bandwidth 100Mb hfsc queue { a b }
>>>>> > queue a bandwidth 50Mb hfsc(default)
>>>>> > queue b bandwidth 50Mb hfsc
>>>>> > This works today :)
>>>>>
>>>>> Yes, I have now tried and verified that it works, but not as we would
>>>>> like to in the sense of a meta interface, eg:
>>>>>
>>>>> altq on { tun0 tun1 tun2 } cbq bandwidth 1Mb queue { a b }
>>>>> queue a bandwidth 700Kb cbq(default)
>>>>> queue b bandwidth 300Kb
>>>>>
>>>>>
>>>>> which turns itself into... (from pfctl -sq)
>>>>>
>>>>>
>>>>> queue root_tun0 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b}
>>>>> queue a bandwidth 700Kb cbq( default )
>>>>> queue b bandwidth 300Kb
>>>>> queue root_tun1 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b}
>>>>> queue a bandwidth 700Kb cbq( default )
>>>>> queue b bandwidth 300Kb
>>>>> queue root_tun2 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b}
>>>>> queue a bandwidth 700Kb cbq( default )
>>>>> queue b bandwidth 300Kb
>>>>>
>>>>>
>>>>> What would I want with this? To create a queue that is shared by every
>>>>> interface, so limiting globally every interface to a maximum of 1Mb
>>>>> each
>>>>> and all of them to 1Mb each too, in a cqb borrowing shared way. For
>>>>> examply, I'd like a to never exceed 700Kb taking into account every
>>>>> interface. This makes perfect sense if I have a limited ammount of bw
>>>>> to
>>>>> share among each client, which, in a real world, happens 99,9% of the
>>>>> time because resources are limited.
>>>>>
>>>>> So, the syntax works, but it does achieve what I mentioned before, the
>>>>> meta interface concept. The example you give is only useful for
>>>>> simplifying rulesets, although it's more difficult for humans to
>>>>> understand.
>>>>
>>>>
>>>>> From what I understand, that binds queue 'a' to every interface. The
>>>> queue definition still limits the queue itself to 700Kb, but allows
>>>> you to assign traffic to that queue on each interface that queue is
>>>> bound to. I can't find the email that I read that suggests it now
>>>> (machine having recently been wiped and google not being terribly
>>>> forthcoming with the answer).
>>>>
>>>> Have you verified this not working with real traffic, or just the
>>>> pfctl -sq output? At this time I don't have a multi-interface box at
>>>> my disposal, so I can't easily test this.
>>>>
>>>> --Bill
>>>> _______________________________________________
>>>> freebsd-pf@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
>>>>
>>>
>>> _______________________________________________
>>> freebsd-pf@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
>>
>> _______________________________________________
>> freebsd-pf@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
>
> --
> Bruno Afonso, Biological Engineer
> Dana-Farber Cancer Institute
> 1 Jimmy Fund Way
> Smith Building
> Boston, MA 02115
> phone: (617)-632-5105
> GABBA Graduate Student (http://gabba.up.pt)
> Homepage @ http://brunoafonso.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001301c5d902$db39d6d0$0132a8c0>