cancel
Showing results for 
Search instead for 
Did you mean: 

Web Gateway: Understanding and Configuring Bandwidth Control

Introduction

With the release of 7.6.2, MWG’s ability to control bandwidth has been greatly enhanced.  MWG now includes a classful means to control your company’s bandwidth. Traffic can now be categorized (not in the URL sense) into different classes and prioritized accordingly. This is different from the 7.1.5 feature called Bandwidth Throttling (White paper: MWG Bandwidth Throttling ). 7.7.0 adds support for transparent and proxyHA modes (See: Defining applicable Network Interfaces).

 

What value does Bandwidth Control add?

Often organizations (small or big) might not have a means to intelligently control bandwidth. Your web policy is the ideal egress point to make decisions based on user/group/ip/category/application. By managing the network traffic bandwidth in this manner, the following can be achieved:

  • Provide guaranteed minimum bandwidth rate to certain traffic classes.
  • Restrict the bandwidth usage of certain traffic classes to a maximum limit.
  • Define priority within traffic classes to share the excess available bandwidth.

 

Bandwidth Control allows you to control data as it goes in and out of the MWG. The events available for Bandwidth Control are Bandwidth.FromClient (Upload - Client to MWG), Bandwidth.ToClient (Download - MWG to Client), Bandwidth.FromServer (Download - Server to MWG), Bandwidth.ToServer (Upload - MWG to Server). The directionality of the events can be found in the diagram below:

 

Nuts and Bolts (Concept)

A Bandwidth class can be identified by a name along with few parameters relevant to classify and control bandwidth. Bandwidth classes can be grouped together to form a class hierarchy (parent-child representation). A child class can have another class as its parent (the parent class should already exist). Each class must have the following parameters:

  • Minimum Bandwidth: Minimum amount of bandwidth guaranteed for the traffic in the class i.e the class receives at least the amount of bandwidth, if bandwidth is available.
  • Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in the class. It does not matter how much bandwidth is available, a class can never receive more bandwidth than its maximum.
  • Priority: When sharing excess bandwidth with classes in the same hierarchy, the class with the lower priority # gets the first opportunity to use excess bandwidth. For Eg,

If a class request less than allocated rate for a child, the excess will be offered to another child with the lowest priority # and so on.

    • If a minimum bandwidth is configured for a parent class, it must be greater than or equal to the sum of the minimum bandwidths of all its child classes.
    • The sum of the minimum bandwidth of all child classes should not exceed the maximum bandwidth defined for the parent class.
    • The sum of the minimum of the children classes would also match the minimum of parent class, so that the parent distribute the leftover bandwidth (maximum – minimum) among the children class.
    • This feature utilizes the native Linux Traffic Control as an underlying mechanism to implement bandwidth control.
    • HTB classful qdisc is used for granular control over traffic. HTB uses the concept of tokens and buckets. It also only enforces leaf classes’ configuration.

 

 

Setting your goals & Bandwidth Tree example

To start testing the waters with Bandwidth Control you’ll need to map out what you want to control and what experience you want users to have. In our bandwidth tree, only "leaf" classes can be used in the configuration, parent classes cannot be used. The leaf classes are noted in the diagram below with the leaf icon.

 

Here is some example goals:

  • Limit YouTube and the Streaming Media category to a Max bandwidth of 10,000 Kbit/s
  • Limit the category Social Networking to a Max bandwidth of 5,000 Kbit/s
  • Ensure that the YouTube category has priority over the Streaming Media class

 

 

 

Defining the Bandwidth Classes

Under Configuration > Bandwidth Control we must check the box for "Enable Bandwidth Control". Once Bandwidth Control is enabled, we must define the classes we defined in our goals. IMPORTANT: The definitions must be created on each proxy you wish to utilize Bandwidth Control.

  • Define a Root class with a max and min bandwidth of 20,000 Kbit/s, the priority is 0 because there is no other competing bandwidth classes.
  • Define two child classes under Root called Streaming and Social Networking
    • Streaming – Max = 10000, Min = 5000, Priority = 0
    • Social Networking – Max = 5000, Min 2500, Priority = 0
  • Define two child classes under Streaming called YouTube and Streaming Media
    • YouTube – Max = 10000, Min = 3500, Priority = 50
    • Streaming Media – Max = 5000, Min = 1500, Priority = 75

 

