From TomatoUSB to pfSense

ekoo

anyone?

Nullity

What problem are you experiencing, exactly?

I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)

ekoo

@Nullity:

What problem are you experiencing, exactly?

I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)

Thanks for the reply.

How I had Tomato setup is that it will work for 1 user, or 250+ units in an apartment complex. It is almost a 1 rule-set that fit most administration needs.
Tomato uses a first rule match system. So, if you look at how my rules are set in Tomato from top down, it makes sense.

The goal is to keep everyone happy with what they use…. at the expense of p2p. Since you cannot shape p2p directly, one can shape everything else to have priority over p2p.

To make it more simple:
Priority on VOIP, snappy HTTP(s), no lag gaming, no hassle video/audio streaming, quick downloads... and p2p takes the remainder unused bandwidth.

Nullity

@ekoo:

@Nullity:

What problem are you experiencing, exactly?

I think it is a bad idea to simply replicate the config you had with Tomato. Replicating the results is a much better goal and will likely require a much simpler config. (Your Tomato config seems wayyy too complex.)

Thanks for the reply.

How I had Tomato setup is that it will work for 1 user, or 250+ units in an apartment complex. It is almost a 1 rule-set that fit most administration needs.
Tomato uses a first rule match system. So, if you look at how my rules are set in Tomato from top down, it makes sense.

The goal is to keep everyone happy with what they use…. at the expense of p2p. Since you cannot shape p2p directly, one can shape everything else to have priority over p2p.

To make it more simple:
Priority on VOIP, snappy HTTP(s), no lag gaming, no hassle video/audio streaming, quick downloads... and p2p takes the remainder unused bandwidth.

Assuming that you understand how to deal with p2p upload & download (toastman's tutorial clearly explains this), then you only need to prioritize VOIP. You can find tutorials for this at the pfSense wiki, this forum, Google, etc.

The only thing that I see you might using that pfSense cannot do is allocate traffic differently depending on the amount of traffic a stream has transmitted/received. Example: After 10KBytes an HTTP stream is de-prioritized. Only Linux-based systems have that capability built-in.
This feature is less useful in the real world…

Otherwise your needs (snappy HTTP(s), no lag gaming, etc) are too generic and seemingly encourage premature optimization, which is bad. If you allocate p2p downloads correctly and use CoDel on your uploads then all your needs should be met. No complex setup required.

ekoo

@Nullity:

Assuming that you understand how to deal with p2p upload & download (toastman's tutorial clearly explains this), then you only need to prioritize VOIP. You can find tutorials for this at the pfSense wiki, this forum, Google, etc.

The only thing that I see you might using that pfSense cannot do is allocate traffic differently depending on the amount of traffic a stream has transmitted/received. Example: After 10KBytes an HTTP stream is de-prioritized. Only Linux-based systems have that capability built-in.
This feature is less useful in the real world…

Otherwise your needs (snappy HTTP(s), no lag gaming, etc) are too generic and seemingly encourage premature optimization, which is bad. If you allocate p2p downloads correctly and use CoDel on your uploads then all your needs should be met. No complex setup required.

Yes, I do understand how to deal with p2p uploads and downloads….. is not to apply a rule to it but prioritize known protocols. At least thats how I did it with tomato.

The other issue with my VOIP is that its an android app (Fongo) that I use on each phone (each phone has its own phone number). So its not a "proper" SIP or PBX, making it somewhat difficult to prioritize other than doing it thru ports.

I think i'm not understanding how to create the queues properly, what values to in which box.

Ultimately, I want to see the torrenting program, (uTorrent, BT, ed2k, etc ), speed drop when i start playing a 4K Youtube/Vimeo video, http download.

Is using CoDel a matter of a checkbox?

ekoo

I've borrowed a queue setup from here: https://forum.pfsense.org/index.php?topic=79589.msg635074#msg635074. Courtesy of 1activegeek.

WAN - Bandwidth = 1Gb
  - qInternet - Bandwidth = 6570Kb / UL = 6570Kb / LS = 6570Kb
    -qHighest - LS = 15%
    -qACK - LS = 20%
    -qHigh - LS = 15%
    -qMedium - LS = 20%
    -qDefault - LS = 20% (default)
    -qLow - LS = 8%
    -qLowest - LS = 2%
LAN - Bandwidth =1Gb
  - qInternet - Bandwidth = 26300Kb / UL = 26300Kb / LS = 26300Kb
    -qHighest - LS = 15%
    -qACK - LS = 20%
    -qHigh - LS = 15%
    -qMedium - LS = 20%
    -qDefault - LS = 20%
    -qLow - LS = 8%
    -qLowest - LS = 2%
  - qLink - Bandwidth = 972Mb / LS = 972Mb (default)

See attached for rules and queues

So far, I think i've replicated my old Tomato results fairly well…. start a few torrents, maxes out the line. Then start a 4k Youtube video, torrents slows to a crawl. VoIP works great, HTTP(s) works great.

My question: is it possible to have very little to zero drops in the queues?

queue1.JPG_thumb

queue2.JPG_thumb

shaper.JPG_thumb

rules2.JPG_thumb

rules3.JPG_thumb

rules1.JPG_thumb

Nullity

Dropped packets are perfectly normal, especially with TCP.

ekoo

@Nullity:

Dropped packets are perfectly normal, especially with TCP.

I mean, it is normal NOT to see any being dropped?

Also, does any of my rules or queue looks anything weird / wrong / can be improved ??

Nullity

@ekoo:

@Nullity:

Dropped packets are perfectly normal, especially with TCP.

I mean, it is normal NOT to see any being dropped?

If you never max out your connection or max out a queue's allocated bandwidth, you should see no drops.

ekoo

Does my setup give any red flags? See anything wrong / wierd / can be improved?

Correct me if I misunderstood how this QoS works:

Create how ever many/little queues you like to sort your traffic
(WAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which really is 95% of your actual line speed)
(LAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which is your NIC speed)
create rules with known protocols and assign them to the queues.
all unassigned traffic will default to a "default" queue.

is that summary correct?

Nullity

@ekoo:

Does my setup give any red flags? See anything wrong / wierd / can be improved?

Correct me if I misunderstood how this QoS works:

Create how ever many/little queues you like to sort your traffic

(WAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which really is 95% of your actual line speed)

(LAN side) allocate bandwidth to each queues adding up to 100% of total line speed specified in the interface (which is your NIC speed)

create rules with known protocols and assign them to the queues.

all unassigned traffic will default to a "default" queue.

is that summary correct?

That's close enough (I guess). Just try to keep your rules & queues simple. Taking the time to verify the functionality of each individual rule/queue is also important.