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

    Traffic shaping not working in Beta 4 for outbound queues?

    Traffic Shaping
    10
    45
    21.4k
    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.
    • N
      nima.m
      last edited by

      Hoba,

      So If my router has a WAN/LAN and WLAN, and the WLAN is bridged to LAN, the traficc shaping dosn't work anymore, correct ?

      Is there anything the pfsense team can do to make Trafic Shaping work on multiple NIC that are bridged with LAN?

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

        That's something to do for 1.1 though there is no fixed featureset for 1.1 yet. If it's doable it will be implemented sooner or later.

        However if you are shaping WAN/LAN and your OPT1 is bridged to LAN there are chances that the shaping actually works. I think I heared someone report this scenario is working earlier, but not too sure about it. Try and let us know.

        1 Reply Last reply Reply Quote 0
        • D
          dvserg
          last edited by

          Can i have comment from professional to my questions?
          :)
          Bridge0 - logical interface .. but them can use for all rules in PF, yes?
          Can bridge0 use in ALTQ rules?
          May be this take effect for shaping (of cose if this possible)

          SquidGuardDoc EN  RU Tutorial
          Localization ru_PFSense

          1 Reply Last reply Reply Quote 0
          • N
            nima.m
            last edited by

            I suspect that the queue is working,
            The problem is the rules.

            In rules, you define "In Interface" and "Out Inferface", and what we miss here is the term for ANY
            This is tipical picture of configuration, if we only could choose
            In Interface = WAN
            Out Interface = ANY

            Then I think the problem would be solved.

            Untitled-1.gif
            Untitled-1.gif_thumb
            Untitled-1.gif_thumb

            1 Reply Last reply Reply Quote 0
            • D
              dvserg
              last edited by

              Thx.
              I today testing bridge queue rule with
              source * destination* - define only protocol and port.
              in simple model i give worked result. If time give possible - tomorrow be testing more big model.

              SquidGuardDoc EN  RU Tutorial
              Localization ru_PFSense

              1 Reply Last reply Reply Quote 0
              • B
                billm
                last edited by

                @nima.m:

                I suspect that the queue is working,
                The problem is the rules.

                In rules, you define "In Interface" and "Out Inferface", and what we miss here is the term for ANY
                This is tipical picture of configuration, if we only could choose
                In Interface = WAN
                Out Interface = ANY

                Then I think the problem would be solved.

                Sorta…too bad it's not quite that simple ;)

                --Bill

                pfSense core developer
                blog - http://www.ucsecurity.com/
                twitter - billmarquette

                1 Reply Last reply Reply Quote 0
                • N
                  nima.m
                  last edited by

                  Billm,

                  Dose pfsense and m0n0wall use the same Traffic Shaping Engine ?

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

                    No.  m0n0wall uses dummynet, we use ALTQ.

                    1 Reply Last reply Reply Quote 0
                    • N
                      nima.m
                      last edited by

                      Okay, The Traffic Shaper in both system look very similar.

                      However, they have solved the bridge problem very cleverly, in the LAN side anyway.
                      In m0n0wall, they only have one interface for rules, and the user can shape the rule for inboud/outbound based on the "direction"
                      So, If you have multiple NIC that are bridged with LAN, you can choose WAN as interface and "in" for direction for choosing "inbound" and "out" for direction for choosing "outbound"
                      So the Traffic Shaping dosn't need to look for both "In Interface" and "Out Interface".

                      However, pfsense need both "In Interface" and "Out Interface".

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

                        Yep completely different set of problems.  The rabbit whole gets EXTREMELY deep when you dive into ALTQ further.

                        1 Reply Last reply Reply Quote 0
                        • B
                          bruor
                          last edited by

                          i also had this bug,  noticed that i was getting drops on my voip phone, and that things were not going into the voip outbound queue,  i have run the cvs sync to releng_1 and will post results here in the next day or so.

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

                            @bruor:

                            i also had this bug,  noticed that i was getting drops on my voip phone, and that things were not going into the voip outbound queue,  i have run the cvs sync to releng_1 and will post results here in the next day or so.

                            You also need to rerun the traffic shaper wizard.

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