The resulting class definitions should appear as you see in the screenshot below:

 

 

Define applicable network interfaces

Again under Configuration > Bandwidth Control we must specify the network interfaces which will impose bandwidth controls. To do this we click add, then select the interface we wish to use. For Explicit Proxy, ProxyHA, transparent router, and WCCP, simply specify the interface you wish to control. Depending on the interface configuration for ProxyHA you might need to specify multiple interfaces on the active director or redundant director node (anything with directory priority higher than 0).

 

 

Bridge mode

For bridge mode we need to specify the interfaces differently because of the bridge interface on the active proxy.

    • On the active or redundant director nodes (director priority greater than 0), specify the inbound and possibly the outbound interface.

    • On the scanning nodes (director priority set to 0), specify the interface for which traffic is received from the director on.

 

 

 

Example Ruleset

To use the Bandwidth classes, we must use the Bandwidth.(FromClient|ToClient|FromServer|ToServer) events in the rule configuration. Bandwidth Control events are last match wins, meaning the last rule which applies Bandwidth Control is the class that is applied. IMPORTANT: In our example this is important because YouTube is a subset of Streaming Media, so to prioritize YouTube separately from Streaming Media, we need to adjust the rule accordingly.

 

>>> Ruleset Download <<<

 

  1. Bandwidth Control: YouTube - This rule is first because YouTube is also categorized as Streaming Media. We want to exit the ruleset as soon as we detect the user is accessing YouTube.
  2. Bandwidth Control: Streaming Media - This rule is second to act as a catch all, higher prioritized exceptions (like YouTube) should be placed above this rule.
  3. Bandwidth Control: Social Media - This rule is last because there should not be high likelihood of overlap with the rules above it.

 

 

Note for Testing

When testing new rules, it's always best to use a test proxy, or scope the rules to apply to only yourself. If you do not have a test proxy available, just add criteria to the ruleset which causes the rules to only apply to your or test users (i.e. Client.IP is in range list [List of test Clients]).

 

 

 

Placement of Rules

For optimal functioning of the Bandwidth Control rules it is best to apply Bandwidth as early as possible. Apply Bandwidth Control too late or applying it incorrectly will likely yield erroneous results. In our example we are only controlling the bandwidth between the MWG and the internet (as this is the most desired example).

 

To apply Bandwidth Control as early as possible, rules should be placed towards the top of your rules. See screenshot below for example placement.

 

 

Correct/Incorrect Uses

Examples of correct uses:

    • For Uploads (FromClient|ToServer) or Downloads (ToClient|FromServer), in Request Cycle based on: Application Name, URL Category, URL, User-Agent, Client IP, Username, Usergroup, or anything which the MWG knows about in the request cycle.

Examples of incorrect uses:

    • For Downloads (FromServer), in Response Cycle based on Ensured Media Type (different from File Extension). To determine the Media Type MWG must have the file (or at least part of it). MWG cannot apply Bandwidth Control based on information it doesnt have.

 

 

Troubleshooting

The underlying mechanism used for Bandwidth Control is tc (traffic control). Various commands can be run from the console to visual the structure of your classes and also determine if the class is being matched correctly. Primarily though rule tracing should be used to understand if the rule matched correctly.

 

Verify configuration

less /etc/sysconfig/bandwidth

 

Visualize classes

tc -g class show dev ifb0

 

# Example output:

