Is there a way to put an IP range in the target when making a simple queue. I am trying to bypass all my hardware (192.168.88.2-192.168.88.9) from my bandwidth limiting from the next queue. I guess I can do 8 different queue’s but it seems something this common should be easier.
Depending on how many hosts you have, you could possibly get away with limiting your DHCP scope to being 192.168.88.128-254 and then make the queue’s target be 192.168.88.128/25
Or you could make an “exception” queue as you discussed with a target of 192.168.88.0/28 (which maps to .0 - .15)
So what you are saying is that if i put the target as 192.168.88.0/28 (which maps to .0 - .15) and then make my dhcp pool, 192.168.88.16-254 I could have those 15 ips to myself???
Ok, I did the math and since the last part of the target is only 4 digits, there are only 15 combinations of binary…Ok cool I’ll try that. I have another question now.
I have an access point that is backhauled from another radio, both in bridge mode, and the MT router in pcq limiting to the whole dhcp. when a client accesses the accesspoint, the pcq bandwidth limiting I have in place will only be restricting the clients stuff right?? Or since both the AP and the other radio each have a static IP, are they limited as well???
This is what I believe to be my problem.
Silly question, but why does a piece of infrastructure need to have unlimited bandwidth?
Unless it’s doing NAT for customers behind it, then its IP address will only be doing management stuff, which really shouldn’t require tons of bandwidth…
Furthermore, if you’re using PCQ (with no per-subqueue limits) then it just means to fairly share the bandwidth… which also shouldn’t hurt a piece of infrastructure’s management access.
You may want to PRIORITIZE the management access, but that’s a different methodology - however, if your devices are all in the 0-15 range, then you have a different queue set up to match this range, you could easily put a limit-at=xxxx value to guarantee the management traffic gets at least xxxx bandwidth.
Not sure exactly what management stuff is.
I set up one part of my campground which can have up to 100 users or more with 512K pcq with a little burst. Everything was fine, but we had a busy weekend, and I noticed you could get an IP, after a struggle, but with almost zero throughput. So it occured to me that the AP’s are also limited to the 512k and that maybe they are needing more then that. When everyone left after the weekend, good to go. So I am thinking this is my issue, do you agree???
APs are layer 2 devices - meaning they deal in MAC addresses, not IP addresses when they forward traffic.
Simple queues are layer 3 constructs - meaning that they match traffic and queue/limit it based on IP addresses.
In other words, APs work more like switches than like routers.
So if 3 users are connected to AP 1 - then the simple queue is going to see that as 3 users, and not “3 users behind this one WAP”
– of course, if the WAPs are also acting as routers - each one is a different DHCP server and has its own IP range behind it, and uses NAT on traffic going through it, then yeah, each WAP would need more bandwidth allocated to it, but I would probably recommend that the WAPs be configured not to act as routers in most cases so that isn’t an issue.
Ok, so that being the case, keeping them out of the DHCP and therefore my pcq queue is not going to solve my problem…Bummer, back to the drawing board…I really don’t know what my issue is now.
Are your APs acting as wireless repeaters, or do you have some type of hard-wired connection (cat5, fiber, vdsl bridge, powerline, etc) going out to the remote APs?
If they’re repeaters, then that’s likely the problem - repeaters only have roughly 1/2 the capacity as hard-wired access points - they have to spend half of their time talking to the users’ devices, and half of their time repeating the data up to the main AP. This is even worse with lots of stations being attached because the resource that gets used up is time… the repeater must divide transmit / receive time up between 100 users, and 100 repeated sessions to the main AP.
Another issue could be the DHCP pool is getting exhausted - remember that a /24 network can only support a maximum of 253 user devices after the router takes up one address itself.
If the lease time is too long, then you could run out of available addresses while old leases are waiting to time out. This is particularly true of networks where lots of people bring devices along. When the iPhone came out, our condo networks all had to go from using /24 networks to using /22 networks - 4 times bigger.
I recommend switching to at least a /23 and setting the lease time to 1hr.
As for bandwidth issues, how much do you have at the site in total?
I have a 75mb connection on this particular network. I have a nanostation M2 backhauled to Bullet M2 into ether 3. I have a rocket m2 with an omni in AP repeater mode that goes to two bullet M2. Right now we are busy and I have about 40 clients in the active window of the hotspot.
I know about the repeater problem. Really though these radios are good for about 30 clients each, so even if we cut that in half and say 15 each, I am still good. In addition, the backhauled link can be just as bad as the repeater links.
If I use queue’s to limit bandwidth at the MT router, does that really help??? If all the router is doing is dropping packets, but the clients keep sending them, then it seems they are just using up the throughput for nothing. I know its better to limit at AP, but I have not found a per IP way to do this with ubiquiti devices. Really, all the AP’s should be a router, with Per IP limiting, so that no worthless info is passed over the links. Is this a correct assumption???
I believe the MT hotspot is doing its job on the leases. the Host tap has may 60 entries, with the active say 40. They time out after 5 min inactive or 30 min out of reach.