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

    First-time user (dumb) questions…

    Traffic Shaping
    3
    12
    2.9k
    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.
    • S
      stefano_noffke
      last edited by

      Greetings,

      I've installed the Traffic Shaper rules for the first time using the wizard, and I would like do understand what the wizard did since the documentation about this topic is a bit unclear…

      Here are the details of my installation:

      PfSense Version:
      2.1-RELEASE (i386)
      built on Wed Sep 11 18:16:50 EDT 2013
      FreeBSD 8.3-RELEASE-p11

      Network Layout:
      1 WAN (4 Mbps Down / 4 Mbps Up nominal, about 3,4 Mbps Down / 3,2 Mbps Up real measured with speedtest.net)
      4 LANs

      My first question is this: The Traffic Shaper queues only the traffic going over the WAN leaving the traffic between the LANS untouched, right? Considering that the firewall rules are only applied to the WAN interface it should be correct, but I just want to be sure :)

      My second question is this:
      I can not understand how the wizard configured the bandwidth shares among the queues…
      Here is how the various queues were configured:

      WAN (Bandwidth 3200 Kbps):

      • qACK (Bandwidth 19.804%, Priority 6, Link Share m2 19.804%)

      • qDefault (Bandwidth 9.902%, Priority 3, Default)

      • qP2P (Bandwidth 4.951%, Priority 1, UpperLimit 4.951%, Link Share m2 4.951%)

      • qVoIP (Bandwidth 32Kbps, Priority 7, Real Time 125Kbps)

      • qOthersHigh (Bandwidth 9.902%, Priority 4, Link Share m2 9.902%)

      • qOthersLow (Bandwidth 4.951%, Priority 2, Link Share m2 4.951%)

      LANs (Bandwidth nothing set, same configuration for all interfaces)

      • qLink (Bandwidth 20%, Priority 2)

      • qInternet (Bandwidth 3400Kbps, UpperLimit 3400 Kbps, Link Share m2 3400 Kbps)

        • qACK (Bandwidth 19.264%, Priority 6, Link Share m2 19.264%)

        • qDefault (Bandwidth 9.902%, Priority 3, Default)

        • qP2P (Bandwidth 4.816%, Priority 1, UpperLimit 4.816%, Link Share m2 4.816%)

        • qVoIP (Bandwidth 32Kbps, Priority 7, Real Time 125Kbps)

        • qOthersHigh (Bandwidth 9.632%, Priority 4, Link Share m2 9.632%)

        • qOthersLow (Bandwidth 4.816%, Priority 2, Link Share m2 4.816%)

      Why is the 3400 Kbps limit is set in the qInternet queue and not ant the interface level as it is for the WAN interface? Does it means that it is a "100%" default value? If so, why not 25% considering there are four LANs?
      Why the sum of the bandwidth allocation to the child queues does not add up to 100% but to some seemingly random value (38.528%)?

      I do not see the logic behind those bandwidth assignment…

      One last question: If a queue reaches its allowed bandwidth (let's say 20% set on Link Share m2); does it borrow the excess request bandwidth from the parent if available?

      Thank you!

      Stefano

      1 Reply Last reply Reply Quote 0
      • G
        georgeman
        last edited by

        First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

        Then:

        • Remember you can only shape out of an interface. You cannot shape in because you don't have control over what comes on the wire from outside. Once it reaches the interface there's not much you can do about it.
        • So, download is shaped out of LAN, and upload out of WAN.
        • Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit
        • If the 3400 Kb limit was set on LAN, it would limit the interface speed to that, limiting also traffic between LANs. That's why it is set on qInternet instead
        • The sum of linkshare values does not need to sum up 100%, it is just a proportional value against the total sum. For example having 3 queues set as 10%/10%/20% will be the same as having them as 25%/25%/50% (I don't know why the wizards sets it up that way anyway, has to do with the way it calculates)
        • Linkshare is not the allowed bandwidth, it is just the proportion of bandwidth it will get if all queues are requesting bandwidth at the same time. If no other queues are using bandwidth, it will use 100% (unless you cap it with upperlimit)

        Regards!

        If it ain't broke, you haven't tampered enough with it

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

          @georgeman:

          First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

          So, if I understand correctly, pfSense can shape correctly the download traffic on multiple LANs only if you want to split the available download bandwidth separately for each LAN. For example, if you have a total bandwidth of 20 Mbps and three LANs, and you want to assign 10 Mbps to the first LAN, 7 Mbps to the second, and 3 Mbps to the third.
          Otherwise, if you need to have the full 20 Mbps to all three LANs, you must assign 20 Mbps to each LAN; this would sum up to 60 Mbps, which is more than you have available. Therefore, pfSense can not handle this traffic correctly.

          Is this correct?

          @georgeman:

          Then:

          • Remember you can only shape out of an interface. You cannot shape in because you don't have control over what comes on the wire from outside. Once it reaches the interface there's not much you can do about it.
          • So, download is shaped out of LAN, and upload out of WAN.

          Clear

          @georgeman:

          • Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit

          I need some clarifications here…
          I assumed the traffic between LANs was not shaped because the only firewall rules created were assigned to the WAN interface.
          According to what you say, ALL traffic is shaped no matter what the rules are applied to the firewall. So, since there are no rules on the LANs, the default queue is applied to all traffic going out those interfaces.
          The default queue is qLink, which is set to have a "20%" of unlimited (not set?) bandwidth; therefore, I suppose that the traffic will be shared equally between users.

          Is this correct?

          However, I do not understand how the queue "qInternet" works (And I know that it works since I see the activity on the queue status page) since there are no rules applied to the Firewall on the LAN interfaces. All the "Floating" rules created by the wizard are applied to the WAN interface.

          How is the traffic assigned to the correct queues?

          @georgeman:

          • If the 3400 Kb limit was set on LAN, it would limit the interface speed to that, limiting also traffic between LANs. That's why it is set on qInternet instead

          It makes sense :)

          @georgeman:

          • The sum of linkshare values does not need to sum up 100%, it is just a proportional value against the total sum. For example having 3 queues set as 10%/10%/20% will be the same as having them as 25%/25%/50% (I don't know why the wizards sets it up that way anyway, has to do with the way it calculates)
          • Linkshare is not the allowed bandwidth, it is just the proportion of bandwidth it will get if all queues are requesting bandwidth at the same time. If no other queues are using bandwidth, it will use 100% (unless you cap it with upperlimit)

          Regards!

          It is clear now; Those values were confusing me because they were so specific that I thought they meant more than a simple proportion.

          Thank you very much!

          Stefano

          1 Reply Last reply Reply Quote 0
          • G
            georgeman
            last edited by

            @stefano_noffke:

            @georgeman:

            First things first, I believe this REALLY this to be cleared out somewhere, but the shaper in its current form won't properly handle shaping download on multi-LAN, no matter if the wizards pretends to configure it. The reason is that you cannot have a queue that applies to multiple interfaces at the same time.

            So, if I understand correctly, pfSense can shape correctly the download traffic on multiple LANs only if you want to split the available download bandwidth separately for each LAN. For example, if you have a total bandwidth of 20 Mbps and three LANs, and you want to assign 10 Mbps to the first LAN, 7 Mbps to the second, and 3 Mbps to the third.
            Otherwise, if you need to have the full 20 Mbps to all three LANs, you must assign 20 Mbps to each LAN; this would sum up to 60 Mbps, which is more than you have available. Therefore, pfSense can not handle this traffic correctly.

            Is this correct?

            Exactly :)

            @stefano_noffke:

            @georgeman:

            • Traffic between LAN interfaces is shaped, but assigned by default to the qLink queue which has pretty much no limit

            I need some clarifications here…
            I assumed the traffic between LANs was not shaped because the only firewall rules created were assigned to the WAN interface.
            According to what you say, ALL traffic is shaped no matter what the rules are applied to the firewall. So, since there are no rules on the LANs, the default queue is applied to all traffic going out those interfaces.
            The default queue is qLink, which is set to have a "20%" of unlimited (not set?) bandwidth; therefore, I suppose that the traffic will be shared equally between users.

            Is this correct?

            However, I do not understand how the queue "qInternet" works (And I know that it works since I see the activity on the queue status page) since there are no rules applied to the Firewall on the LAN interfaces. All the "Floating" rules created by the wizard are applied to the WAN interface.

            How is the traffic assigned to the correct queues?

            Great question! The queue assignment is based on the firewall states. When a packet goes out of WAN, that state is marked as belonging to the queue. When the response comes back in, before the package goes out of LAN the system applies the queue on LAN that has the same name as the queue that was originally assigned out of WAN (unless there is a explicit queue defined on LAN). This is why the queues on LAN and WAN have the same names, otherwise it wouldn't work this way and you would need to separately identify and match incoming and outgoing traffic.

            The same applies the other way around ,you could queue traffic on your LAN rules (in), instead of floating. In some cases there's no other option, for example if you want to shape based on the source IP and you are doing NAT. If you are doing NAT, out of WAN the packets have already been translated so you cannot queue based on the source IP. You would need to do it on LAN instead

            Side note: if there is a queueing rule on both LAN (in) and WAN (out), the one on LAN is the one that will ultimately apply for shaping download

            I am really glad you seem to have understood it!

            Regards!

            If it ain't broke, you haven't tampered enough with it

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

              Thank you very much, everything is much clearer now :)

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

                I have one other question (for now) :)

                In the Firewall Floating Rules, I see some rules have two queue selected (The qAck queue plus one other), while other queues have only one queue selected.

                Why?

                If I want to create a new rule, how do I choose to apply it to both the Acknowledge queue and another queue or just the other queue?

                Thank you!

                Stefano

                1 Reply Last reply Reply Quote 0
                • G
                  georgeman
                  last edited by

                  The Acknowledge queue will catch the SYN and ACK packets, so it is actually a good idea to have it select only for TCP protocol rules

                  If it ain't broke, you haven't tampered enough with it

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

                    @georgeman:

                    The Acknowledge queue will catch the SYN and ACK packets, so it is actually a good idea to have it select only for TCP protocol rules

                    Thank you.

                    Let me add yet another question :)

                    When I ran the wizard, I chose fot the VoIP the "Generic" setting. Now, I wanted to fine tune the shaper for our VoIP.

                    I checked the firewall rules, and I found out that the rule assigning the traffic to the VoIP queue was a generic "Assign all UDP traffic to the VoIP queue". Something like:
                    Proto: IPv4 UDP
                    Source: *
                    Port: *
                    Destination: *
                    Port: *
                    Gateway: *
                    Queue: qVoIP

                    Not the best setting I think…

                    I changed that rule to actually two different rules: (Note: we are using an external service provider to handle our VoIP calls. Let's call it "sip.voip.org" at the address "1.2.3.4")
                    FIRST: (Outgoing UDP traffic (RTP) to our VoIP service Provider)
                    Proto: IPv4 UDP
                    Source: *
                    Port: *
                    Destination: 1.2.3.4
                    Port: 10000-20000
                    Gateway: *
                    Queue: qVoIP

                    SECOND: (Outgoing TCP/UDP SIP Traffic (port 5060))
                    Proto: IPv4 UDP
                    Source: *
                    Port: *
                    Destination: 1.2.3.4
                    Port: 5060 (SIP)
                    Gateway: *
                    Queue: qACK/qVoIP

                    Is this a correct configuration? Did I understand it right?

                    Thank you.

                    1 Reply Last reply Reply Quote 0
                    • G
                      georgeman
                      last edited by

                      Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

                      If it ain't broke, you haven't tampered enough with it

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

                        @georgeman:

                        Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

                        The second rule is actually "TCP/UDP", my mistake…

                        1 Reply Last reply Reply Quote 0
                        • G
                          GomezAddams
                          last edited by

                          @georgeman:

                          Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

                          What does selecting an ack queue do for UDP traffic (since UDP doesn't have acks)?

                          1 Reply Last reply Reply Quote 0
                          • G
                            georgeman
                            last edited by

                            @GomezAddams:

                            @georgeman:

                            Sounds good. Anyway on the second rule you said "proto UDP", so I wouldn't select an acknowledge queue (unless you know what you are doing)

                            What does selecting an ack queue do for UDP traffic (since UDP doesn't have acks)?

                            Not really sure. What I can tell you is that some traffic might be catched, depending on the packet flags I guess. To make sure everything works the way I want, I prefer to create two rules: one with acknowledge queue for TCP, and one without for UDP

                            If it ain't broke, you haven't tampered enough with it

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