+---(1:1) htb rate 10Gbit ceil 10Gbit burst 0b cburst 0b

     +---(1:2) htb rate 1Kbit ceil 20Mbit burst 1600b cburst 1600b

          +---(1:3) htb rate 5Mbit ceil 10Mbit burst 1600b cburst 1600b

          |    +---(1:4) htb prio 7 rate 3500Kbit ceil 10Mbit burst 1599b cburst 1600b

          |    +---(1:5) htb prio 7 rate 1500Kbit ceil 5Mbit burst 1599b cburst 1600b

          |

          +---(1:6) htb prio 1 rate 2500Kbit ceil 5Mbit burst 1600b cburst 1600b

 

Monitor class usage (real-time)

watch -d tc -s -d class show dev ifb0

 

# Example output:

class htb 1:1 root rate 10Gbit ceil 10Gbit linklayer ethernet burst 0b/1 mpu 0b overhead 0b cburst 0b/1 mpu 0b overhead 0b level 7

Sent 74723335 bytes 51203 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 5495 borrowed: 0 giants: 0

tokens: 14 ctokens: 14

 

 

class htb 1:2 parent 1:1 rate 1Kbit ceil 20Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 6

Sent 74723335 bytes 51203 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 5495 giants: 0

tokens: -85914057 ctokens: 9587

 

 

class htb 1:3 parent 1:2 rate 5Mbit ceil 10Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 5

Sent 74723335 bytes 51203 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 28577 borrowed: 5495 giants: 0

tokens: 38350 ctokens: 19175

 

 

class htb 1:4 parent 1:3 prio 7 quantum 43750 rate 3500Kbit ceil 10Mbit linklayer ethernet burst 1599b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 16378282 bytes 11888 pkt (dropped 151, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 4858 borrowed: 7030 giants: 0

tokens: 54782 ctokens: 19175

 

 

class htb 1:5 parent 1:3 prio 7 quantum 18750 rate 1500Kbit ceil 5Mbit linklayer ethernet burst 1599b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 58345053 bytes 39315 pkt (dropped 506, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 12273 borrowed: 27042 giants: 0

tokens: 68494 ctokens: 20550

 

 

class htb 1:6 parent 1:2 prio 1 quantum 31250 rate 2500Kbit ceil 5Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 80000 ctokens: 40000

 

 

Conclusion

By the end of this best practice, you should have tested the waters with Bandwidth Control. If you have any use cases you would like more information on, please drop a comment below.

Labels (1)
Attachments
Comments

Looking forward for the trasparent implementation guide.

Jon,

  Great news ! The ability to limit bandwidth (not just on a per-connection basis) was a feature I particularly missed in MWG. Following the instructions in your article I was able to use it and found it very effective. Thanks !

  Just a couple of questions:

  1) I see that the "fw" filter is used in conjunction with "htb" classes.

 

  I could not see any iptables rules pointing to the "MARK" target and so I'm curious: how are the packets being marked ?

 

  2) The documentation says (in the "Nuts and Bolts" section) that classes with higher priority numeric values are served first when there is excess bandwidth. However, the documentation for "tc" says otherwise.

  From "man tc-htb":

 

  """

  prio priority

 

              In the round-robin process, classes with the lowest priority field are tried for packets first. Mandatory.       

  """

 

  I see that commands in "/etc/sysconfig/bandwidth" use the exact number typed in the UI when configuring the priority of each bandwidth class.

 

  Maybe the documentation should be amended ?

   

  Regards,

  Sergio

Hi Sergio,

Seeing your comments now, I pinged development about this, will keep you posted.

Best Regards,

Jon

Hey again Sergio,

I spoke with development and I'm clarifying something further about marking packets.

You are right that lower priority has higher precedence. I'll update that in the guide.

Best Regards,

Jon

Hello,

When using Bandwidth.ToServer, is the Maximum Bandwidth value set for every connections?

For example I use 100 kbps maximum Bandwidth to control the streaming media from the youtube. Is it share this bandwith between two users (50 - 50 percent) or both of them got the 100 kbps bandwith independently from each other?

Thanks!

Regards,

Zoltan

Hey Zoltan,

