1 wan 3 lans , wan shaping
-
ok if i understand this right
my line has 25mbit download speed
im going to firewall traffic shaper -> interface and set
wan : 25 and codelq
lan 1: 3 and codelq
opt1 : 20 and codelq
opt2 : 2 and codelqis that correct?
what about the upload speed?
any info on how i can atleast limit down the torrents download ?
thank you for the fast replies!
-
any info on how i can atleast limit down the torrents download ?
Classify all known traffic and route to appropriate queues. All remaining traffic goes into the lowest priority queue. Bittorrent is hard to throttle, so it's easier to basically whitelist all known traffic and leave the rest in the slow lane.
-
is there anywhere a step by step guide as this is my first time messing with a firewall?
-
Not really. Traffic shaping is probably the most difficult thing about pfSense. Read everything you can, practice/play, ask questions.
-
lan 1: 3 and codelq
opt1 : 20 and codelq
opt2 : 2 and codelqIf you really want those to be hard limits, just use the limiters. They're a lot easier to configure.
-
lan 1: 3 and codelq
opt1 : 20 and codelq
opt2 : 2 and codelqIf you really want those to be hard limits, just use the limiters. They're a lot easier to configure.
can you be more spesific on how to do that? on my last attempt didnt seemed to work?
is this configuration that i posted is going to work?
thank you in advance
-
Simple way: Set the root interface to the speed you want, then enable Codel
More complex way: Create a queue on each interface for Internet traffic, enable HFSC, and set the upper limit to the speed you want, then use a rule to shove your internet traffic into that queue. Again, enable Codel.
the "simple" seems to work for downloads
what about the uploads?
-
lan 1: 3 and codelq
opt1 : 20 and codelq
opt2 : 2 and codelqIf you really want those to be hard limits, just use the limiters. They're a lot easier to configure.
How do limiters fit into the pipeline? If the limiters apply before Codel, then Codel won't help. With HFSC and the interface doing the limiting, I know the interface limits how quickly the queue is dequeued, but if the limiter happens after the queue, then Codel can't help.
-
I don't know. Codel isn't QoS. It simply drops packets that have been in the queue "too long" and its sole purpose is to prevent buffer bloat. Nothing else.
-
It's not QoS, but it maintains a stable low latency while allowing high throughput. Lower latency and higher throughput sounds like a win to me.
-
Not really. It still needs a shaper to avoid over-saturating your links.
-
Not really. It still needs a shaper to avoid over-saturating your links.
Yes, but because the limiter has that nifty feature where it can limit evenly per IP address, it leads me to believe that it doesn't limit the queue.
It should be easy enough to test.
- limit the interface and test two clients trying to saturate upload at the same time and monitor ping
- remove limit from the interface and instead use the limiter and do the same upload test
My guess is the limiter happens before the queue, which means it limits how quickly the queue fills up. If you want Codel to work, you need to limit how quickly it's drained.
*Entirely a guess based on what features the limiter has
