Upgraded all of our access points to RouterOS 3.4 about one week ago.
After a couple of days we began to get complaints about randomly occuring high ping times.
After some research I found out that it was the access-list (with per client bandwidth control), that was the source of the problem. The symptoms can be explained in the following way:
There is no default upper bandwidth set, and clients are allowed to authenticate by default.
There is created one mac-based static access-list entry pr client to throttle the clients bandwidth.
When client A is assigned, say, tx: 1000kbit rx: 1000kbit, and uses download bandwith fully, all other clients will get horrible response times and bandwidth. It’s like the access-list entry for one client has an effect on all the other clients as well. When one uses his full bandwidth, it’s like the AP tx speed is operating at 100%, so the other clients aren’t properly served. This is not a cpu-related issue, as the problem suddenly have appeared on all our ROS 3.4 APs, many of which has plenty of CPU time available. I’ve also tried both with, and without nstreme, without it making any difference.
When I disabled the access-list completely, and the clients are solely throttled by our central router connected to the internet, everything works like it should again.
Is this a bug in RouterOS 3.x, or is the access-list meant to function in a way I haven’t comprehended?
Problem still confirmed on ROS 3.10 AP, is there any way to limit the client activities beside the access-list? The access point is in bridge mode, so the simple queues doesn’t seem to work. The traffic shaping has to be done at the AP.
It also depends on your available bandwidth feed to the AP.
If you have a feed of lets say 1Mb and your clients also are limited to 1Mb then when only one client is using it he gets all the bandwidth, 1Mb.
The moment more clients want access the AP has to start sharing the feed to all its clients. So everybody will see lower speeds. That is a very normal thing. It will also have effect on ping times since the AP radio has to distribute its time amongst more user radios and thus ping times will go up.
You can make life easier for your clients in several ways:
Have a bigger feed, most simple way. If your feed is 3Mb and you sell only 1Mb already 3 users can fully use their max. before problems arrive.
Have QoS with queuing on the AP to arrange more sophisticate bandwidth share amongst users en programs.
Limit clients to smaller bandwidth! May be not the most desirable solution but less complaints for not getting what they have been sold!
Be aware that if you have only a handful users performing big downloads over time (video, streams, big files) you run out of capacity very fast. For instance, a network that can handle only 3 full same time down loaders (say 3 x 1Mb while feed = 3mb) that same network can handle probably 30 users simultaneously browsing before problems are becoming noticeable. Since browsing only generates short lived bursts of downloads the traffic jam is very little compared to some paralleling high continuous data streams…
But your choice of wording give some room for confusion:
¨_There is no default upper bandwidth set_¨ What do you mean with that?
¨_When I disabled the access-list completely, and the clients are solely throttled by our central router connected to the internet, everything works like it should again._¨. How do you ´disable´ the access list? If you mean that you disable your access list entries only (by graying the entries out in winbox) and clients are still able to get authentication by the AP it means you have ¨default auth¨ ON in your AP. Only when ´default auth.¨ is OFF in the wireless setting of the AP the Access list becomes in charge. Then the AP looks in this list which mac is allowed authentication (or not) and what is its assigned bandwidth limits (or not). I think in your case the access list was not doing its work in the first place, it was never enabled. You just enabled/disabled each mac. filter in the list. But it never has had any effect since the list in itself has not been in use.
You wrote : ¨There is no default upper bandwidth set, and clients are allowed to authenticate by default.¨
Specially the italic part made me believe you have ´default authentication´ ON all the time.
When default authentication is on, any client with same radio band can log in and gets all speed available from the AP. More clients authenticated, less speed everybody gets…
How many clients were on when problems are noticed?
How big is your feed compared to what clients can get (according Access list)
3.xx is working fine in this respect. I work with MT-AP’s that had seen all 3.xx family versions and on some AP’s I have 25 users all assigned 3Mb according the Access List while the feed is only 7Mb which in itself is shared with other AP’s too! Hardly ever see any problems. I have only 2 x 7Mb to serve 100 clients with 3Mb. Everybody is stunned on the high speed browsing most clients never experienced in their live before! Only when two or three users start lengthy downloads together in time others experienced users start to see some delays. But most ordinary browsers never see anything at all… The fun of having big feed is that I can sell relative high bandwidth to my customer since even movies or whole CD-rom’s only take 15-30 mins for a client which reduces simultaneously big download collisions to rare events…
We could never make the bandwidth settings in the access-list tables work correctly. Even with several posts and replies from MT support, they finally gave up as well.
We switched to using Simple Queues (make sure the setting in the Bridge section is checked to “Use IP Firewall”) or the queues won’t do anything. You also have to specify by IP address, but it works perfectly for us.
I just tested this again. If I set the speed to 2M on the “AP to client” speed and 2M on the “Client TX limit”, and then run a speed test I get 2M download to the client, but only 1.2M on the upload.
I have tested this on two different AP’s and two different clients.
How is everyone controlling their bandwidth with Mikrotik? When we had Nstreme turned on, we could use the Simple Queues on the AP and it worked perfectly. Then MT told us we had to turn Nstreme off with more than 30 clients and now a single client with a large download or upload can affect the entire AP (high latency, dropped packets, etc.). If I start a download on a client, I start dropping pings to all the other customers. Same with an upload.
Is there a good way to manage Mikrotik AP’s? We have over 60 AP’s and 700+ clients and it is a complete joke compared to other wireless solutions (Trango, Canopy, etc.). Is there a solution? We are deploying 100 new customers per month, but will be forced to switch to something else if there is not a good way to manage each customer (which have to have a symmetrical speed, like 1M x 1M).
heh well we use access list to control bw on the mikrotik to mikrotik and then use radiusmanger or usermanger or build a custome mysql + freeradius ordeal to control bw. You can also use firewall rules and queus to control it also. THe best way imo is to control it from the client side.