Can bandwidth be limited and/or policed per ssid?

  • 1
  • Question
  • Updated 4 months ago
Can bandwidth be limited and/or policed per ssid or VLAN?
Photo of Todd Parkins

Todd Parkins

  • 1 Post
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Todd,

It's much better than that in HiveOS, you control things like this on a per user profile basis so you have complete flexibility.

It would be a product limitation to couple this inflexibly and directly to a SSID or a VLAN.

You can achieve the same end result by configuring and applying user profiles appropriately based on your needs.

I would also implore to you to consider using QoS over other types of cap.


Photo of Prashan


  • 8 Posts
  • 1 Reply Like
So we can't limited the bandwidth for per SSID, ryt ?
Photo of Nathaniel Moore

Nathaniel Moore, Employee

  • 56 Posts
  • 16 Reply Likes
It's also worth mentioning in addition to Nick's post that in HiveManager NG, you will soon have the ability to impose a data usage limit per user profile.

For example, User Profile X is limited to 1GB of data per day. Additionally, we are adding time-based restrictions to the UI. This will enable you to, for example, say that User Profile X can only consume 1GB of bandwidth between 8:00 and 17:00 each day.

Keep your eye out for these features as they will be coming very soon :)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Here's a couple of thoughts on that...

As user profiles are often used as group profiles, how does this interact with that?
Is there a dependency on HM-NG being live and available for this feature to function? Does it work when external RADIUS servers are being used?

You would want the ability for such a limit to be applied for a discrete identity based on what the user profile directs, not in aggregate for all users with that user profile.

Incidentally, were that supported and where an external RADIUS server is in use, you would further need to return the TLS-based EAP inner identity normalised in the User-Name attribute of the Access-Accept to avoid spoofing another user via identity privacy - the EAP outer identity and to ensure identity consistency for a discrete user.

(There's different ways of referring to the same user: foo, foo@domain,, domain\foo and\foo)

(Additionally, HM-NG currently has a bug where user correlation is case sensitive rather than case insensitive. Depending on how and where this is enforced, there may be issues there.)