The bandwidth control outlined above is classful, meaning users connections of a certain class would battle for the bandwidth allotted (50/50). I'm not sure that its 50/50 exactly, it could vary.

The old event "Throttle.FromServer" was not classful, as such each connection could be restricted individually.


Best Regards,Jon

Hello Jon,

Thanks for the answare!

Best Regards,

Zoltan


Hi Jon,

I have been waiting for the 7.6.2.2 release as I was looking to implement the Bandwidth Control Ruleset, however just spotted the...

IMPORTANT: The first release of classful Bandwidth Control only applies to Direct Proxy mode (no ProxyHA), ProxyHA and transparent modes are planned for future releases.

Do you have an idea of what release and when ProxyHA will be supported with this rule please?

Hi Rugmeister,

You'll have to wait until 7.7.0 is released... which is today.

This bring support for transparent and proxyHA modes. It will take some time for me to get the guide updated, but a lot of the concepts are the same.

Best Regards,

Jon

Does "transparent" also include WCCP?

or only Transparent Route/Bridge modes?

All of the above! Bridge/Router/ProxyHA/WCCP


Hi Jon,

I have been waiting for the 7.7.x.x release so I can incorporate the classful Bandwidth control in Proxy HA made. Glad to see that has been released.

I noticed this on the page: "Current SaaS: 7.6.2.4 (highest version supported for sync)"

Does this mean 7.7.0 won't support Hybrid configurations or just that SaaS is not supported as yet for this version?

thanks

Hi Rugmeister,

SaaS needs to have a newer version than on-premise in order for sync to be possible.

Currently SaaS has 7.6.2.4, so a 7.7 on-premise node would not be able to sync with SaaS.

There is typically a two-three week period delay from when a release comes out and SaaS gets that new version.

Best Regards,

Jon

Hi Jon,

Is there an update on the new SaaS version to enable on premise nodes to sync with SaaS?

thanks

Gavin

Hi Jon,

thank you for this article. It was very helpful for me.

I have some questions:

1. In most cases it seems to be the best way to place the rules only in the request cycle und this is enough for the response cycle, too. Is this correct?

2. Please tell me if I am right:

If I have two appliances with central management I have to define the bandwidth classes on each appliance.

In your example I would limit 5000 Kbit/s at the first appliance and additional 5000 Kbit/s at the second appliance for Social Networking.

Each limit is only for the local appliance? Therefore I would have a maximum bandwidth 10000 Kbit/s with both appliances?

I then could even set different bandwidth limits for the same class on each appliance.

So with the same rule I would have different bandwidth limits depending on the local class configuration.

3. If this is true is there a possibility to set a global bandwidth limit for several appliances with central management?

4. If I want to set a global limit for the Internet bandwidth of an appliance for all traffic, could I define a bandwidth class "Root"

and then add a rule which is always used for each request (only in the request cycle). This rule would use the events

Bandwidth.FromServer("Root") and Bandwidth.ToServer("Root"). Is this possible?

Do uploads and downloads share the "Root" bandwidth in this case?

thanks

tux

Hi Rugmeister,

Is this question related to Bandwidth control or just a general question?

As of today SaaS is compatible with 7.7. I was a little bit slow in updating the Release notes page:

Best Regards,
Jon

Hi Klaus!

Thank you for these questions!

#1, I'm not quite sure what the questions is here, but in general applying in the request cycle is going to be the most effective. Applying bandwidth control in the response cycle can work, but results may vary depending on how you're doing it.

#2. You're correct, each appliance would have their own classes defined and how you use them in the rules is up to you. Each class/limit is only for the local appliance.

#3 At the moment there is not, the cluster does not share the currently consumed bandwidth with each other in real time so there is no chance to have a "globally" shared bandwidth class.

#4 If you're using "Root" in the same manner that I have above, it will not work. "Root" in the examples is not a "leaf" class and therefore will not work as expected. Only leaf classes can be used -- from the example, those would be YouTube, Streaming Media, and Social Networking.

