pfSense

Partly the wizard and partly duplication to #749, but primarily a big whinge that the broader shaping implementation of pfSense 2.0 has a rather silly design fault in that it shapes all traffic on the system and disregards the traffic flow from different functions when pfSense is doing more than one job (ie inter-VLAN routing as well as WAN routing). Having to run 2 instances, one for routing and one for shaping is IMO a flaw, as things like double NAT and extra hops should be avoided where possible.

As for the wizard itself, the main problem issue is that it creates confusion by providing a traffic shaping set up that's far from ideal, and people trying to replicate it's configuration are getting their knickers in a twist.

I've consequently realised after trying to set up ALTQ to do all shaping that it's only one part of the wider shaper config. The full config seems to need a little bit of ALTQ (queues), but NOT on downstream (or just FAIRQ/PRIQ with 100mbit), a little bit of L7 (complex applications, esp BitTorrent) and a little bit of floating rules as well as interface-assigned rules (assigning matched traffic to queues). The wizard only creates floating rules and altq on both WAN and LAN with fixed bandwidth.

As such this was a bug report to really have a good hard subjective look at the whole shaper config, as currently it's a) unnecessarily complex b) flawed in that to create a perfect shaping and multi-functional routing setup requires more than one pfSense instance and c) that the config the wizard produces isn't a very good example of a good setup.

What would be the best design to handle shaping and routing?

I just ran into a duh moment after a site with limited wan bandwidth complained about slow printing, the printer is on a different vlan than the machine sending the print job, so it is being limited to the wan bandwidth (384kbit in this case)

I've just been thinking a little bit about how to fix this when I saw this bug. Would there just need to be an added layer of queues to get this to work correctly?

lan (Wirespeed bandwdith)
-> qInternet (5Mbit bandwdith)
-> qAck
-> ...
-> qIntraLan (50Mbit bandwidth)
-> qAck
-> ...

Am I thinking about it correctly?

I think the first change could be that for multi lan setups, there should be another layer of queues to cover intra lan/vlan traffic. I would be happy with being able to set a blanket limit for all intra (v)lan traffic to start out with. The wizard would just ask for another bandwidth limit, the default intra (v)lan bandwdith, along with wan in and out bandwidth.

The floating rules might get a bit complex, since I don't think there is a built in alias for local lan interfaces...
Thanks
Josh

The wizard is the same as in 1.2.3 it just takes more values for multiple interfaces.
And for me this is not much different from 1.2.3 and should not be considered a bug.

If people want to create a wizard fine with me but the swiss knife will never be present.

Chris Buechler wrote:

The wizard in 1.2.3 creates seriously bad, wrong queues with behavior that cannot be duplicated all over again. Where downstream queues are still attached to LAN, that's a serious problem that was supposed to be addressed with the new shaper. Whether with separate queues for internally routed traffic or attaching that queue elsewhere, this has to be addressed.

Chris, when you say "Where downstream queues are still attached to the Lan" what exactly is your meaning. Do you mean attached directly to the lan queue? Because the new wizards do create a qInternet parent queue, and then attach the individual queues to that. The qInternet queue is attached to Lan. My diagram above came out wrong, it should have looked like.

lan (Wirespeed bandwdith) (HSFC and CBQ)
-> qInternet (5Mbit bandwdith)
L--> qAck
L--> ...
-> qIntraLan (50Mbit bandwidth)
L--> qAckIL
L--> ...

You also talk about attaching the queues elsewhere, but I thought that traffic shaping queues had to be attached to an interface, where else would you attach them?

I haven't had time to test it yet, but what I believe this is referring to is the queue for Internet traffic being attached to the WAN interface, so traffic from one internal interface to another internal interface (such as routing between VLANs or multiple physical interfaces) is limited as if it were Internet traffic. That may not be the case.

Thanks for your efforts in going through helping with tickets, Josh.

This is a major issue for us, and we'd be happy to contribute funds to getting this re-worked. Shaping that only works in one direction is almost entirely useless for us. There's some further discussion here: http://forum.pfsense.org/index.php/topic,34589.0.html.

We'd be happy to help out on this however we can, definitely want to see shaping on LAN interfaces as well as WAN interfaces.

