Traffic Shaping limits being ignored
-
Basically someone opened a bug about how the Traffic shaper didn't work very well in multi lan situations, so Ermal removed the ability to shape on LAN interfaces, which technically sort of fixed the problem… since intra lan traffic will no longer be shaped. So it now isn't possible to restrict the download speed while using the wizards.
That answers my question. Thanks. I was wondering why the LAN side bandwidth limit (on LAN Root) didn't work. I guess I need to find a way to perform LAN shaping via Limiter queues instead. However, this screws up my ack queues (ack packets are getting dumped into default queue instead).
-
Thanks stompro… that makes sense. Thanks Loke too... I didn't quite understand the way you wrote it, but I understand now. I'll follow up on that ticket. We'd be happy to sponsor development on this, it's pretty crucial and like you said, a shaper that only works one way is pretty useless.
-
Actually i said the same in my post, stompro. ;) And what they've done is not solution of the problem. ALTQ shaper just can't work in this case, old school dummy net shaper (personally like it much more) required for this purpose. At this moment it must be already fixed. Didn't tested it yet, but i will in a next few hours. Wizards must be fixed. If shaper shapes only in one direction, who need it at all? It's a nonsense. But we all must understand pfSense 2.0 is not ready yet, it's still in development stage so all we can do is wait or help developers to finish it faster.
Sorry Loke, I see it now, sorry for just repeating you. I have thought of using dummynet for this, but I haven't figured out how to use multiple dummynet pipes together yet. I want to keep using the built in limiters for the captive portal users, along with for certain other uses, and also run all traffic through one that limits to %90 of bandwidth, so I don't trigger the buffer bloat http://www.bufferbloat.net/ problem.
-
Well you can clone the WAN config on LAN from the Queue view tab and just change bandwidth settings.
That will enforce 'download' to be followed with the same rules. -
Dummynet shaper is quiet simple to understand. And when you'll understand how it works it's very simple to create any configuration you need. ALTQ shaper got a great minus. It can shape traffic only on exit from interface. Dummynet can shape in both directions and can limit speed not only for diff traffic, but also for diff sources/destinations. And this is a huge advantage over ALTQ in some cases.
-
@ermal:
Well you can clone the WAN config on LAN from the Queue view tab and just change bandwidth settings.
That will enforce 'download' to be followed with the same rules.Thanks Ermal, I've done that now. The shaper limiting is now working as it was some months ago. We're still interested in sponsoring this to come to a good solution for all parties.
-
BTW i think there must be an ability in wizard to select which type of shaper you want to use. In some cases preferred ALTQ in some Dummynet. But now if you want to use dummynet you forced to create a tonne of rules manually. And this is not good. ;D
-
What is dummynet exactly? Is that an internal scheduler that I can't select… cause I don't see it in the available schedulers.
-
He is talking about limiters.
But altq and limiters are very different in behaviour. -
What is dummynet exactly? Is that an internal scheduler that I can't select… cause I don't see it in the available schedulers.
Dummynet is completely different type of shaper so it's not the type of scheduler as it's not ALTQ. And ermal is right, it's called limiter in pfSense 2.0. If you want to use dummynet shaper you need to go to limiter tab and create pipes and queue manually. Than you need create corresponded rules to put traffic in queues. To understand dummynet you better look how it's done in m0n0wall. In pfSense it's very hard to understand. Or if you familiar with FreeBSD just look man ipfw and read about dummynet.
-
ok gotcha, thanks.
-
Have been working a lot with shapers and would like to add my 2 cents.
I have been playing with the altq hfsc queues and would like to say they are very much more powerful and useful than limiters/dummynet/captive portal limits. However it's a bit harder to understand, and I agree the wizard maybe doesn't shed much light on the workings…
As for the problem of mulitple LANs being limited when you limit the LAN interface, I think this is the same problem I ran into when putting a slow limit on the LAN interface, it also slows down the web interface to pfSense! The solution is to set the LAN interface queue rate at wire speed, and then create child queues to shape internet traffic, and send traffic to those queues with firewall rules. put the default queue as a direct child of the LAN with no bandwidth Upperlimit. Or alternatively use the default queue to shape internet (WAN) traffic, and create an unlimited queue and send inter-LAN traffic specifically to that queue. The point is that the root LAN interface is set to wire speed.
I know the wizards and interface doesn't make this intuitive or easily to edit... I find it much easier to edit the xml config file, cloning rules with copy and paste. But the wizard is a lot better than nothing, and it mostly makes sense, it's just that hfsc and the whole system is not a simple subject!
Also I found some good information about HFSC that was really useful for me to understand the configuration better, it seems to be very relevent to pfSense: http://www.iijlab.net/~kjc/software/TIPS.txt See section 3.
I think it has caused a lot of confusion that the wizard doesn't create LAN interface queues, but there is a lot of confusion anyway about shaping incoming traffic! I remember reading, "once the packets have come to your WAN interface from the internet, they have already used your bandwidth, so you can't shape that traffic." Well this isn't true at all, because of how TCP works. That is exactly how you shape any TCP traffic, by dropping packets when it starts to go too fast, which is what happens naturally without the shaper anyway, but with altq you can have a lot of control over which streams get slowed down by dropping packets. I know, i hate to drop packets at all after they have come all the way over an expensive satellite link, but that's how it works. If you want to share the bandwidth, you have to limit some streams, meaning you have to get the server to stop sending you so many packets, and that is done by not sending ACKs, which is done by dropping the packets. Still trying to understand the effects of delaying instead of dropping, but that causes even more problems so far. ECN makes lots of sense, but not sure yet if it actually works, maybe it isn't widely implemented across the internet.
Anyway, just wanted to post somewhere the little that I have learned lately, before i forget it! Should make for good discussion.
edit: UDP traffic goes to queues properly now!!!
-
Good tip, thanks!