simple queue missing traffic (ie not working) (simple 1 pc setup)

RouterOS General
1

i have encountered this before for clients, but now that i have a fiber line at the office im able to reproduce/test this while controlling for everything.

this is only MT attached to the fiber line, there is only 1 pc behind the mikrotik (is doing NAT, no fasttrack).

the Simple queue, whether on the entire interface of the WAN , or as is more common on the LAN port and set for a single local IP (or subnet), same result, traffic is getting past it beyond the speed limits set.

yet test torrent traffic is racing right past it. (im testing with torrent traffic as its a good/quick way to simulate many, BW intensive and diverse connections from a single pc). + its a type of traffic we as providers have to deal with. (to be clear: this topic is NOT about torrent traffic or how to control torrent traffic, this topic is strictly about why would a simple queue fail to limit some traffic or protocols)

see image , queue is set for 150/150m , isp line is a 200/200m line , and mt export. (only 1 pc attached directly to eth1)

(note- trying the other queue types that you see as disabled, showed the same exact results)- the weird thing is when watching torsch of both interfaces, ill see:
(on lan int)- pub IP- RX:50m TX:1m

any ideas? tks


# apr/25/2019 20:19:51 by RouterOS 6.44.3
# software id = P2xx
#
# model = RB4011iGS+
# serial number = B8xx
/interface ethernet
set [ find default-name=ether1 ] name=ether1-SW
set [ find default-name=ether2 ] name=ether2-UNITI
/queue simple
add disabled=yes max-limit=180M/180M name=queue2 target=192.168.1.14/32
[b]add max-limit=100M/100M name=queue3 target=192.168.1.14/32[/b]
add disabled=yes max-limit=100M/100M name=queue35 target=192.168.1.0/24
[b]add disabled=yes max-limit=100M/100M name=queue34 target=0.0.0.0/0[/b]
add disabled=yes max-limit=150M/150M name=queue1 target=ether2-UNITI add comment=PCQ disabled=yes limit-at=100M/100M max-limit=100M/100M name=PCQ-queue1 queue=pcq-upload-default/pcq-download-default target=192.168.1.14/32
/ip address
add address=93.x/30 disabled=yes interface=ether2-UNITI network=93.x
/ip dns
set servers=170.x.x.x
/ip firewall filter
add action=drop chain=input comment="drop MGMT SERVICES PORTS - DROP if not on ACL" dst-port=\
    20-55,80-445,2000,8022-8729 in-interface=ether2-UNITI log=yes log-prefix="/drop/-TCP not on ADMIN addyList" \
    protocol=tcp src-address-list=!adminIPs
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether2-UNITI
/ip route
add distance=1 gateway=93.x.x.x.
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=192.168.0.0/16
set api disabled=yes
set winbox address=192.168.0.0/16
set api-ssl disabled=yes
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote
/snmp
set enabled=yes
/system clock
set time-zone-name=America/Toronto
/system identity
set name=TestQUEUE_rb4011_1.219

queueCapture.JPG

2

Your config is not in sync with the screenshots.

This queue should to the trick: target should be “internal” ip range / interface.
add max-limit=100M/100M name=queue3 target=192.168.1.14/32

You might want to reduce the bucket-size (which defaults to 0.1) to have a finer control over the bandwidth.

3

thanks for reply,
(i have always been seting local 192 IP of the PC as the queue’s target)
my SS maynot have been in sync as i was trying different queues, but mainly i wanted the export to show that i dont have any other FW or mangle rules that could be interfering.

even with 0.01 bucket size, still seeing lots of traffic get by, keep in mind if i do a simple speedtest.net run (ie it uses just 4x TCP connections to the same DST ip), that does fully queue at the 100/100m (w no overflow showed):

/queue simple
add bucket-size=0.001/0.001 max-limit=100M/100M name=queue2 target=192.168.1.14/32
add disabled=yes max-limit=100M/100M name=queue3 target=192.168.1.0/24

I have tried other queeu types as well (like PCQ), same results.

As i have said too, i have seen this happen on other MTs with other ISPs we have deployed, but i always assumed it was something in those more complex configs that i was not accouting for. However now that i can test this with everything contorled, this should be concerning (to us, and MT) as this will affect quality of a line (if you queues are letting traffic past them, in terms of ISP uplink). Unless its that im doing something wrong ofcouse.
I did email MT support about a year ago on this same issue (but at a different location), and they blamed the ISP (?) at the time. This is a different ISP , different physical location (by far) on this test im posting about here.

same result (bucket size does not seem to be doing anything):
queueCapture.JPG

4

With queuing one can only really control the transmitting side: so before almost filling the uplink pipe, what to send.
On reception side it’s a hack: by dropping some packets already transmitted and received, TCP and ONLY tcp, can be forced to back down / slow transmission.

The UPD is connection less, assumes loss, and will not back down / slow down. In other words, one can not prevent full pipe from ISP, if being bombarded by UDP.
Torrent also uses UDP…

5

when i looked at the traffic more closely, i saw some was UDP , which then made me realize that the UDP traffic is mostly what is causing this.

(you can only really control TCP , not udp, for the reasons you stated).

Will need to look at other sites where i have seen this before to see if there is any UDP cuasing the same thing. (i think there maybe some l2tp vpns, which are udp, so perhaps that is source there).

Thanks