Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Jun 2007 20:02:37 +0200
From:      "Lubomir Georgiev" <0shady0recs0@gmail.com>
To:        freebsd-ipfw@freebsd.org
Subject:   ipfw, pipes, queues, weights and managing an Internet connection
Message-ID:  <937e203f0706161102m1ffa750ble3c900aade2e1c4f@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
I'm reposting my question - there might have been some problem the previous
time I sent it because I have not received ANY mail from the fbsd lists in
over 4 days now...




OK, so here's what I've ended up -> fxp0 is the external interface, the one
on which natd is bound to.


   00001: 440.000 Kbit/s    0 ms  500 B 1 queues (1 buckets) droptail
>         mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
>     BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
> Pkt/Byte Drp
>       0 tcp   85.187.141.213/24593      10.11.0.33/3132  16906 17390616
> 0    0 2394
>     *  I've limited the pipe to 440 Kbit/s for the testing purposes. There
> are no other pipes.
>
>     q00001: weight 99 pipe 1   50 sl. 1 queues (1 buckets) droptail
>         mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
>     BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
> Pkt/Byte Drp
>       0 tcp       10.11.0.33/3132   85.187.141.213/24593 374713 26638167
> 0    0   0
>     q00002: weight 75 pipe 1   50 sl. 1 queues (1 buckets) droptail
>         mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
>     BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
> Pkt/Byte Drp
>       0 tcp   66.160.135.130/80       192.168.1.90/1228  2025  1825680
> 0    0   0
>     q00003: weight 50 pipe 1   50 sl. 1 queues (1 buckets) droptail
>         mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
>     BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes
> Pkt/Byte Drp
>       0 tcp      64.12.90.22/80       192.168.1.90/1100  9081 10419914
> 0    0   0
>




And the ruleset -> I'll try to comment the lines the same way Mark did:



    01900 queue 1 ip from any to any out proto tcp tcpflags ack iplen 0-80
> xmit fxp0
>     01905 queue 1 ip from any to any in proto tcp tcpflags ack iplen 0-80
> recv fxp0
>     * Following Mark's example I let the ACK's in the first queue.
>     01910 queue 1 ip from any to any out proto udp xmit fxp0
>     01911 queue 1 ip from any to any in proto udp recv fxp0
>     * Again using Mark's example - this server for DNS requests
>     01915 queue 1 ip from any to any in proto icmp recv fxp0
>     01920 queue 1 ip from any to any out proto icmp xmit fxp0
>     * You guessed it - the dreaded ping...
>     01950 queue 2 ip from 192.168.1.90 to not me
>     01960 queue 2 ip from not me to 192.168.1.90
>     * 192.168.1.90 is a host which I want to have priority over everything
> else - except for the DNS, ACK and ping requests.
>     02000 queue 3 ip from any to any src-port 80 not layer2 via fxp0
>     02100 queue 3 ip from any to any dst-port 80 not layer2 via fxp0
>     *  Here I give priority to the 80 port so that browsing should not
> feel that something is being downloaded and is trying to eat up the pipe.
>     65500 allow ip from any to any
>     * And here falls everything else. The interesting part about this is
> that when I put that rule to fall in for ex. queue 4 /pipe 1, weight 1,
> least priority/ all the others seem to not work, judging by the ping times,
> so I just allowed it without setting a queue to it.
>



  I believe that the 65500 rule and the not working of others when assigned
a queue may be because I have no allow rule after the natd diver. The 1900
rule is the first one after the divert rule. I think that's the reason.

  Please people comment, share your thoughts and opinions - I feel that
there is some difference, but I do drastically feel when there is a torrent
in the background. Maybe I'm doing something wrong? If anyone has the time
and the desire to test this ruleset - IT WOULD BE INVALUABLE, cuz words can
only take you so far...

  To anyone who participates - a big thanks!



-- 
mEsS wItH tHe bEsT
dIE liKe tHe rESt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?937e203f0706161102m1ffa750ble3c900aade2e1c4f>