Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PRIQ Shaping Question - No limit on LAN, only limit WAN out

    Scheduled Pinned Locked Moved Traffic Shaping
    11 Posts 4 Posters 2.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tuffcalc
      last edited by

      Hey everyone,

      Trying to setup PRIQ as follows:

      LAN Priority
      None - I have a gigabit switch, so routing on my internal LAN doesn't need to be proritized

      WAN Priority
      I have a 30Mb/s download and 5Mb/s uplink.  I like to download from newsgroups (which saturates my download and makes browsing laggy).  I also have many VoIP phones in the home.  I would like my WAN management prioritized as follows:

      1. VoIP
      2. HTTP
      3. Everything else
      4. NTP/P2P

      I've used the traffic shaper but can't get my head around the following:

      A. Why are the exact same attributes added to both WAN and LAN shapers? (i.e., qVoip on the LAN and WAN side).  Shouldn't this only be needed on the WAN side?

      B. In the Firewall Floating Rules - I'm confused with two things - Ackqueue/Queue, which "Queue" is this referring to (WAN or LAN), and why would I ever need an AckQueue (and again, is it referring to the WAN or LAN attribute).

      C. Second question in the firewall rules, the traffic shaper wizard has only highlighted the "WAN" interface.  Underneath it says "choose on which interface packets must come in to match this rule".  In my VoIP scenario, isn't this counterintuitive? I'm worried about packets going TO the interface, not from it?

      Any help is appreciated.

      Thanks!!!

      1 Reply Last reply Reply Quote 0
      • H
        Harvy66
        last edited by

        A. Shaping only affects egress, not ingress. If you want to shape download data, you need to have queues on your LAN interface

        B. The queues are relative to the interface one which the rule is matching. What confuses me about floating rules is if they can match both ingress and egress, which floating rule wins when one rule matches on the ingress of one interface and another rule matches on the egress of the other interface. Can the queue change once set?

        C. not sure

        1 Reply Last reply Reply Quote 0
        • S
          sideout
          last edited by

          From my understanding if a floating rule creates a queue on the WAN interface it should apply that automatically to matching traffic going out on the LAN.

          I think I read that in a forum post on here somewhere.

          1 Reply Last reply Reply Quote 0
          • H
            Harvy66
            last edited by

            That's not my experience. I had it a few weeks back where my games were getting assigned to my games queue on my WAN, but the default queue on my LAN. I had to set the floating rule for both interfaces and set direction to Any before it put my games in both queues.

            The reason I could tell this is what was happening is because both queues were at 0, then I'd open a game, and my WAN queue would increment, but not my LAN queue. I assumed it was going to Default. I can't know for sure because there doesn't seem to be a way to see which queue a given state is assigned.

            At one point I was messing around and I got my games to go to qGames on WAN and qVoIP on LAN. Bah.. I haven't figured out floating yet.

            1 Reply Last reply Reply Quote 0
            • S
              sideout
              last edited by

              Hmm. it seems to put them in the right ones for me with HFSC by using direction ANY and interface WAN on my rules and I see both queues increment.

              I can test it again and see if that is still the case. I dont set queues for anything on the LAN side and let the floating rules handle it all.

              1 Reply Last reply Reply Quote 0
              • H
                Harvy66
                last edited by

                My issue might be that I have a catch all floating rules that apply to all traffic on both interfaces. Maybe it's matching on the LAN interface before reaching the WAN interface and causes my issues.

                I could see about setting all of my rules to the WAN and ignore the LAN. I really wish there was a manual with all of the cases for floating rules. I haven't found one yet.

                1 Reply Last reply Reply Quote 0
                • S
                  sideout
                  last edited by

                  Yea i dont have a catch all rule. I just let it go into the default queue because at the LAN parties that works for me.

                  1 Reply Last reply Reply Quote 0
                  • H
                    Harvy66
                    last edited by

                    I use catch all because TCP and UDP typically have different characteristics, so I like to break them into their own separate queues. I'll try just setting them to WAN and not LAN and see what happens. UDP is typically low bandwidth and latency sensitive and TCP is typically bulky.

                    1 Reply Last reply Reply Quote 0
                    • S
                      switchman
                      last edited by

                      @tuffcalc,

                      Give CoDel a try.  Apply it to both your LAN and WAN port.  Don't worry about the up/down speeds.  See if that doesn't help.

                      Save you current setup so you can re apply it if desired.

                      1 Reply Last reply Reply Quote 0
                      • T
                        tuffcalc
                        last edited by

                        @switchman:

                        @tuffcalc,

                        Give CoDel a try.  Apply it to both your LAN and WAN port.  Don't worry about the up/down speeds.  See if that doesn't help.

                        Save you current setup so you can re apply it if desired.

                        Thanks for the tip.  Really seems to work - and virtually no config (didn't even put in bandwidth settings)!  I wasted a day of my life setting up PRIQ for nothing :(

                        1 Reply Last reply Reply Quote 0
                        • S
                          switchman
                          last edited by

                          Glad it is working.  I am hoping that the developers will implement fg-codel.  That brings dynamic queue separation for the flows with codel working on each queue individually.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.