https://doc.pfsense.org/index.php/Traffic_Shaping_Guide

https://doc.pfsense.org/index.php/Limiters

All of my LAN shaping works fine. While the first interface rule gets processed first, floating rules get processed before even those.

With pftop, confirm that everything is going to the proper queues. This is usually my problem.

Queue bitrates on sending interface must be the lowest bitrate of the route. (I think you have success already)

What you have seems like it should work.

I dunno crap about IPSEC/VPN.

First off, the main issue of traffic shaping is you must set the interface to rate limit to just below the minimum amount of bandwidth you expect to have. I have a dedicated 100Mb connection, so I can safely set my bandwidth to 98Mb/s.

If you have a 100Mb connection of lesser quality during peak hours, you need to rate limit to your lowest, so if you dip to 80Mb, you need to limit to 78Mb/s, or some value below 80Mb.

Next problem. You cannot see into a VPN tunnel, PFSense will see a single encrypted flow. If you want to rate limit inside the tunnel, you need to set your tunnel interface to rate limit to the minimum rate you want to give the tunnel as a whole.

This does mean in order to properly rate limit, you need to give it a maximum rate if you want to shape the bandwidth with something like HFSC inside the tunnel.

If you don't want to artificially set a maximum, but instead want the tunnel to be able to use an "free" bandwidth, then you could probably use PRIQ or FAIRQ. I would recommend trying FAIRQ first. CoDel may also work. If we had fq_Codel or Cake, I would recommend those because they do well with fluctuating bandwidth where your interface is doing the buffering.

PRIQ doesn't need to know the bandwidth, but your interface still needs to have the bandwidth rate limited, otherwise your interface will just pump out data as fast as the interface, which is probably 1Gb/s. When data comes in faster than 1Gb/s, PRIQ will start to re-arrange packets.

Thanks Harvey, worked like a charm…

PFSense has two types of shaping, interface shapers like HFSC and limiters. HFSC can shape the egress of an interface. In other words, you can shape the data leaving your WAN and you can shape the data leaving each of your VLAN interfaces, but you cannot have your interfaces share state. Each interface does not know anything about the shaping of another interface.

Some people claim there are some round-about ways to effectively share bandwidth across several interfaces, but at least for easy setups, you'll need to forget sharing bandwidth and instead just carve out dedicated bandwidth.

@stephenw10:

You are probably hitting this: https://redmine.pfsense.org/issues/4326
Set the limiter on the LAN side or try a 2.2.3 snapshot where I believe a patch has now gone in: https://redmine.pfsense.org/issues/4596

Steve

Steve,

Thank you!  A quick scan of that bug looks like it's a good bet as to the source of the problem.  I've been pulling my hair out trying to figure out what's wrong.  Everything's working and then I insert the two limit queues into the firewall rule and everything just stops.

Regards,
  Fred

Ah thank you.

I was trying to make sense of why such a broad rule was created by the wizard.

@mcwtim:

Proper upgrade procedure is to backup your config, uninstall any packages, do your upgrade, reinstall your packages then re-import your config.

RTFM  ;) Thank you, all this time and I did not know that.
What must have happened was that I tried to setup traffic shaping on the old release, it failed, updated to latest, re-ran the traffic wizard and failed.
Could have been that the box did not reboot. Couldn't get to a prompt on the local console .Had to have someone on site hit the power button.

Client is still up.
I'll build a new box and ship it to them.

Thanks again

TL

jr.fenol, could you create your own thread instead of spamming someone else's?

Hi Harvy,

If applied to both WAN Interfaces, both WAN Queues are working for Upload. –> This should be OK.
Currently, i'm not load balancing because i'm afraid for overloading 1 of the Download Lines.

I want to shape the Download, and this seems to only work when the LAN Interface is selected in floating Rule.

Maybe disable ECN?

Ok

So I an use a priority queue to guantee the uplink on a single WAN which is good as that is more limited, and dedicate a fixed bandwith to the VOIP on the downlink, which means there is some wasted when no calls are happening, but isn't too bad.

If I had 2 boxes, the first with just 2 interfaces, then I could queue both in and out based on destination quiet happily. What about some clever configuration where by all traffic coming in on the wan got routed out of an interfaces with a queue, which just came back in on another spare interface to be then processed as normal. Would that work / have any disadvantages? Clearly would need 2 spare interfaces to do it.

You can't shape ingress traffic, but most traffic is not a DOS and follow rules. UDP traffic is typically fixed bandwidth and will not attempt to fill up your pipe, while TCP will attempt to fill up the pipe, but backs off on packet-loss.

In my case, prior to my ISP having an AQM and had a hard cut-off for bandwidth by using the rate limiting built into my ONT which was very strict, setting my LAN interface to about 95% of my bandwidth pretty much kept ping spikes out, which means no buffering on my ISP's side. I could have reduced my bandwidth further and tightened the ping spikes, but way too much diminishing returns. I was already down near 10ms. While 98% link speed resulted in packet-loss and some major ping spikes. That 3% different was pretty big.

My point is TCP is pretty good at responding to congestion. Latency is a big issue. My tests were primarily against busty traffic like speedtests or youtube, which I had between 10ms and 20ms. If the sender is further away, like 200ms, it will take that much longer for the packet-loss signal to reach them.

It really depends on your typical use cases.

I have never used the L7 stuff, but just wanted to point out the bug in your XML.

sorry about the confusion. if i set the limiter to 2Mbit/s upload or anything else I get 0.09 Mbit/s Upload but if i take off the limiter in firewall rules i get my full 4 Mbit/s Upload. I suspect something weird is going on here.

I have not been able to get limiters working at all, since 2.1.5 or earlier. Could just be me though… but I would expect SOME life to show in the limiters when most of my other configs work as I assumed they would.

Is there a standard practice for enabling debugging or verbose logging? I think I remember something at boot about verbose logging. Is there a debug toggle for ipfw/pf/altq?

No, they are ignored unless you craft your own traffic shaping rules to prioritize the traffic.