Navigation

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

    Limiter Design

    Traffic Shaping
    2
    2
    125
    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.
    • J
      james_h last edited by james_h

      I have a site with 4 LANs and 1 WAN with 30Mb x 8Mb VDSL.

      I have setup 2 floating match rules for WAN to share bandwidth evenly using an upload and download limiter with child queues and CoDel.

      This works great when testing with multiple devices even saturating the link but what this setup doesn't like is bursty type traffic generated by smart TV and set top boxes. This is affecting whatsapp video calls etc.

      Today I tried to add additional limiters to TV vlan to limit overall traffic to these TV and boxes. My question is will the traffic traverse these hard limits before hitting the floating match rules?

      Is there a better way to approach this?

      1 Reply Last reply Reply Quote 0
      • C
        chrcoluk last edited by chrcoluk

        I have moved over to using QFQ (which I believe is default selected in pfSense UI) for downstream combined with Codel on the child queue. (this seems to match HFSC performance on ALTQ).

        fq_codel works awesome for egress, but not so good for ingress on consumer broadband in my experience.

        What i did in limiter configuration.

        Pipe set the limit as documented, use droptail.
        Scheduler set to QFQ
        Queue set to Codel. Also on queue configure src-ip and src-ip6 masks, I used /16 for ipv4 and /56 for ipv6. I will probably change ipv6 to /48.

        The idea been I dont want a flow for each individual ip, so many would be created, instead to have traffic from same providers in their own flow, /16 will usually cause that, although it will be possible you may have 2 different providers at once in the same /16, in practice this seems rare though. As an example if I used /32 for flow separation and a steam download (32 threads) was competing with a twitch stream, then it would be 32/33 bandwidth allocated to steam and 1/33 allocated to twitch, with /16 it would be 50/50.

        Floating rules would be same as documentation. This still is not 100% for me but its working better for ingress than fq_codel. fq_codel I had to reduce flow limit's to 20 but that flooded my console with warnings and I still didnt have as good performance as QFQ.

        Also with this system the flows are visible in the diagnostics -> limiter screen whilst fq_codel hides its internal flows. So you can see which flows have packets dropped by the shaper, to determine how well things are working.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post

        Products

        • Platform Overview
        • TNSR
        • pfSense Plus
        • Appliances

        Services

        • Training
        • Professional Services

        Support

        • Subscription Plans
        • Contact Support
        • Product Lifecycle
        • Documentation

        News

        • Media Coverage
        • Press
        • Events

        Resources

        • Blog
        • FAQ
        • Find a Partner
        • Resource Library
        • Security Information

        Company

        • About Us
        • Careers
        • Partners
        • Contact Us
        • Legal
        Our Mission

        We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

        Subscribe to our Newsletter

        Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

        © 2021 Rubicon Communications, LLC | Privacy Policy