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

    Shaping / Limiting Advice Needed

    Scheduled Pinned Locked Moved Traffic Shaping
    7 Posts 3 Posters 1.2k 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.
    • M
      mloiterman
      last edited by

      Background
      Multi-WAN and Multi-LAN

      • WAN1 - Comcast: 1,000 Mbs download x 40 Mbs upload

      • WAN2 - Uverse: 25 Mbs download x 2 Mbs upload

      • LAN1 - Primary LAN

      • LAN2 - VOIP LAN

      I primarily use the WAN1 connection and have designated WAN2 as a dedicated VoIP link and as a failover for WAN1.

      Issue:
      Although it's pretty rare, when my WAN1 connection goes down, I'm forced to use the WAN2 connection as my primary.

      In general, that works as it should in terms of the failover working and routing correctly.  But, because the WAN2 upload is so limited, a lot of latency is introduced.  I'm thinking this is because it can't keep up with all of the ACKs.  This makes the connection almost unusable.

      Objective

      • Reduce latency on WAN2 during heavy use.

      Questions

      • Should I use a limiter or a shaper to address this issue?

      • If I should use a shaper, which one?

      • If I should use a shaper, I think I would need to shape the WAN2 and LAN1 and LAN2, right?  How should I configure this?  Should I use a dedicated link or the Multi-Wan?  I really don't want to shape WAN1.

      Eager to hear everyone's thoughts.

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

        I would recommend using fq_Codel limiter per WAN interface. Other than the lack of UI to setup, it's very simple to use. Mostly just set your bandwidth.

        This long lived post should have all the info you need. https://forum.pfsense.org/index.php?topic=126637.0

        1 Reply Last reply Reply Quote 0
        • M
          mloiterman
          last edited by

          This long lived post should have all the info you need. https://forum.pfsense.org/index.php?topic=126637.0

          I saw that, and while I'm extremely comfortable on the command line, I'm reluctant to introduce those kinds of "non-standard" modifications on what I consider to be a production machine.  For now, I'd like to stick to the official tools provided by the GUI…even if they're not as good as fq_Codel.

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

            @mloiterman:

            This long lived post should have all the info you need. https://forum.pfsense.org/index.php?topic=126637.0

            I saw that, and while I'm extremely comfortable on the command line, I'm reluctant to introduce those kinds of "non-standard" modifications on what I consider to be a production machine.  For now, I'd like to stick to the official tools provided by the GUI…even if they're not as good as fq_Codel.

            The changes are actually pretty straightforward -  all you would have to do is configure Limiters and queues in the GUI and then issue one command from the command line to to apply fq_codel.  To make it persistent between reboots the Shellcmd package can be used.

            As an alternative to fq_codel you can try using the FAIRQ scheduler together with Codel applied to the queues instead.  All that can be configured in the GUI.  This should yield pretty similar performance to fq_codel.

            Hope this helps.

            1 Reply Last reply Reply Quote 0
            • M
              mloiterman
              last edited by

              @tman222:

              @mloiterman:

              This long lived post should have all the info you need. https://forum.pfsense.org/index.php?topic=126637.0

              I saw that, and while I'm extremely comfortable on the command line, I'm reluctant to introduce those kinds of "non-standard" modifications on what I consider to be a production machine.  For now, I'd like to stick to the official tools provided by the GUI…even if they're not as good as fq_Codel.

              The changes are actually pretty straightforward -  all you would have to do is configure Limiters and queues in the GUI and then issue one command from the command line to to apply fq_codel.  To make it persistent between reboots the Shellcmd package can be used.

              As an alternative to fq_codel you can try using the FAIRQ scheduler together with Codel applied to the queues instead.  All that can be configured in the GUI.  This should yield pretty similar performance to fq_codel.

              Hope this helps.

              Is there a FAQ or some additional details on how to set up what you're describing?  I'm not very proficient with traffic shaping and when I tried to setup what you described, essentially nothing was added.  Nothing shows when I do, for example:

              ipfw sched show
              
              1 Reply Last reply Reply Quote 0
              • M
                mloiterman
                last edited by

                Just giving this a bump, as I would like to deal with the latency resulting from lack of upload bandwidth on my very assymetric Uverse connection.

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

                  @mloiterman:

                  Just giving this a bump, as I would like to deal with the latency resulting from lack of upload bandwidth on my very assymetric Uverse connection.

                  I added some instructions how to setup fq_codel in a few steps in this thread:

                  https://forum.pfsense.org/index.php?topic=142321.msg776278#msg776278

                  Hope this helps, but please let us know if you have any additional questions.

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