Date: Fri, 18 Mar 2005 00:58:18 -0800 From: ray@redshift.com To: "Constant, Benjamin" <bconstant@be.tiauto.com>, freebsd-pf@freebsd.org Subject: Re: Interrogation regarding pf + ALTQ Message-ID: <3.0.1.32.20050318005818.00a8e2a0@pop.redshift.com> In-Reply-To: <B6D948D84090A54ABCD88AA391DAAC8CD87DF2@tiasbel00ex00.be.eu .tiauto.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Benjamin, This might help in some areas. It's a diagram I drew for myself a few months back so I could make sure I fully understood the interplay between ipf and ipnat on a FreeBSD machine which I built for use as a router on my network. This diagram shows the packet going through the router and across the two interfaces. It provides a clear picture of the state of the packet at each junction. I don't know if it will relate 100% to your specific situation, but perhaps you will find it helpful. Here is the link: http://www.redshift.com/~ray/network/packet.gif If you find it helpful, you might want to save a copy, since that link may not always be static :-) Based on my testing, as far as I know this information is accurate as far as when/where the packet is re-written, etc. Ray At 11:03 AM 3/17/2005 +0100, Constant, Benjamin wrote: | | Hello list, | | I'm performing some tests with pf & ALTQ here but before going further | on, they are some obscure points I would like to clear up in my mind, | that's why I hope some gurus available on this list will give me some | more information. | | Here is how I understand the assignation to queues when the bsd_box is | acting as a gateway with two network interfaces: | | ..........int_if(in) ext_if(ou)------------ | [station_a] [bsd_box] [station_b] | ----------int_if(ou) ext_if(in)............ | | Dotted lines represent incoming traffic that can't be assigned to the | queues defined on the interface (you can't shape incoming traffic). | Dashed lines represent outgoing traffic that can be shaped trough the | queues defined on the interface (outgoing traffic). | | You are already welcome to correct me if I missed something on this point! | | Some more details: | | bsd_box is not acting as a firewall, it is only doing routing and | traffic shaping. | int_if is the internal interface connected to a 100Mbits switch with a | bandwidth of 100Mbits. | ext_if is the external interface connected to a 100Mbits switch with a | real bandwidth of 4Mbits (2Mbits up + 2Mbits down leased line) to the | outside world. | | Here is what I want to do: | | Shape the traffic according to the maximum bandwidth available for | both incoming and outgoing traffic on the leased line. | | What I understand: | | As I can't shape the traffic coming from station_b to station_a on the | ext_if, the only way for me to rate limit incoming traffic is to | define a queue with a maximum bandwidth of 2Mbits on the int_if but | what about the outgoing traffic on the external interface ? Is it | enough to define a queue with a maximum bandwidth of 2Mbits on the | ext_if ? | | Some other interrogation: | | When a packet is matching a state, is it still at least evaluated for | queueing ? | As the bsd_box is not acting as a firewall, shoud I use a state table | entry for each interface (set state-policy runtime option) ? Will it | speed up the lookups in the table ? Is there any risk to drop/discard | the packets even if the default behaviour is pass all and that the | rule is using the quick keyword ? | Are there documents that clearly describes the flow of packets | crossing a bsd box running pf + ALTQ ? | Are there other tools than pftop and pfctl to help in debugging pf and | traffic shaping ? | | You'll find below one my pf file for one of my router box. | | I hope I was clear enough with my explanation and I want to thank for | the time you may spend on my interrogation. | | Best Regards, | | Benjamin Constant | | PS: | | This message was also sent to pf@bendrezine.cx mailing list as I want | to gather as much as possible information. | | Here is a stripped sample of what I did (I know they are difference | compared to my previous explanation), feel free to comment it if you | see strange things in it: | | # See pf.conf(5) and /usr/share/examples/pf for syntax and examples. | # Required order: options, normalization, queueing, translation, filtering. | # Macros and tables may be defined and used anywhere. | # Note that translation rules are first match while filter rules are last | match. | | # Macros: define common values, so they can be referenced and changed | easily. | | # Interfaces ###### | # | # We have two interface, int_if is connected to the local lan and also to | the | # firewall which is located on the local lan. | # Interface ext_if is used for vpn traffic and is connected to vpn boxes on | a | # different logical network. | # | ################### | | int_if="em0" | ext_if="em1" | | # Servers | proxy="ip" | support="ip" | sla="{ ips }" | | # Site bandwidth available | # | # | ################### | bwdth="2048Kb" | | # Tables: similar to macros, but more flexible for many addresses. | table <tiiprange> persist file "/etc/pf.iprange.tiauto" | table <trendiprange> persist | | # Options: tune the behavior of pf, default values are given. | | # Normalization: reassemble fragments and resolve or reduce traffic | ambiguities. | #scrub log-all on $int_if all | #scrub log-all on $int_if all reassemble tcp | #scrub log-all on $ext_if all | #scrub log-all on $ext_if all reassemble tcp | | # Queueing: rule-based bandwidth control. | | altq on $ext_if cbq bandwidth $bwdth queue { internet, vpn, sla, dbg } | | # Main children queues | # | # We have decided to split the traffic into 3 main queues as follow: | # - Internet queue is dedicated to internet traffic | # - Vpn queue is used for traffic between sites (trough vpn). | # - Sla queue is used as a quality of service queue for specific hosts | or services. | # | ################### | | # Internet queue | queue internet bandwidth 512Kb priority 1 cbq { i_default, i_high } | queue i_default priority 5 cbq(borrow) | queue i_high priority 6 cbq(borrow) | | # Default and vpn queue | queue vpn bandwidth 1Mb priority 2 cbq(default, borrow) { v_low, | v_mon, v_normal, v_high, v_critical, v_default } | queue v_low priority 4 cbq(borrow) | queue v_mon bandwidth 128Kb priority 4 cbq(ecn) | queue v_normal priority 5 cbq(borrow) | queue v_high priority 6 cbq(borrow) | queue v_critical priority 7 cbq(borrow) | queue v_default priority 5 cbq(borrow) | | # Sla queue | queue sla bandwidth 512Kb priority 2 cbq(borrow) | | # Debugging queue | queue dbg priority 2 { d_in, d_out } | queue d_in priority 5 cbq(borrow) | queue d_out priority 5 cbq(borrow) | | # Queue assignation | # | # - 'remote' means ip range <> lan | # - 'local' means lan ip range | # | ################### | | # drop broadcast packets | block drop in quick on $int_if from any to $int_if:broadcast | block drop in quick on $ext_if from any to $ext_if:broadcast | | # traffic FROM remote TO local proxy (replies to local will not cross | this server, this is not transparent proxy) | pass in quick on $ext_if proto tcp from <tiiprange> to $proxy port | 8080 flags S/SA keep state queue i_default | pass out quick on $ext_if proto tcp from $proxy port 8080 to | <tiiprange> keep state queue i_default | | # traffic FROM remote TO local $sla server pool | pass in quick on $ext_if proto tcp from <tiiprange> to $sla flags S/SA | keep state queue sla | pass out quick on $ext_if proto tcp from $sla to <tiiprange> keep | state queue sla | | # traffic FROM remote TO remote $support | pass in quick on $ext_if proto tcp from <tiiprange> to $support port | 80 flags S/SA keep state queue sla | pass out quick on $ext_if proto tcp from $support port 80 to | <tiiprange> keep state queue sla | # traffic FROM local TO remote $support | pass in quick on $int_if proto tcp from <tiiprange> to $support port | 80 flags S/SA keep state queue sla | | # traffic FROM remote TO remote OR local http servers | pass in quick on $ext_if proto tcp from <tiiprange> to <tiiprange> | port { 80, 443 } flags S/SA keep state queue v_high | pass out quick on $ext_if proto tcp from <tiiprange> port { 80, 443 } | to <tiiprange> keep state queue v_high | # traffic FROM local TO remote http servers | pass in quick on $int_if proto tcp from <tiiprange> to <tiiprange> | port { 80, 443 } flags S/SA keep state queue v_high | | # traffic FROM remote TO remote OR local FOR mail exchange | pass in quick on $ext_if proto tcp from <tiiprange> to <tiiprange> | port { 25, 102 } flags S/SA keep state queue v_normal | pass out quick on $ext_if proto tcp from <tiiprange> port { 25, 102 } | to <tiiprange> keep state queue v_normal | # traffic FROM local TO remote FOR mail exchange | pass in quick on $int_if proto tcp from <tiiprange> to <tiiprange> | port { 25, 102 } flags S/SA keep state queue v_normal | | # traffic FROM remote TO remote FOR unmatched traffic | pass in quick on $ext_if from <tiiprange> to <tiiprange> flags S/SA | keep state queue v_default | pass out quick on $ext_if from <tiiprange> to <tiiprange> keep state | queue v_default | | # traffic FROM remote TO everywhere FOR unmatched traffic (Internet is | everywhere) | pass in quick on $ext_if from <tiiprange> to any flags S/SA keep state | queue i_default | pass out quick on $ext_if from any to <tiiprange> keep state queue i_default | | # default policies | pass in on $int_if from <tiiprange> to any | pass out on $int_if from any to <tiiprange> | pass on lo0 all | | Benjamin Constant | TI Automotive | | The information contained in this transmission may contain privileged and | confidential information. It is intended only for the use of the | person(s) named above. If you are not the intended recipient, you are | hereby notified that any review, dissemination, distribution or | duplication of this communication is strictly prohibited. If you are not | the intended recipient, please contact the sender by reply email and | destroy all copies of the original message. This communication is from TI | Automotive. | _______________________________________________ | 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" | |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.20050318005818.00a8e2a0>