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

    Avoid Datacenter bandwidth overages

    Scheduled Pinned Locked Moved Traffic Shaping
    8 Posts 5 Posters 1.4k 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.
    • A
      awsiemieniec
      last edited by

      I have a pfSense at a datacenter that I'm getting bandwidth overages from.  On the pfSense I have an OpenVPN site-to-site to our main office.  I have setup limiters on the various rules that I think are causing our bandwidth overages to stem from.  I have a quite a few rules and am looking to simplify the setup.

      Is there a generic way to say that on the WAN connection (includes IPSec and OpenVPN connections) never go above XXMbps?

      Thanks.

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

        Use HFSC, and set your default queue to have an UpperLimit. Then you can make match rules to move other traffic out of the default queue that you don't want in there.

        1 Reply Last reply Reply Quote 0
        • N
          Nullity
          last edited by

          I have no experience with OpenVPN, but encapsulation overhead could be your problem. Like, for OpenVPN to emulate a 10Mbit connection may require 12Mbit of bandwidth including OpenVPN's encapsulation overhead.

          So, I would think you would want to rate-limit after encapsulation, if such a thing is possible.

          Please correct any obvious misinformation in my posts.
          -Not a professional; an arrogant ignoramous.

          1 Reply Last reply Reply Quote 0
          • A
            awsiemieniec
            last edited by

            Thank you for showing me about the HFSC.  I read a bunch last night and implemented a "first try" at limiting bandwidth at 20Mbps at one of the datacenters.

            Here is a screen shot of the queues.  I'm concerned about the "Drops" column.  That normally ins't a good thing - to drop packets.  Can someone give me a little insight on what is happening here?

            Queues.PNG
            Queues.PNG_thumb

            1 Reply Last reply Reply Quote 0
            • KOMK
              KOM
              last edited by

              Packet drops aren't "bad", per se, as they are used by TCP to handle flow control.  Drops are normal and expected, especially when you re using traffic shaping.

              1 Reply Last reply Reply Quote 0
              • A
                awsiemieniec
                last edited by

                OK, thx.  I'll continue reading up on the subject.

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  You are trying to avoid overages.

                  That means you have to drop packets that will exceed your target.

                  If you have to drop too many then you need more bandwidth or need to move less data.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                    50 is the default. I recommend just enabling CoDel on each queue. Large buffers are bad because they cause bufferbloat, but they're great for high throughput(except in extreme cases, like more than 1,000ms of bloat).

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