I tried to test this out, but the description that Ermal added doesn't clearly tell me what I'm looking for. At first I thought I might be looking for a new queue at the same level as qInternet, but that isn't what I am seeing. And the only revisions listed in the ticket are the two from 7 months ago that removed lan side queues, which look like they were reverted.

I now found the revisions related to the changes. Looks like it is supposed to create a new Queue, qlink, it didn't work for me when I tried it though.

Oh, I see that if I have the p2pcatch all enabled, it doesn't create qLink.... When I tried it with p2pcatchall on, it behaved really strange.

- qOthersDefault was only created under the Wan->qInternet queue, it was left off all the LAN queues.

What are the chances that the queues created by the wizard could keep classifying all unknown traffic to or from the Wan network as qInternet->p2p, but classify traffic between Lan interfaces as qLink?

I'll test this out again without the p2pcatchall.
Josh

I tested out the shaper wizard without the p2p catch all, and it looks like the queues were created as intended.

qLink is created with a %20 bandwidth, which I think is the same as setting a linkshare of %20. It is set as the default queue.

I don't quite get how this is going to fix the issue without adding more rules though. No traffic is assigned to qLink other than what is not matched and assigned to another queue. So if I go through the wizard and set http & https to low priority, when I make a http connection to a server on a different interface, the traffic will be classified to the qOthersLow queue, and be limited to the qInternet speed.

How does all intra lan traffic get assigned to qLink?
Thanks
Josh

qLink will get all traffic that is not matched by the wizard rules.

I just committed an optimization that should address your concerns.

https://github.com/bsdperimeter/pfsense/commit/8fd84f8778dde3f1c62934c1c2ae687bc5c0f51f

Testing the changes made in commit 8fd84f8778dde3f1c629.

So now all the floating rules have WAN selected as the interface packets must come in on to be matched, it isn't really the interface that the packet comes in on though, right. Since the direction of the rules is Any. (Maybe that language should be fixed for the floating rule edit screen.)

The one last hole I see is the fact that any WAN->LAN*/LAN*->WAN traffic not matched will go into the default queue (QLink), and be unshaped. So the easy way for someone to get around the packet shaping is to pick a random port for their traffic. An easy test is to use the ICSI Netalyzr (netalyzr.icsi.berkeley.edu), it uses a port not matched by the default floating rules, so it's bandwidth test traffic is all categorized to QLink and isn't limited.

What is the easiest way to place unmatched Wan->LAN* and LAN*->WAN traffic into the QInternet->Qdefault or Qinternet->Qp2p queues?

Add a floating rule to the top of the floating list that matches
Interface: Wan
Direction: Any
Proto: Any
Source: Any
Dest: Any
Queue: QP2P

That rule will match all traffic that goes through the WAN, but it will be overruled by later more specific rules, and then traffic that doesn't touch the WAN will be assigned to qLink by default. Could the code that deals with the p2p catch all be changed to just add a similar rule to the top of the floating rules?

Thanks
Josh

Probably yes.
But that is what it does if you select it.
Meaning that qP2P will become default queue if you enable it as a catchall.

I will verify it again but that is how its supposed to work.

It seems to me that you are saying that p2p catch all and not shaping Lan to Lan traffic are mutually exclusive then. You can have one or the other.

I think that the intent of the p2pcatch all should be to match Wan->Lan* traffic, and not the intra lan traffic that now goes into qLink otherwise.

If the p2pcatch all added a rule to match all Wan<->Lan* traffic, and didn't set qP2P to default, then it would be the best of both worlds in my opinion.

And when the p2pcatch all isn't enabled, Wan->Lan* traffic that isn't matched should go into the qDefault queue, so it is managed by the limits of the qInternet parent queue.
Josh

Well making p2pcatch all only valid for Wan->Lan traffic is not easily possbile today.
It certainly would be possible in 2.1 when pf(4) has possibility to identify the interface the packet came in.

For sending all the non matching traffic to qDefault to honor link limits i am not too much worried since the limit of the link will be imposed by the provider usually.
If needed a floating rule with any any and interface WAN selected at the top should do the job.

Though its tricky to do autmatically for now, so i do not think it will make 2.0.