If you created a leaf class using the same idea, I dont think there should be an issue sharing the class for uploads and downloads.

Best Regards,

Jon

Hi Jon,

thank you very much for your fast answer.

For a global limitation I think it would be the best to define a "Root" class as parent class and one leaf class for uploads "Up" and another leaf class for downloads "Down".

In this case I could limit the global bandwidth for uploads and downloads together in the "Root" class and then add a rule for uploads using the event

Bandwidth.ToServer("Up") and another rule for downloads using the event Bandwidth.FromServer("Down").

Does that make sense?

Best Regards,

Klaus

Hi Klaus,

That makes sense and should work, its probably a good idea to have separate ones in case you wanted to change them depending on the location.

Best Regards,

Jon

Hi Jon,

while testing this new and helpful feature I have another question.

Is it also possible to limit the bandwidth per client in addition to the limits in your example?

I could create a leaf class "Client" and define a bandwidth value for the clients, but I have no

idea for a rule to do this. Alle the traffic of a single Client should be limited to a maximum bandwidth.

Best Regards,

Klaus

Hi Jon,

I need to set up Bandwidth control in a Proxy HA configuration. Are there any release notes or guides for this yet please? or does it work in the same way as this guide?

"7.7.0 adds support for transparent and proxyHA modes (not covered in this guide yet)."

thanks

Gavin

Hi Klaus,

At the moment this would not be possible

Bandwidth classes are static, the example you gave is a more dynamic example.

Best Regards,

Jon

Hi Gavin,

I had added the 7.7 info, but forgot to remove that comment. Will update the guide, the setup is the same for proxyHA as it is for explicit proxy.

Best Regards,

Jon

Hi;

my UI version 7.6..2.5.0

It's not working on my servers , please help

I don't know what I'm doing wrong?

watch -d tc -s -d class show dev eth0

class htb 1:1 root rate 1Gbit ceil 1Gbit linklayer ethernet burst 1375b/1 mpu 0b overhead 0b cburst 1375b/1 mpu 0b overhead 0b level 7

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 187 ctokens: 187

class htb 1:2 parent 1:1 rate 1Kbit ceil 20Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 6

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 10000

class htb 1:3 parent 1:2 rate 1Kbit ceil 20Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 5

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 10000

class htb 1:4 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 2Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 100000

class htb 1:5 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 14Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1597b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 14281

class htb 1:6 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 4Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 50000

McAfee BC.PNG

McAfee BC2.PNG

Hi;

After restart MWG and change interface - it looks like it works

watch -d tc -s -d class show dev ifb0

class htb 1:1 root rate 10Gbit ceil 10Gbit linklayer ethernet burst 0b/1 mpu 0b overhead 0b cburst 0b/1 mpu 0b overhead 0b level 7

Sent 1960669117 bytes 1476788 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 917929 borrowed: 0 giants: 0

tokens: 5 ctokens: 5

class htb 1:2 parent 1:1 rate 1Kbit ceil 20Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 6

Sent 1960668517 bytes 1476778 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 917919 giants: 0

tokens: -883627981 ctokens: -2061

class htb 1:3 parent 1:2 rate 1Kbit ceil 20Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 5

Sent 1959862659 bytes 1475879 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 917755 giants: 0

tokens: -883627981 ctokens: -2061

