A definitive, example-driven, HFSC Reference Thread


  • Netgate

    I would like to start a thread about the proper configuration of HFSC on a typical SOHO network.  I would like to eliminate the guesswork involved in floating rules, what interfaces are tagged in them, is the direction in or out, and, of course, the HFSC Queue hierarchy itself.

    In a self-serving manner, I have diagrammed the network I would like to get shaping working on.

    My initial goals are:

    • Shaping everything to the 1500/256k cable modem connection

    • Prioritizing ACK and DNS traffic for LAN/OPT1/OPT2

    • Ensuring LAN <-> DMZ runs at full ethernet speed

    • Put an Upperlimit on OPT2 of 10/1

    When all that is designed, I would like to prioritize the VoIP traffic and add, maybe some gaming prioritization to the workstation on LAN/192.168.223.6.  Then perhaps, add P2P/BitTorrent as low-priority traffic.

    I will be running the wizard on this configuration tonight and I figure that's where I should start since it's the go-to default starting point for HFSC noobs.

    By the time this thread has run its course I hope that all participants, myself included, will have a pretty complete understanding of how to properly shape with HFSC on pfSense 2.1.

    ETA:
    Links harvested from thread posts:

    HFSC Tutorial "for a deep explanation on HFSC"
    Traffic Shaping with pfSense and HFSC - YouTube - Andre LaBranche


  • Netgate

    Well, I got home and started working on this only to find out that Cox has discontinued the ability to temporarily subscribe to an additional WAN address.  I want to use a real public IP for this to best fit the normal use case to I'm hooking it up to a backup 1.5M/256kbit DSL service instead.  The drawing has been changed to reflect this.

    DMZ and WAN are currently not connected (link down).

    I installed 2.1.4, created all the interfaces, enabled DHCP on LAN, OPT1_DMZ, and OPT2_GUEST and got the DHCP from the DSL provider on WAN.

    I deleted the Allow IPv6 any rule from LAN because I'm not testing IPv6.

    On OPT1_DMZ:
    Reject any to LAN net
    Reject any to OPT2_GUEST net
    Permit any any

    On OPT1_GUEST:
    Reject any to LAN net
    Reject any to OPT1_DMZ net
    Permit any any

    I then ran the Single_WAN_Multi_LAN traffic shaper wizard.  Below you can see my interface settings.  I just selected Next through the rest except for the other protocols screen, on which I told it to prioritize DNS.

    ![Screen Shot 2014-07-21 at 10.59.23 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 10.59.23 PM.png_thumb)
    ![Screen Shot 2014-07-21 at 11.13.44 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.13.44 PM.png_thumb)
    ![Screen Shot 2014-07-21 at 11.13.44 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.13.44 PM.png)
    ![Screen Shot 2014-07-21 at 10.59.23 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 10.59.23 PM.png)
    ![Screen Shot 2014-07-21 at 11.18.21 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.18.21 PM.png)
    ![Screen Shot 2014-07-21 at 11.18.21 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.18.21 PM.png_thumb)
    ![Screen Shot 2014-07-21 at 11.18.29 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.18.29 PM.png)
    ![Screen Shot 2014-07-21 at 11.18.29 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.18.29 PM.png_thumb)


  • Netgate

    I got these rules when I was done.  The two DNS rules are Match on WAN in any direction.  Not quick.

    ![Screen Shot 2014-07-21 at 11.17.19 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.17.19 PM.png)
    ![Screen Shot 2014-07-21 at 11.17.19 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.17.19 PM.png_thumb)
    ![Screen Shot 2014-07-21 at 11.30.55 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.30.55 PM.png)
    ![Screen Shot 2014-07-21 at 11.30.55 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.30.55 PM.png_thumb)


  • Netgate

    I then started a large download and opened a terminal window.  This is where things don't seem quite right.  In the terminal window I repeatedly entered 'dig @8.8.8.8 www.google.com'.  Query time really suffered during the download, like 700-1000ms up from about 75ms with no other activity.  Rather than paste a bunch of screen shots, I am pasting the pertinent section of /tmp/rules.debug and a pfTop capture.

    I find it interesting that all the downloads are on qLink instead of qInternet.  Downloads don't appear to be subject to shaping at all until there's contention for the gigabit LAN.  Am I missing something?

    ![Screen Shot 2014-07-21 at 11.16.55 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.16.55 PM.png)
    ![Screen Shot 2014-07-21 at 11.16.55 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.16.55 PM.png_thumb)
    ![Screen Shot 2014-07-21 at 11.35.05 PM.png](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.35.05 PM.png)
    ![Screen Shot 2014-07-21 at 11.35.05 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-21 at 11.35.05 PM.png_thumb)



  • The problem with your approach is assuming that there are a lot of people here who know HFSC inside & out, and are willing to help.  My experience here is that's just not the case.  I have only seen a small handful of people who really seem to know HFSC, and I'm sure they're not interested in providing free consulting.  I spent a lot of time trying to fully understand HFSC and read a lot about it online from every source I could find.  In the end, I switched to PRIQ.  So much easier to understand & manage.


  • Netgate

    That is what this thread is intended to remedy.  I don't think it is a matter of people not wanting to provide free consulting, I think it's simply a time issue.  I am not asking for someone to say "Here is the config for your network," but I am hoping that either I can figure this out piece by piece, or someone might chime in with a piece of the puzzle occasionally.  I know I could just punt and use PRIQ, but I don't want to. :)

    I haven't quite nailed it down yet, but it seems having the qLink queues tagged as "default" is a problem.

    I created qDefault queues under qInternet and changed them to default (removing default from qLink) and I started getting more desired behavior.

    I then created floating match rules for the LAN<->DMZ traffic, sending it to qLink and my testing wasn't positive.  Seemed like it was only going into qLink in one direction or something.  I haven't been back to it since.  Maybe tonight.

    The wizard output for WAN seems to be pretty close.  It's the qLink/qInternet queues on LAN ports that appear to need some work.



  • IMO, HFSC is only really useful in the case where you have a heavily saturated link with time-sensitive devices on the network, but you want to maintain minimum service levels for the lower queues.  With PRIQ, your higher queues will always be serviced first to the possible severe detriment of the lower queues.  Everything else can be done via PRIQ or limiters.  However, I'm happy to help however I can.  I've forgotten a lot of what I thought I knew, but isn't qLink the Linkshare queue?  When all RT guarantees are met, all available bandwidth is allocated to LS aka qLink, with a max of 100% and a minimum guarantee of whatever your bandwidth setting for qLink is, IIRC.



  • Alright!

    First and most important of all (I think that I mention this on at least 70% of my topics here): shaping for multi-LAN does NOT work as one would expect, even if the wizard pretends to configure it. Download is shaped on the LAN side, but you cannot have a queue applying to more than one interface at a time. So you cannot "share" download bandwidth between download interfaces. However, you could set a hard limit of 500 Kbps on each of your LAN queues, in a way that the sum of them will never exceed what your ISP provides you. Obviously, this is plain awful and far from optimal.

    There are currently 3 ways around this (that I can think about):

    • You can bridge the 3 interfaces and apply the shaper to the bridge (you can still control inter-LAN traffic fairly well with rules)
    • You can use VLANs on the same interface + an L2 switch, and apply the shaper to the physical interface
    • You can use another pfSense box in front of the other one, just for shaping purposes.


    Now, as regards HFSC, I suggest to avoid using the wizard and configure it yourself from scratch, it is not that difficult. Here are some tips (although most of these apply to all schedulers):

    • Remember this is a stateful firewall and the shaper is tied to it. When the traffic goes through the firewall, you only need to queue it once (either incoming on one interface or outgoing on the other one, and just in one direction). On the other side, it will get on the queue that has the same name (and this is why queues on LAN and WAN have the same names). You are in fact shaping connections and not packets.
    • The whole traffic shaping thing is based on the assumption that you know the download and upload limits of the connection. The idea is that queuing occurs at your router (where you can control it) and not at your ISP's router. This is why it is so important to properly set the upper limits on the parent queues (and this is also why the multi-LAN I mentioned before does not work)
    • I prefer to queue outgoing connections (LAN to internet) with floating rules, direction OUT, on the WAN interface. Always specify the interface and direction on floating rules, otherwise it will quickly become a nightmare to debug (which rule is really applying??)
    • I prefer to queue incoming connections (NAT port forwards and alike) on the regular interface tab (you need an allow rule there, anyway).
    • Set the qLink queue as default queue on every interface. Then make proper matching rules to direct the traffic wherever you want.
    • Remember that floating rules, action match, are not "quick" rules. This means that all rules will apply in order, and the last one matching wins. This means that the logic is sort of the inverse of the regular interface rules. Here the most general rule needs to go first, and more specific ones below it. Keep this in mind!!
    • The only protocol where the "ack queue" concept makes sense is TCP. For whatever else, keep the selection empty.
    • The "priority" option does not do anything on HFSC (check the source code!). In fact, I'm not sure why the box is still there…
    • For a matter of simplicity, on HFSC always set the same value on both linkshare m2 and bandwidth. They are actually the same thing, but if your values differ you will not know which is the one applying…
    • For now, lets forget about the m1 and d parameters, so everything I say applies to m2.

    --
    Practice time! Delete all queues and related rules and start from scracth (also, for the reasons stated before, all examples involve just one LAN).

    Let's start by priotizing DNS traffic.  Create this hierachy on both LAN and WAN:

    *qInternet
    ---qDNS
    ---qBulk
    *qLink

    You will set both the upperlimit and linkshare of qInternet on LAN to around 95% of your real download speed, and both upperlimit and linkshare on WAN as 95% of your real upload speed. Also, on both interfaces set qLink as the default queue. Why the linkshare value? Because on this hierachy, this is a parent queue and you will in fact be queueing traffic on the children queues.
    Set qDNS as having 30% realtime and 10% linkshare (and bandwidth).
    Set qBulk as having 90% linkshare (and bandwidth)
    Set qLink as having 20% linkshare (and bandwidth). In fact, it doesn't really matter what value you put here since this queue is destined for local traffic.

    What's the deal here? Realtime is guaranteed bandwidth. This means that no matter what the other queues want, this queue will get 30% of the available bandwidth for itself at any given time ()*, even if by doing so other queues need to drop packets. The sum of all the realtime values cannot exceed 80% of your bandwidth (note: 30% for DNS is insanely high on a real life scenario, but this is just for learning purposes)

    To keep this simple, always try that the sum of the linkshare values from the children queues sum up to the value of the parent queue. This is because HSFC uses a "sustractive" method for the percentages (I can elaborate of this later).

    Now, let's go for the rules. On the floating tab, create these rules:

    • Interface WAN, direction OUT, protocol UDP, destination ! WAN net, port 53 –> queued onto qDNS
    • Interface WAN, direction OUT, protocol any, destination ! WAN net –> queued onto qBulk

    I like to include "destination ! WAN net" on these rules to keep potential traffic intented to some other host on the WAN subnet out of the internet queues but on the default qLink.

    That's it. A quick test should reveal that DNS queries are being placed on the appropriate queue.

    IMPORTANT NOTE: this doesn't mean that DNS queries will be magically faster, there are several factors to consider. For example, if you have 500 torrents active at the same time, clogging up your bandwidth, probably there's no shaping on Earth that can help…

    These very same principles can be applied to shaping any other kind of traffic.

    Feel free to ask any questions. Hope this helps! (I should probably write a Wiki article at some point, though). Next lesson we can talk about the ACK queues ;)

    Best regards

    EDIT:

    ()* while re-reading what I wrote, "at any given time" here sounds somewhat misleading because what realtime actually guarantees is not the instantaneous bandwidth but the long-term average. In real life on a properly configured hierachy, it's unlikely that the traffic gets penalized for having exceeded its bandwidth in the long term, though. Still, the best use of realtime queues is to handle latency through properly set d and m1 parameters, and NOT prioritization of packets

    ANOTHER EDIT: for a deep explaination on HFSC, this is my favourite source of info: http://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt



  • Thanks a lot George for your contribution.  I've seen you here before and I've read all your HFSC posts, but I didn't think you were around much anymore.

    Question:  As I was creating the queues as per your directions, the GUI kept yelling at me 10-11 times about this same error:

    (There were errors loading the rule(s): pfctl: the sum of the child bandwidth higher than parent root_em0 - The line in question reads (0): )

    Did you see this?  I went through and checked everything again and it looks good, but I still have the errors.  Is this normal when you're building the queues manually?

    When I look at Status - Queues, all I have are Root Queue and qLink.  All the others aren't being shown.



  • @KOM:

    Thanks a lot George for your contribution.  I've seen you here before and I've read all your HFSC posts, but I didn't think you were around much anymore.

    Question:  As I was creating the queues as per your directions, the GUI kept yelling at me 10-11 times about this same error:

    (There were errors loading the rule(s): pfctl: the sum of the child bandwidth higher than parent root_em0 - The line in question reads (0): )

    Did you see this?  I went through and checked everything again and it looks good, but I still have the errors.  Is this normal when you're building the queues manually?

    When I look at Status - Queues, all I have are Root Queue and qLink.  All the others aren't being shown.

    That message shows up when the sum of the bandwidth assigned to the children queues is higher than the parent queue. There must be some value not set properly. Probably the bandwidth of the interface itself? (leave it blank)

    You can post the generated rules from rules.debug and we'll see…



  • In my lab, I gave it an arbitrary bandwidth of 9Mb/s up/down.  Then I followed your directions exactly and pumped in all the specified percentages.  Did you mean to say that actual percentages should be used in the GUI, or were you meaning that we should pump in n% of the actual bandwidth number?  maybe I'll run through it again here at home.  Won't be back in the office until Monday.

    Edit: SO I just spun up the lab and tried it.  I set WAN and LAN bandwidth to 9Mb/s.  I created qLink next, set it to default, gave it bandwidth 20% and LS 20%.  Then I created qInternet and gave it UL 95% LS 95%.  As soon as I applied it, the same error appears.  See attached pics.








  • Dont put the bandwidth vaule on LAN and WAN. Put the value on qInternet. Leave the WAN and LAN blank and you should not get the error.

    You want the qDNS to be under the qInterent. qLink and qInternet should be on the same level.



  • Thank you.  That wasn't clear to me.  No errors when I applied the shaper.

    Edit: Not so fast.  I went to Status - Queues and it failed to load the queues at all, and the error appeared in the statusbox again.



  • I would blow it all away and redo it from scratch. I can try it in my lab later and see what I get.



  • @sideout:

    Dont put the bandwidth vaule on LAN and WAN. Put the value on qInternet. Leave the WAN and LAN blank and you should not get the error.

    You want the qDNS to be under the qInterent. qLink and qInternet should be on the same level.

    Yep, exactly. The idea is not to limit the interface itself but the queues, since you might have local devices lying on your WAN subnet



  • I went back to my snapshot and tried again with the bandwidth value removed from WAN and LAN and added to both qInternet queues.  Same result with a slightly different error:

    (There were errors loading the rule(s): pfctl: linkshare sc exceeds parent sc root_em0 - The line in question reads (0): )



  • Are you staggering the queues though?

    It should be like this:

    LAN
      qLink - 20%
      qInternet - 95% of your real download vaule
        qDNS - x%
        qBulk - y%

    x + y have to be less than value of qInternet



  • I know what it's going on here. You should not type "95%" but the real amount, in Mbps or Kbps, that represents the 95% of your real speed



  • Where, in the Bandwidth combobox or the service curve variable boxes?  Or both?

    Edit:  Never mind.  It seems to not like using % at all.  I had to convert everything to Kb and Mb instead of %, and then finally my queues appeared in Status.

    It should be like this:

    LAN
      qLink - 20%
      qInternet - 95% of your real download vaule
        qDNS - x%
        qBulk - y%

    I had the proper parent/child hierarchy but that wasn't my problem.

    In your example, what is the relationship between qLink and qInternet as far as bandwidth is concerned?  They are both at the same level, but qLink has 20% and qInternet has 95% for a total of 115%.  I don't know how that is.



  • Since there is no value on LAN , the value on qLink does not matter as it is default and for local traffic.  The only thing that matters is the value on qInternet . That defines how much the child queues have.

    It's kind of weird I know but it does work.



  • Since there is no value on LAN , the value on qLink does not matter as it is default and for local traffic.

    Can you leave it blank or must you provide some value, which is then subsequently ignored?

    Set qDNS as having 30% realtime and 10% linkshare (and bandwidth).

    Another question, sorry.  What is the bandwidth relationship above, and how does it figure into the parent/child calculations?  If I have parent qInternet at 10Mb and children qDNS at 1 Mb and qBulk at 9Mb, do I set qDNS's RT to 300Kb and LS to 100Kb as per 30%/10% above?  Is it supposed to add up to 1 Mb, the bandwidth total for the parent qInternet?



  • It needs a value. 20% is fine for a random value.  qDNS can be set at whatever you want. I just used 30% as an example.



  • But what's qDNS's relationship between RT, LS and bandwidth?  LS and bandwidth are the same variable, so for my example, where qDNS bandwidth is 1Mb, I would set LS to 1 Mb and RT to 3 Mb (30%)?  If so, that extra 2Mb above what the bandwidth setting is, where does that come from?



  • I wouldn't set the RT to anything except for your priority queues.  RT say it gets X amount of bandwidth ALL the time so if you give qDNS 3MBIT then it gets 3Mbit all the time.  So that extra 2Mbit comes from whatever qInternet is set for , your case 9Mbit.



  • I would only ever use RT for VoIP traffic and ACK, typically.  OK, so it draws from the parent queue.  Sorry for asking endless questions but it's the only way to wrap my head around the whole thing and connect the dots between all the elements so that it makes sense.  I don't like following instructions without knowing what I'm doing and why,



  • No worries. That is the best way to learn.


  • Netgate

    Thanks sideout, georgeman.

    A couple things:

    georgeman:

    I know you specify this in the text, but in the floating match rules we still do not apply "quick" right?  This means that the qBulk rule has to come before the more specific qDNS rule.  One might be misled by the order in the text.

    sideout/all:

    The realtime queue you're discussing only applies when there's contention/congestion right?  If I specify 30% realtime for qDNS and there is no DNS traffic being placed in the queue, the other queues are not absentmindedly robbed of the 30% bandwidth, if I understand things.

    This has all been a really big help.  I appreciate it.  I am currently implementing the solution provided by georgeman on my bench.  More later.



  • From my understanding - RT means that X% is taken automatically for that queue even if there is no traffic in the queue. At least that is the way it reads to me.    For what I use it for , qGaming that is a non issue as my use of HFSC is with traffic shaping at LAN parties so qGaming is my highest priority queue.  I use the following queues:

    LAN
    qInternet - bandwidth - 50MBit - I have 4 cable modems but putting in 200Mbit here would not be the correct thing to do as I cannot bond them to get 200Mbit
    qGaming - gaming traffic - RT 30% / bandwidth - 40% / LS - 40%
    qHTTPSTeam - bandwidth - 20% / LS 20%
    qWEBTraffic - bandwidth -  20% / LS 20%
    qACK - bandwidth - 20% / LS 20%

    qLink - bandwidth - 20% / LS - 20% - default queue

    WAN - 5MBIT - I have 4 WAN's so each are 5Mbit upload
    qLink - bandwidth - 10% / LS - 10% - Default queue
    qGaming - bandwidth 40% / RT - 20% / LS 40%
    qHTTPSteam - bandwidth - 20% / LS 20%
    qWEBTraffic - bandwidth - 20% / LS 20%
    qACK - bandwidth - 10% / LS 10%

    I use the floating rules to put DNS in the qGaming so it gets good response.  General web traffic goes into qWEBTraffic and then I use rules to put Steam traffic into qHTTPSteam.
    I use interface rules to direct gaming traffic out different wans via gateway groups. I allocate one modem / wan to like LoL gaming traffic , another to BF4 . I dedicate one modem to strictly web traffic and another modem is reserved for staff use and downloads as I have a limiter on for DHCP addresses to restrict all TCP connections to typically 25Mbit for everyone.

    This way I can get the best ping times and still give everyone bandwidth to do what they need without being too restrictive.



  • I'd like to see your ruleset if it isn't too much trouble.


  • Netgate

    Okay.  This is all coming along nicely.

    I have created the following queues:
    WAN
      qLink default bw 20% ls 20%
      qInternet bw 15Mb ul 15Mb ls 15Mb
        qDNS bw 5% rt 5% ls 5%
        qACK bw 10% ls 10%
        qVPN bw 10% rt 5% ls 10%
        qBulk bw 50% ls 50%
        qOpenWireless bw 2Mb ul 2Mb ls 2Mb

    LAN
      qLink default bw 20% ls 20%
      qInternet bw 50Mb ul 50Mb ls 50Mb
        qDNS bw 5% rt 5% ls 5%
        qACK bw 10% ls 10%
        qVPN bw 10% rt 5% ls 10%
        qBulk bw 50% ls 50%

    OPENWIRELESS
      qLink default bw 20% ls 20%
      qInternet bw 10% ul 10Mb ls 10Mb
        qOpenWireless bw 50% ls 50%

    The screen shot details the floating rules.  All are !quick on WAN direction OUT.

    The only thing that's not going to the right queue are connections from OPENWIRELESS into the qOpenWireless on WAN.

    I have reset states.

    I have told my pass any any rule on OPENWIRELESS to queue to qOpenWireless.  That gets downloads into the right queue on the OPENWIRELESS interface but uploads are still going to qBulk.

    I am assuming this is because the floating rule on WAN OUT is happening post-NAT so the match on the source address is failing.  I just fixed this by, instead of my pass any any rule on OPENWIRELESS setting the queue to qOpenWireless, I instead mark the packet with "OW" and use that in a floating rule on WAN OUT to match on "OW" and place the traffic into qOpenWireless.  Seems to work.

    ![Screen Shot 2014-07-27 at 11.15.48 AM.png](/public/imported_attachments/1/Screen Shot 2014-07-27 at 11.15.48 AM.png)
    ![Screen Shot 2014-07-27 at 11.15.48 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-07-27 at 11.15.48 AM.png_thumb)



  • @KOM:

    I'd like to see your ruleset if it isn't too much trouble.

    I will post up my latest rule set on Monday when I pull it off my lab firewall.



  • Here are my FW rules and alias's. You need the Alias's as well to use my rule set.

    https://www.dropbox.com/s/y7dtifw12y6ghmx/fwrulesalias.zip



  • @KOM:

    In your example, what is the relationship between qLink and qInternet as far as bandwidth is concerned?  They are both at the same level, but qLink has 20% and qInternet has 95% for a total of 115%.  I don't know how that is.

    No, again, do not set "95%" for the value, but the real downlaod/upload speed multiplied by 0.95 aprox

    Consider that the interface speed is usually either 100 Mbps or 1000 Mbps, while the real download speed is, let's say, 5 Mbps. In this case, you would set the m2 and bandwidth values of the qInternet queue at 4.75 Mbps.
    Then, if you set qLink at 20% that would be 100 Mbps x 0.2 = 20 Mbps.
    So the sum of the bandwidth assigned to both root queues is actually 24.75 Mbps (< 100 Mbps)

    We say that the 20% value for the qLink queue doesn't matter because in this examples, it is destined just for local traffic, there is not upperlimit on it and usually the qInternet values are way lower than the interface speed. If this is not the case, or if you want to be strictly accurate, you would need to set the qLink value to the difference between the interface speed and qInternet values, so the sum of them adds up to 100% (or the interface speed)

    Anyway, linkshare values are not absolute values, but relative to each other. It doesn't matter if they don't add up to 100%, what matter is the proportions between them. If you set ls to 20 on one queue and to 1 on another, that means that ls will try to give the first queue 20 times more bandwidth than the second one (when the link is saturated)

    @Derelict:

    georgeman:

    I know you specify this in the text, but in the floating match rules we still do not apply "quick" right?  This means that the qBulk rule has to come before the more specific qDNS rule.  One might be misled by the order in the text.

    Exactly. Traffic will first match the qBulk, then the qDNS too, and will stick to the last one that matched

    @Derelict:

    sideout/all:

    The realtime queue you're discussing only applies when there's contention/congestion right?  If I specify 30% realtime for qDNS and there is no DNS traffic being placed in the queue, the other queues are not absentmindedly robbed of the 30% bandwidth, if I understand things.

    Yep, as you say. By specifying realtime on one queue, if that bandwidth isn't being used it is still available to other queues.

    –------

    There are tons of factors and caveats to consider for an accurate implementation. For example, RT considers the service curve since traffic started, so it could be "penalized" on high-usage times if it was exceeded during non-peak times and we are not using linkshare (not what we want!)

    This is why some people (I tend to agree with this), suggest to use RT only to fulfill latency requirements and not bandwidth requirements (which can be handled by linkshare). And when you use RT, set the service curve on LS to the same values as RT (to account for the above scenario)


  • Netgate

    Ok.  Moving on to the OpenVPN prioritization.

    My Site-to-Site OpenVPN to the office is on server aliased to work_vpn UDP 1195.

    I have qVPN on WAN and LAN set at bw 10% rt 5% ls 10%

    Floating rule: WAN out dest work_vpn UDP 1195 none/qVPN

    That places traffic sent to the VPN in qVPN but none of the return traffic is going into qVPN on LAN.

    I haven't been able to get traffic received through the VPN into qVPN on LAN.

    I have tried

    Floating: LAN out source remote_vpn_lan any none/qVPN
    Floating: WAN in source work_vpn UDP 1195 none/qVPN

    I know that I can't apply queues to virtual interfaces (OpenVPN) only physical.  Not sure what I need to do here.

    Edited:

    I think I solved this with the following rules:

    Floating Match LAN in any source any dest remote_vpn_lan  none/qVPN
    Floating Match WAN out UDP source any dest work_vpn 1195 none/qVPN

    It looks like one of the necessary concepts to grasp is your rules have to be implemented so they catch the traffic at the point of state creation.

    It looks like this also works:
    Floating Match OpenVPN any any source any dest any  none/qVPN
    Floating Match WAN out UDP source any dest work_vpn 1195 none/qVPN

    I would think that the former could be used to queue a specific VPN out the LAN interface and the latter would be an easy way to do the same with all OpenVPN traffic.



  • @georgeman:

    We say that the 20% value for the qLink queue doesn't matter because in this examples, it is destined just for local traffic, there is not upperlimit on it and usually the qInternet values are way lower than the interface speed. If this is not the case, or if you want to be strictly accurate, you would need to set the qLink value to the difference between the interface speed and qInternet values, so the sum of them adds up to 100% (or the interface speed)

    Hello Mr. Georgeman,

    How the local traffic is directed through qLINK ? is there any floating/lan/wan rule I need to apply?

    Regards,

    CP



  • Hello phoenixsampras,

    I suppose that, given we've made qLink the default queue, anything that does not match the other queues, go into the qLink queue "by default".



  • Hello all,

    I have a few queries:

    1. I need some clarifications regarding the relationship between incoming/outgoing connections and downloading/uploading.
    I understand that, whether a connection is incoming or outgoing depends on the location/interface where the associated state is first created.
    So, if this is correct, then we can say that incoming or outgoing connections are not related to downloading or uploading.
    As an example, a local FTP client makes an outgoing connection to a remote public FTP server, but afterwards, a download or an upload can be made.
    Similarly, a remote FTP client makes an incoming connection to a local FTP server, but afterwards, a download or an upload can be made.
    Is my understanding correct?

    2. From what I've understood (as Derelict also mentioned), in order for traffic shaping to work and for the packets to be placed in the correct queue, the rule should be on the interface where the state is first created. Can anyone confirm this?

    3. When we create and define the queues in "Firewall->Traffic Shaper" in pfSense, queues created on the LAN interface shape downloads and queues created on the WAN interface shape uploads. Is this correct?

    Thanks for any help.


  • Netgate

    @netsysadmin:

    Hello all,

    I have a few queries:

    1. I need some clarifications regarding the relationship between incoming/outgoing connections and downloading/uploading.
    I understand that, whether a connection is incoming or outgoing depends on the location/interface where the associated state is first created.

    Yes, but this can be either the ingress or the egress interface for the state.  Here's an example using the diagram at the top of the thread and FTP.  Say you have an FTP client on LAN connecting to an internet FTP site.  You can either set the queue with a firewall rule on LAN, or a floating rule on WAN out.  Like georgeman and sideout have indicated, it's a lot easier to shape on WAN out.  This is because you probably do not want to shape FTP from, say, LAN to DMZ so you can either have a lot of rules for LAN governing what is shaped and what is not in or just put it on floating WAN out with qLink the default queue on LAN.

    So, if this is correct, then we can say that incoming or outgoing connections are not related to downloading or uploading.
    As an example, a local FTP client makes an outgoing connection to a remote public FTP server, but afterwards, a download or an upload can be made.

    Yes.  When either interface matches and sets up a state, the queue on the other interface of the same name is also set.  In this example qFTP on WAN will shape traffic out of WAN and qFTP on LAN will shape out of LAN.  So your LAN queue will regulate "downloads" and your WAN queue will regulate "uploads", regardless of how the state was created.

    Similarly, a remote FTP client makes an incoming connection to a local FTP server, but afterwards, a download or an upload can be made.
    Is my understanding correct?

    Yes.  But for inbound sessions to a local FTP server, you probably want to set the queues on the firewall rule on WAN that allows such connections in in the first place.  As georgeman mentioned, you have to have the rule anyway and it will only apply to WAN traffic.

    2. From what I've understood (as Derelict also mentioned), in order for traffic shaping to work and for the packets to be placed in the correct queue, the rule should be on the interface where the state is first created. Can anyone confirm this?

    Not exactly.  They have to be on an interface that is included in the initial state creation.  Like with the outbound FTP session example above, it will work with a floating rule on WAN out even though the session is actually initiated from LAN.  This way it will not impact ftp sessions from, say, LAN to DMZ which you probably want to shape differently if at all.

    3. When we create and define the queues in "Firewall->Traffic Shaper" in pfSense, queues created on the LAN interface shape downloads and queues created on the WAN interface shape uploads. Is this correct?

    You might be better off thinking in terms of flow direction.  The shaper shapes traffic going OUT the interface on which the queue is defined.  Someone outside could be "uploading" to your local FTP server on LAN, but that "upload" would be shaped by the queue on the LAN interface.

    Also remember that rules created on interface tabs only apply to states created coming IN that interface.  The only way to create rules to catch states being created going OUT an interface is with a floating rule.

    Thanks for any help.

    Hope I haven't misled you here.

    Someone please correct me if I made any mistakes.  I'm learning too.



  • @Derelict:

    I agree on pretty much everything mentioned here  ;)

    As regards the OpenVPN prioritization mentioned before, in fact I have never tried to do it on an OpenVPN site-to-site tunnel. I can tell that I don't think you can shape within the tunnel in case of (at least) roadwarrior connections since the packets are seen encrypted out of the WAN interface and the queue selections do not seem to be kept (on IPsec they are, but because it is hooked up to the kernel I guess).

    As soon as I can we can continue to elaborate on HFSC (since all this was more about the general shaper config)

    Cheers!



  • @georgeman:

    To keep this simple, always try that the sum of the linkshare values from the children queues sum up to the value of the parent queue. This is because HSFC uses a "sustractive" method for the percentages (I can elaborate of this later).

    Could you elaborate on this?  Your other information has helped me learn more about this.