NetEqualizer Directory Integration FAQ

Editor’s Note: This month, we announced the availability of the NetEqualizer Directory Integration (NDI) feature. Over the past few weeks, interest and inquiries have been high, so we’ve created the following Q&A to address many of the common questions we’ve received.

What is NDI anyway?
NetEqualizer Directory Integration (NDI) is an API for NetEqualizer that allows you to pull in username information from a directory and display it in your active connections table. This way, instead of only seeing IP to IP connection information, you can see usernames associated with those IPs so that you can make better decisions about how to manage your bandwidth. We will gradually be expanding NDI functionality to allow for shaping by username.

How much does NDI cost?
NDI requires setup consultation and is an additional add-on feature for the NetEqualizer. Currently, version 7.0 is required to run NDI. Take a look at our price list for more information.

How does NDI work?
NDI is an API on NetEqualizer that sends your directory server a URL containing an IP address. The process on your directory server then looks up the username for that IP and returns it to the NetEqualizer which stores the information.

What am I responsible for implementing with NDI?
You are responsible for implementing the process which resides on the directory server. This process returns a username when given an IP by the NDI API call. We have examples of how to do this for some directory server setups, but directory server setups are too specific for us to create a generic process that will work for all customers.

When would knowing the username be helpful?
Knowing the username instead of simply IP-to-IP information can helpful for administrators in many ways. Here are just a few:
– Easily see which users are taking up a lot of bandwidth. This is doable with a manual look up but that can get tedious.
– Eventually, NDI will be enhanced to shape by username. Again, this helps take away a step that an administrator would have to perform manually.
– Often, users are not assigned static IP addresses. With NDI’s dynamic updating, you don’t have to worry about the IP anymore. The username information will automatically adjust.

What are the upcoming enhancements to NDI?
We are planning to make NDI more robust in the months ahead. Our first feature will be Quotas by Username. This feature is currently in Beta. Once this feature is implemented, you will be able to assign usage quotas by username as opposed to IP or subnet. Additional possible changes to NDI include shaping by username and limiting by username. Stay tuned to NetEqualizer News for announcements.

If you have additional questions about NDI, feel free to contact us at:!

Check List for Integrating Active Directory to Your Bandwidth Controller

By Art Reisman, CTO,

Art Reisman CTO

The problem statement: You have in place an authentication service such as Radius, LDAP, or Active Directory, and now you want to implement some form of class of service per customer. For example, data usage limits (quotas) or bandwidth speed restriction per user. To do so, you’ll need to integrate your authentication device with an  enforcement device, typically a bandwidth controller.

There are products out there such as Nomadix that do both (authentication and rate limiting),  but most authentication devices are not turn-key when it comes to a mechanism to set rate limits.

Your options are:

1) You can haggle your way through various forums that give advice on setting rate limits with AD,

2) Or you can embark on a software integration project using a consultant to accomplish your bandwidth restrictions.

In an effort to help customers appreciate and understand what goes into such an integration, I have shared notes that I have used as starting point when synchronizing our NetEqualizer with Radius.

1) Start by developing (borrowing if you can) a generic abstract interface (middle ware) that is not specific to Active Dircectory, LDAP or Radius. Keep it clean and basic so as not to tie your solution to any specific authentication server.  The investment in a middle ware interface is well worth the upfront cost.  By using a middle layer you will avoid a messy divorce of your authentication system from your bandwidth controller should the need arise.

2) Chances are your bandwidth controller speaks IP, and your AD device speaks user name. So you’ll need to understand how your AD can extract IP addresses from user names and send them down to your bandwidth controller.

3) Your bandwidth controller will need a list of IP’s or MAC addresses , and their committed bandwidth rates. It will need to get this information from your authentication database.

5) On a cold start, you’ll need to make bandwidth controller aware of all active users, and perhaps during the initial synchronization, you may want to pace yourself so as to not bog down your authentication controller with a million requests on start-up.

6) Once the bandwidth controller has an initial list of users on board, you’ll need to have a back ground re-synch (audit) mechanism to make sure all the rate limits and associated IP addresses are current.

7) What to do if the bandwidth controller senses traffic from an IP that it is unaware of? You’ll need a default guest rate limit of some kind for unknown IP addresses. Perhaps you’ll want the bandwidth controller to deny service to unknown IPs?

8) Don’t forget to put a timeout on requests from the bandwidth controller to the authentication device.

Integrating NetEqualizer with Active Directory

By Art Reisman


I have to admit, that when I see this question posed to one of our sales engineers, I realize our mission of distributing a turn key bandwidth controller will always require a context switch for potential new customers.

It’s not that we can’t tie into Active Directory, we have. The point is that our solution has already solved the customer issue of bandwidth congestion in a more efficient way than divvying up bandwidth per user based on a profile in Active Directory.

Equalizing is the art form of rewarding bandwidth to the real time needs of users at the appropriate time, especially during peak usage hours when bandwidth resources are stretched to their limit. The concept does take some getting used to. A few minutes spent getting comfortable with our methodology will often pay off many times over in comparison to the man hours spent tweaking and fine tuning a fixed allocation scheme.

Does our strategy potentially alienate the Microsoft Shop that depends on Active Directory for setting customized bandwidth restrictions per user ?

Yes, perhaps in some cases it does. However, as mentioned earlier, our mission has always been to solve the business problem of congestion on a network, and equalizing has proven time and again to be the most cost effective in terms of immediate results and low recurring support costs.

Why not support Active Directory integration to get in the door with a new customer ?

Occasionally, we will open up our interface in special cases and integrate with A/D or Radius, but what we have found is that there are a myriad of boundary cases that come up that must be taken care of. For example, synchronizing after a power down or maintenance cycle. Whenever two devices must talk to each other in a network sharing common data, the support and maintenance of the system can grow exponentially. The simple initial requirements of setting a rate limit per user are often met without issue. It is the follow on inevitable complexity and support that violates the nature and structure of our turn-key bandwidth controller. What is the point in adding complexity to a solution when the solution creates more work than the original problem?

See related article on the True Cost of Bandwidth Monitoring.

%d bloggers like this: