Hi Karl, If you're using a bridge, the IP should be assigned to the bridge interface, not to one of the members. That might be your issue. M ________________________________ From: Karl Auer <kauer@nullarbor.com.au> Sent: Saturday, 3 February 2018 2:31 pm To: MikroTik Australia Public List Subject: Re: [MT-AU Public] queue noob On Sat, 2018-02-03 at 13:43 +1100, Mike Everest wrote:
if the interface is configured as a bridge port, then define the bridge as the interface for queue not the physical port.
Thanks - but still no go. The bridge has three interfaces in it - ether2, wlan1, wlan2. ether3 and ether4 are slaved to ether2. ether5 has been split off as a management port, nothing on it for these tests. The network on the bridge (actually on ether2) is 192.168.100.0/24. The bridge settings are: use-ip-firewall: yes use-ip-firewall-for-vlan: no use-ip-firewall-for-pppoe: no allow-fast-path: yes bridge-fast-path-active: no bridge-fast-path-packets: 0 bridge-fast-path-bytes: 0 bridge-fast-forward-packets: 0 bridge-fast-forward-bytes: 0 My queue looks like this (formatting edits only): Flags: X - disabled, I - invalid, D - dynamic 0 name="test" target=bridge parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=10k/10k burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 With target=ether1, nothing moves. With target=bridge, the queue has no effect at all. With target=192.168.100.0/24, the queue seems to slow down interactive access to the router dramatically (leading to unfounded optimism), but a file transfer in Firefox scoots up to 100 kiloBYTES per second average over a 50 megabyte download. The thing is, without the queue the transfer happens at 1.2 megabytes per second, so clearly the queue is doing something! Just not remotely like what I am expecting. In desperation I set max-limit to 1000/1000 and things almost stopped :-) Interaction with the router CLI involved multi-minute delays. The browser was rendered unusable, so could not see whether the download was any slower. What am I missing? This seems like a totally simple thing to want, it must be a common requirement, how come it is so danged hard to achieve? "That link there - allow no more than X bps inbound and Y bps outbound". Regards, K.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Friday, 2 February 2018 11:21 PM To: MikroTik Public <public@talk.mikrotik.com.au> Subject: [MT-AU Public] queue noob
I bought an HAP ac lite, intending to use it as a throttle between a bunch of evil leeching wifi users and a client's tender defenseless Internet router. I have had a test unit (an older 951 unit) in there and used the bandwidth command on the relevant ethernet port. That worked a treat.
Turns out none of the interfaces on the HPA ac line support the set bandwidth command :-(
So I have turned to queues. I cannot figure them out. This command should IMHO limit the total bandwidth coming IN to ether1 to 1 megabit, and the total bandwidth for traffic LEAVING ether1 to 500 kilobits:
/queue simple add target=ether1 queue=ethernet-default/ethernet-default max- limit=500K/1M
But when I do that, nothing moves over ether1 (which is the link between the HAP and the Internet router).
So I deleted that queue and tried this (192.168.100.0/24 is the network containing the leeches - wlan1, wlan2, ether2/3/4 bridged):
/queue simple add target=192.168.100.0/24 queue=ethernet-default/ethernet-default max- limit=500K/1M
Traffic flows over ether1, but this in no way limits the bandwidth to anything like those values. If I use 10K/10K instead and then download a file in Firefox, I see the transfer rate start at 12KB/s (kilobytes per second) and creep steadily up to around 100KB/s by the time the whole 50MB file has been downloaded. That's in stark contrast to the 1 or 2 megabytes per second I get without the queue, so *something* is happening, it just doesn't seem very predictable. Ideas would be very welcome... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.c om.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com .au
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Sat, 2018-02-03 at 04:14 +0000, Michael Junek wrote:
If you're using a bridge, the IP should be assigned to the bridge interface, not to one of the members. That might be your issue.
Thanks. The IP address 192.168.100.1/24 is in fact assigned to the bridge. Sorry, my wording was poor. Is anyone on this list actually using a queue to limit bandwidth? Things are not helped by the Mikrotik documentation being out of date. It refers to several attributes of a simple queue that do not exist on my router (like "interface", "direction" and "dst-address"). The description in the doco is very clear (if apparently out of date): "Add a simple queue rule, which will limit the download traffic to 512kbps and upload to 256kbps for the network 10.1.1.0/24, served by the interface Ether2: [admin@MikroTik] /queue simple> add name=private \ target=10.1.1.0/24 \ max-limit=256K/512K \ interface=ether2 "In this case statement works right also if we indicate only one of parameters: "target=" or "interface=", because both of these define where and for which traffic this queue will be implemented." But my queue simply does not do what the doco says it should. Though it does have some effect. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
Hi Karl, All looks to be in order. In response to your question - yes, I am. I have a guest network which is limited to 2M/256k per user, with an aggregate of 8M/1M This gets switched to 512k/128k per user and 2M/512k aggregate once a pre-set download threshold is met. (A script does this, by disabling one simple queue, and enabling another) Below is my config. The per connection queueing is handled by the individual queue types, which are then bound in the simple queue which handles the aggregate. This is running on a CRS109-8G-1S-2HnD - with guest networks bring a pridge interface, containiung 5x tagged ethernet ports to various APs, and an SSID on the CRS itself. RouterOS version is 6.37.3 /queue type add kind=pcq name=Guest-2M-Downstream pcq-burst-time=1s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 add kind=pcq name=Guest-256k-Upstream pcq-burst-time=1s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=256k pcq-src-address6-mask=64 add kind=pcq name=Guest-128k-Upstream pcq-burst-time=1s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=128k pcq-src-address6-mask=64 add kind=pcq name=Guest-512k-Downstream pcq-burst-time=1s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=512k pcq-src-address6-mask=64 /queue simple add max-limit=1M/8M name=Guest-Normal-Speed queue=Guest-256k-Upstream/Guest-2M-Downstream target=172.19.124.128/26 add disabled=yes max-limit=512k/2M name=Guest-Limit-Speed queue=Guest-128k-Upstream/Guest-512k-Downstream target=172.19.124.128/26 I just went through the rest of the config on that device and I cant see anything else that would trigger the queue to work, other than the above. There is a Queue Tree associated to the NBN facing interface, but that's just to prioritorise the sending of packets from specific VLANs. M. ________________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Karl Auer <kauer@nullarbor.com.au> Sent: Saturday, 3 February 2018 16:21 To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] queue noob On Sat, 2018-02-03 at 04:14 +0000, Michael Junek wrote:
If you're using a bridge, the IP should be assigned to the bridge interface, not to one of the members. That might be your issue.
Thanks. The IP address 192.168.100.1/24 is in fact assigned to the bridge. Sorry, my wording was poor. Is anyone on this list actually using a queue to limit bandwidth? Things are not helped by the Mikrotik documentation being out of date. It refers to several attributes of a simple queue that do not exist on my router (like "interface", "direction" and "dst-address"). The description in the doco is very clear (if apparently out of date): "Add a simple queue rule, which will limit the download traffic to 512kbps and upload to 256kbps for the network 10.1.1.0/24, served by the interface Ether2: [admin@MikroTik] /queue simple> add name=private \ target=10.1.1.0/24 \ max-limit=256K/512K \ interface=ether2 "In this case statement works right also if we indicate only one of parameters: "target=" or "interface=", because both of these define where and for which traffic this queue will be implemented." But my queue simply does not do what the doco says it should. Though it does have some effect. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Sat, 2018-02-03 at 05:56 +0000, Michael Junek wrote:
All looks to be in order. In response to your question - yes, I am. I have a guest network which is limited to 2M/256k per user, with an aggregate of 8M/1M
I think you mean 1M/8M, and does this mean your setup puts an upper limit of 8 megabits per second on aggregated outbound traffic, and 1 megabyte per second on aggregated inbound traffic, whatever else it may do per user? Silly question I know - but have you ever tested this and seen conclusively that it does actually impose the limits you expect? If so, how accurately does it impose the limits? Would you expect the queue I described to put an absolute upper limit of 10K bits per second on the link - in total? I am starting to wonder if there are magic numbers, and some numbers are too small or too large and get rounded up or down behind the scenes. Maybe my problem is in specifying 10000/10000? I tried 128k/128k and saw transfer speeds of 1.7 megabytes per second. 64k/64k seemed to slow it a bit at first, but by the end of the transfer the average had still reached 1.2 megabytes per second. At 10000/10000 the average speeds were still well over 100 kilobytes per second. As I sy, it does seem to have an effect - just not much. I thought at one point that it might be packets, not bytes, but there is no way known that the packet rates are approaching 10K packets per second in either direction. Just as a sanity check I used "set bandwidth" on the router (an RB951G- 2HnD) at the other end of the link I am trying to control and it worked fine. With a bandwidth limit of 128k/128k, the test transfer was neatly limited to around 13 kilobytes per second, which is near enough. I think I might have to go back to Mike cap in hand and ask for a different router. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
Hi Karl, It's definitely all been tested and working - my father would have not appreciated guests at his property from pinching all the 25/5 NBN Wireless he's on :) Here is an output from the router - as you can see there are 2779/95078 packets dropped since the last reboot/clear. -- /queue simple print stats: Flags: X - disabled, I - invalid, D - dynamic 0 name="Guest-Normal-Speed" target=172.19.124.128/26 rate=0bps/0bps total-rate=0bps packet-rate=0/0 total-packet-rate=0 queued-bytes=0/0 total-queued-bytes=0 queued-packets=0/0 total-queued-packets=0 bytes=941499094/3745280196 total-bytes=0 packets=2888996/3353772 total-packets=0 dropped=2779/95078 total-dropped=0 pcq-queues=0/0 -- As for accuracy - it's pretty reasonable. A download starts slow to begin with as the rate is exceeded inititally, and then speeds up as the TCP window size is adjusted appropriately to the available bandwidth. If you use WinBox, you can tell what the queue is doing by watching it's icon - green means traffic rate is under the limit, and red means it's exceeding it. Yellow is within 80% (off memory) In regards to the configuration - it's definitely 8M towards the guest network (downstream), and 1M towards the internet (upstream). The numbers are specified backwards.
From the Mirkotik Howto: -- The max-limit parameter cuts down the maximum available bandwidth. The value max-limit=256k/512k means that clients from private network will get maximum of 512kbps for download and 256kbps for upload. The target allows to define the source IP addresses to which the queue rule will be applied. (and) Note: Since RouterOS v6 these settings are combined in the option target where you can specify either of the above. Target is to be viewed from perspective of the target. If you want to limit your users's upload capability, set "target upload". --
If all of your traffic you want to limit is on a single interface, you could also try applying the simple queue directly to the interface - specify ether1 (or whatever it may be) as the Target instead. It's entirely possibly it's a hardware related thing too, although as I remember it's all done in software. I'll try and run up the config today or tomorrow on another router (I think I have a hAP or hAP lite lying around somewhere) - which can rule that in or out as well. M ________________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Karl Auer <kauer@nullarbor.com.au> Sent: Saturday, 3 February 2018 17:38 To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] queue noob On Sat, 2018-02-03 at 05:56 +0000, Michael Junek wrote:
All looks to be in order. In response to your question - yes, I am. I have a guest network which is limited to 2M/256k per user, with an aggregate of 8M/1M
I think you mean 1M/8M, and does this mean your setup puts an upper limit of 8 megabits per second on aggregated outbound traffic, and 1 megabyte per second on aggregated inbound traffic, whatever else it may do per user? Silly question I know - but have you ever tested this and seen conclusively that it does actually impose the limits you expect? If so, how accurately does it impose the limits? Would you expect the queue I described to put an absolute upper limit of 10K bits per second on the link - in total? I am starting to wonder if there are magic numbers, and some numbers are too small or too large and get rounded up or down behind the scenes. Maybe my problem is in specifying 10000/10000? I tried 128k/128k and saw transfer speeds of 1.7 megabytes per second. 64k/64k seemed to slow it a bit at first, but by the end of the transfer the average had still reached 1.2 megabytes per second. At 10000/10000 the average speeds were still well over 100 kilobytes per second. As I sy, it does seem to have an effect - just not much. I thought at one point that it might be packets, not bytes, but there is no way known that the packet rates are approaching 10K packets per second in either direction. Just as a sanity check I used "set bandwidth" on the router (an RB951G- 2HnD) at the other end of the link I am trying to control and it worked fine. With a bandwidth limit of 128k/128k, the test transfer was neatly limited to around 13 kilobytes per second, which is near enough. I think I might have to go back to Mike cap in hand and ask for a different router. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Sat, 2018-02-03 at 05:56 +0000, Michael Junek wrote:
Below is my config. The per connection queueing is handled by the individual queue types, which are then bound in the simple queue which handles the aggregate.
Thanks for that; it has been a great help. I modified my queue setup to be more like yours, thusly: /queue type add kind=pcq name=Guest-10K-Downstream \ pcq-burst-time=1s \ pcq-classifier=dst-address \ pcq-rate=10k add kind=pcq name=Guest-10K-Upstream \ pcq-burst-time=1s \ pcq-classifier=dst-address \ pcq-rate=10k /queue simple add max-limit=10k/10k name=test \ queue=Guest-10K-Upstream/Guest-10K-Downstream \ target=192.168.100.0/24 .. and that worked much better, but still not as I expected, The transfer rate of a test file over the supposedly limited link was around 60 kilobytes per second. That's still tens of times higher than it should be, but way more acceptable than hundreds of kilobytes or even megabytes per second. Hence my question as to whether you have tested the limits your queuing is supposed to impose, by which I mean objectively, not using the Mikrotiks themselves to tell you :-) And another slightly pathetic question: Am I correct in expecting "maxlimit=10k/10k" to limit the affected traffic to ten kilobits per second in either direction, i.e. to somewhere around 1 kilobyte in either direction? That is, are the real transfer speeds of 60 kilobytes per second that I am seeing definitely unexpectedly high? Regards, K. PS: These are my queue stats. They make no sense to me. 0 name="test" target=192.168.100.0/24 \ rate=6.0kbps/3.3kbps total-rate=0bps \ packet-rate=11/3 total-packet-rate=0 \ queued-bytes=0/1072 total-queued-bytes=0 \ queued-packets=0/5 total-queued-packets=0 \ bytes=787434/715998 total-bytes=0 \ packets=6933/3005 total-packets=0 \ dropped=0/207 total-dropped=0 \ pcq-queues=8/1 What also puzzles me a lot is that with my 10k/10k limit in place, interactive comms with the router (CLI) is affected; echo delays and so forth. This is true even when there is no other traffic happening, and the CPU is at 1%. Take away the queue and the effect stops immediately. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 8454 EE43 6215 B6DD 1B4D 9D8D 984D 7BA1 7378 A38D Old fingerprint: 58F8 09D4 97E4 D74A 0940 44BC 8D6D C28C 3BC9 B0CB
participants (2)
-
Karl Auer -
Michael Junek