Community discussions

 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Queues Rate limiting?

Fri Nov 20, 2015 9:23 pm

Hey all, I am not sure if I'm doing something wrong or my understanding is off, but I cannot get a Simple Queue to limit bandwidth at all. I have followed the Wiki, read others' tutorials but no matter what, it doesn't seem to work.

Rate limiting works spot on if I set it on the port itself but I'd like to limit traffic speeds/bandwidth for an entire network.

EDIT:
Here's my rule(s).

0 name="Full Speed" target="" parent=none packet-marks="" priority=8/8
queue=default-small/default-small limit-at=0/0 max-limit=0/0
burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

1 name="wasteland" target=192.168.13.99/32 parent=Full Speed packet-marks=""
priority=8/8 queue=default-small/default-small limit-at=0/0
max-limit=1M/1M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

Thanks!
 
User avatar
vixxant
newbie
Posts: 38
Joined: Thu Mar 17, 2011 7:36 pm
Contact:

Re: Queues Rate limiting?

Sat Nov 21, 2015 1:32 pm

Try setting up a max-limit
queue simple add name="Full Speed" target="0.0.0.0/0" parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=5M
/5M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Mon Nov 23, 2015 9:33 pm

Try setting up a max-limit
queue simple add name="Full Speed" target="0.0.0.0/0" parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=5M
/5M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s
If you look at my second rule named Wasteland, it shows a max-limit=1M/1M which targets a single IP address. This rule doesn't work either.
 
User avatar
vixxant
newbie
Posts: 38
Joined: Thu Mar 17, 2011 7:36 pm
Contact:

Re: Queues Rate limiting?

Tue Nov 24, 2015 3:42 am

Your second rules parent queue is set as the first queue .can you check by setting parent queue as none in the second rule . Check whether the queue accumulates traffic after setting it as none
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Tue Nov 24, 2015 5:41 pm

It does not accumulate traffic even after doing that. I originally only had one rule, the rate limiting, but some documentation stated you should have a parent rule which does not limit any traffic.

I did get the upload limiting to work though. The RouterOS documentation seems to be all over the place e.g. not updated, conflicting, non-existent.

Some documentation stated to simply create a simple queue and that was it. Other documentation stated you needed to mark the packets and then check for those marks in the simple queue. After marking the packets using Mangle for the prerouting chain, uploading speeds are limited by the queue.

I am unable to get correctly mark the packets and limit the download rate though.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 1743
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Queues Rate limiting?

Tue Nov 24, 2015 6:13 pm

taken from other vendor documentation and adapted to routeros terminology

this recommendations have worked well for me
Traffic Shaping Objectives

Traffic shaping operates by measuring and queuing IP packets with respect to a number of
configurable parameters. The objectives are:
• Applying bandwidth limits and queuing packets that exceed configured limits, then sending
them later when bandwidth demands are lower.
• Dropping packets if packet buffers are full. The packets to be dropped should be chosen from
those that are responsible for the congestion.
• Prioritizing traffic according to administrator decisions. If traffic with a high priority increases
while a communication line is full, traffic with a low priority can be temporarily limited to
make room for the higher priority traffic.
• Providing bandwidth guarantees. This is typically accomplished by treating a certain amount
of traffic (the guaranteed amount) as high priority. The traffic that is in excess of the
guarantee then has the same priority as other traffic, competing with all the other
non-prioritized traffic.
Traffic shaping does not typically work by queuing up immense amounts of data and then
sorting out the prioritized traffic to send before sending non-prioritized traffic. Instead, the
amount of prioritized traffic is measured and the non-prioritized traffic is limited dynamically so
that it will not interfere with the throughput of prioritized traffic.


Limits should not be more than the Available Bandwidth
If queue limits are set higher than the available bandwidth, the queue will not know when the
physical connection has reached its capacity. If the connection is 500 Kbps but the total queue
limit is set to 600 Kbps, the queue will believe that it is not full and it will not throttle lower
priorities.

Limits should be less than Available Bandwidth
queue limits should be below the network bandwidth. A recommended value is to make
the queue limit 80-90% of the physical limit. The need for this difference becomes less with increasing
bandwidth since represents an increasingly larger piece of the total.
The reason for the lower pipe limit is For outbound
connections where packets leave the router, there is always the possibility that
might slightly overload the connection because of the software delays involved in
deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed
by the traffic shaping system and it is therefore more important to set pipe limits slightly
below the real connection limit to account for the time needed for queuing to adapt to
changing conditions.

Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing
through that bottleneck passes through the defined queues.
If there is traffic going through the Internet connection that the queues do not know about,
queuing cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic
"leaking" through without being measured by pipes will have the same effect as bandwidth
consumed by parties outside of administrator control but sharing the same connection.
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Tue Nov 24, 2015 10:17 pm

taken from other vendor documentation and adapted to routeros terminology

this recommendations have worked well for me
Traffic Shaping Objectives

Traffic shaping operates by measuring and queuing IP packets with respect to a number of
configurable parameters. The objectives are:
• Applying bandwidth limits and queuing packets that exceed configured limits, then sending
them later when bandwidth demands are lower.
• Dropping packets if packet buffers are full. The packets to be dropped should be chosen from
those that are responsible for the congestion.
• Prioritizing traffic according to administrator decisions. If traffic with a high priority increases
while a communication line is full, traffic with a low priority can be temporarily limited to
make room for the higher priority traffic.
• Providing bandwidth guarantees. This is typically accomplished by treating a certain amount
of traffic (the guaranteed amount) as high priority. The traffic that is in excess of the
guarantee then has the same priority as other traffic, competing with all the other
non-prioritized traffic.
Traffic shaping does not typically work by queuing up immense amounts of data and then
sorting out the prioritized traffic to send before sending non-prioritized traffic. Instead, the
amount of prioritized traffic is measured and the non-prioritized traffic is limited dynamically so
that it will not interfere with the throughput of prioritized traffic.


Limits should not be more than the Available Bandwidth
If queue limits are set higher than the available bandwidth, the queue will not know when the
physical connection has reached its capacity. If the connection is 500 Kbps but the total queue
limit is set to 600 Kbps, the queue will believe that it is not full and it will not throttle lower
priorities.

Limits should be less than Available Bandwidth
queue limits should be below the network bandwidth. A recommended value is to make
the queue limit 80-90% of the physical limit. The need for this difference becomes less with increasing
bandwidth since represents an increasingly larger piece of the total.
The reason for the lower pipe limit is For outbound
connections where packets leave the router, there is always the possibility that
might slightly overload the connection because of the software delays involved in
deciding to send packets and the packets actually being dispatched from buffers.
For inbound connections, there is less control over what is arriving and what has to be processed
by the traffic shaping system and it is therefore more important to set pipe limits slightly
below the real connection limit to account for the time needed for queuing to adapt to
changing conditions.

Watching for Leaks
When setting out to protect and shape a network bottleneck, make sure that all traffic passing
through that bottleneck passes through the defined queues.
If there is traffic going through the Internet connection that the queues do not know about,
queuing cannot know when the Internet connection becomes full.
The problems resulting from leaks are exactly the same as in the cases described above. Traffic
"leaking" through without being measured by pipes will have the same effect as bandwidth
consumed by parties outside of administrator control but sharing the same connection.

Hmm...so I must have a leak then cause I can get upload to work through simple queue, marking packets and queue types but no matter what I cannot get download to work.

Can having two bridges cause packets to leak?
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Tue Nov 24, 2015 11:19 pm

While using Torch and setting the destination IP to an IP that's part of the Queue makes it work...
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Mon Nov 30, 2015 6:58 am

Well after running through all options/troubleshooting, I reset my configuration a few times, reconfigured manually and everything worked as stated in documentation...not sure what to attribute the issues to.
 
bsdbytes
just joined
Posts: 1
Joined: Thu Nov 26, 2015 3:57 am

Re: Queues Rate limiting?

Wed Dec 02, 2015 5:31 am

I was running into the same problem and researched all over trying to figure out why my queues weren't being applied. Finally figured out that I needed to disable the fastTrack connection forward rule in the firewall settings. This is enabled during initial setup, so it might be overlooked.
 
wxlsxn
just joined
Topic Author
Posts: 13
Joined: Wed Nov 04, 2015 8:13 am

Re: Queues Rate limiting?

Thu Dec 03, 2015 4:20 am

I was running into the same problem and researched all over trying to figure out why my queues weren't being applied. Finally figured out that I needed to disable the fastTrack connection forward rule in the firewall settings. This is enabled during initial setup, so it might be overlooked.
I think you're right because all my default Firewall/NAT rules that used to be in there were wiped out after resetting my config.

Who is online

Users browsing this forum: Google [Bot] and 31 guests