Hi Bill, I still for problem for a few items as the behaviour of the traffic shaper does not support my understanding:
For Item 5: Suppose that the WAN->LAN rule is setup to shape the returned traffic, why would the destination port the same as its respective LAN->WAN rule? For example, if I wish to put the HTTP traffic on a specific Queue, it is logical to define a LAN-WAN rule that catch the traffic with Destination Port 80. However, the destination port of the replied packets will not be Port 80. How then could its respective WAN->LAN rule catch the returned packets? It seems to me that the LAN->WAN rule is to shape the traffic if a user is accessing to a Web Server from the LAN interface; whereas the WAN->LAN rule is to shape the traffic if a user is accessing to a Virtual Server in the LAN from the Internet. Is this correct? Suppose that the LAN->WAN rule is to shape the WAN interface for traffic coming from the LAN interface, does the "target" outbound and inbound queues refers to only the queue associated with the WAN interface? May be the attachment can explain my question. Regards, Kelvin -----Original Message----- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 2:02 AM To: support@pfsense.com Subject: Re: [pfSense Support] Traffic Shaper On 3/13/07, Kelvin Chiang <[EMAIL PROTECTED]> wrote: > > > Hi, is there a document somewhere that I can read and understand about > the mechanism for Traffic Shaper? Or if someone can verify whether my > concept is > right: > > 1. Before anything can be defined, we must first define a pair of > Parent Queues, one for download speed and one for upload speed. > Multiple Parent Queues can be defined on the system as well. > > 2. The we should define multiple traffic queues that belongs to a > Parent Queue. It only make sense to always create a pair of queues > instead of one. Correct? > > 3. Then, allocate bandwidth to the "Daughter" queues, either by > percentage of the Parent Queue's bandwidth, or an absolute figure (in > Kbps, Mbps & etc). If the absolute bandwidth is higher than the > Parent's bandwidth, the "Daughter" queue's will override the Parent > Queue's. Correct? Child queues inherit from the parent. The sum of all child queues cannot exceed that allocated to the parent. > 4. When defining the traffic queues, there is an option to check the > box "Default queue". If this box is checked, all unclassified traffic > by the rules will be put on this queue. Correct? Yes > 5. If I use the Wizard to create a set of rules and queues, I realized > that there was always a pair of rules defined for the same protocol, > LAN->WAN and > WAN->LAN. I also realized that in each rule definition, there is an > WAN->option > to specify the "Direction", "any", "in" and "out". Isn't that > Direction = "any" already take care of LAN->WAN and WAN->LAN, why is > there a need to create a pair of rules? The LAN-WAN rules apply to the WAN interface, the WAN-LAN apply on the LAN interface. We setup rules such that the WAN-LAN queue is applied to the state on the LAN interface so the return traffic gets shaped. > 6. In a rule definition, suppose that the "In Interface" is LAN and > "Out Interface" is WAN, the Inbound Queue in "Target" holds the > inbound traffic to the LAN interface whereas the Outbound Queue holds > the outbound traffic from the WAN interface, provided that the rule is > matched. Correct? How does the "Direction" field affects of which > queue the traffic will be queued then? It doesn't, that should have been pulled. That field does nothing. > 7. While the Traffic Queues defined in "Queues" section (qlandef, > qwandef & > etc) are logical queues that control the speed and priority, the > "Outbound Queue" and "Inbound Queue" in traffic shaper rule definition > refers to the physical "memory buffer" queue, correct? If I understand you correctly, yes. > 8. For any pair of rule (LAN->WAN and WAN->LAN), if I change the "LAN" > to "PPTP" and leave everythings else as it is, I always receive > errors. Is there a reason why? PPTP (tun) interfaces probably don't allow for ALTQ. --Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<attachment: ts.jpg>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