class htb 1:4 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 2Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 229255370 bytes 209045 pkt (dropped 7852, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 113 borrowed: 129098 giants: 0

tokens: -544327052 ctokens: -174333

class htb 1:5 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 14Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1597b/1 mpu 0b overhead 0b level 0

Sent 1650257345 bytes 1194334 pkt (dropped 5259, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 363 borrowed: 733458 giants: 0

tokens: -37575005 ctokens: 9941

class htb 1:6 parent 1:3 prio 7 quantum 1000 rate 1Kbit ceil 4Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 80349944 bytes 72500 pkt (dropped 1004, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 816 borrowed: 55199 giants: 0

tokens: -102993022 ctokens: -16311

class htb 1:7 parent 1:2 prio 1 quantum 62500 rate 5Mbit ceil 10Mbit linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu 0b overhead 0b level 0

Sent 805858 bytes 899 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 681 borrowed: 164 giants: 0

tokens: 38350 ctokens: 19175

Great write up Jon.

I'm currently testing it out to see how I can police bandwidth for locations that are allowed access to Youtube et al. I've seen where setting a 500kbps ceiling does work for YT but it seems other services like Twitch (I look for Twitch via its application and URL) just disregards the ceiling. I'll have to keep poking around a bit.

BWControl_YT.JPGBWControl_TW.JPG

Hello all

I got a problem. (7.6.2.13.0 version)
I've created class to limit traffic and also created rule in policy, but it seems like its not working. After checking in CLI i clearly see that somehow these classes dont work.
Please note that even if i created rule criteria "always", it still didnt work.
I've even restarted MWG process as one of comments suggested, but it didnt help.

1) classes

classes.png

2) rule in policy
policy.png
3) output of CLI

Every 2.0s: tc -s -d class show dev eth0                         Fri Aug 18 08:46:53 2017

class htb 1:1 root rate 1Gbit ceil 1Gbit linklayer ethernet burst 1375b/1 mpu 0b overhead

0b cburst 1375b/1 mpu 0b overhead 0b level 7

Sent 4844 bytes 56 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 56 borrowed: 0 giants: 0

tokens: 175 ctokens: 175

class htb 1:2 parent 1:1 rate 1Kbit ceil 30Mbit linklayer ethernet burst 1600b/1 mpu 0b o

verhead 0b cburst 1593b/1 mpu 0b overhead 0b level 6

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 6656

class htb 1:3 parent 1:2 prio 1 quantum 1000 rate 1Kbit ceil 1500Kbit linklayer ethernet

burst 1600b/1 mpu 0b overhead 0b cburst 1599b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 133328

--------

---------

Every 2.0s: tc -s -d class show dev eth1                         Fri Aug 18 08:47:01 2017

class htb 1:1 root rate 1Gbit ceil 1Gbit linklayer ethernet burst 1375b/1 mpu 0b overhead

0b cburst 1375b/1 mpu 0b overhead 0b level 7

Sent 11828 bytes 15 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 15 borrowed: 0 giants: 0

tokens: -145 ctokens: -145

class htb 1:2 parent 1:1 rate 1Kbit ceil 30Mbit linklayer ethernet burst 1600b/1 mpu 0b o

verhead 0b cburst 1593b/1 mpu 0b overhead 0b level 6

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 6656

class htb 1:3 parent 1:2 prio 1 quantum 1000 rate 1Kbit ceil 1500Kbit linklayer ethernet

burst 1600b/1 mpu 0b overhead 0b cburst 1599b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 133328

Every 2.0s: tc -s -d class show dev ifb0                         Fri Aug 18 09:39:32 2017

class htb 1:1 root rate 1Gbit ceil 1Gbit linklayer ethernet burst 1375b/1 mpu 0b overhead

0b cburst 1375b/1 mpu 0b overhead 0b level 7

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 187 ctokens: 187

class htb 1:2 parent 1:1 rate 1Kbit ceil 30Mbit linklayer ethernet burst 1600b/1 mpu 0b o

verhead 0b cburst 1593b/1 mpu 0b overhead 0b level 6

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 6656

class htb 1:3 parent 1:2 prio 7 quantum 1000 rate 1Kbit ceil 1500Kbit linklayer ethernet

burst 1600b/1 mpu 0b overhead 0b cburst 1599b/1 mpu 0b overhead 0b level 0

Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended: 0 borrowed: 0 giants: 0

tokens: 200000000 ctokens: 133328

Can we use this for limitation for all traffic?

How to limit for diff. branches?

Not only streams or categories.

Contributors
Version history
Revision #:
3 of 3
Last update:
‎03-20-2018 11:29 AM
Updated by: