Using the ET/BWMGR AutoMgr (Auto Manager)

The AutoMgr is an advanced feature of the ET/BWMGR bandwidth management suite which allows for advanced control of policy management in an automated fashion. The AutoMgr allows you to check for longer term trends of usage and to change policies temporarily for a specific time period or until the conditions change. The learning feature enables it to only manage traffic that exists, which may be desireable for very large networks where it is impractical to create a ruleset for every user. For large networks, where the default policy for all users is not to control at all, its extremely useful for finding those with unusual levels of activity and applying temporary controls without having to manually monitor the network.

What it Can Do

The Auto Manager can implement more complex, longer term policies than can be achieved with the standard bandwidth management strategies. For example:

If any IP address has averaged more than 256Kb/s for the last 60 minutes, set the profile on that IP to reduce usage for 15 minutes.

Or, on a more macro scale:

If any IP address has averaged more than 800Kb/s for the last 3 hours, block the address for 20 minutes.

Additionally, cascaded policies can create a step-down effect:

1. If any IP address has averaged more then 512Kbs for 30 minutes, knock them down to a 256kb/s policy for 15 minutes
2. If any IP address has averaged more than 250kb/s for 60 minutes, knock them down to 56kb/s for 15 minutes
3. If any IP address has averaged more than 52kb/s for 30 minutes, set to 56kb/s for 30 minutes.

Note that policy 3. is a "sticky" policy, so that anyone filling their 56k limit will be limited until they stop. The above would cause anyone doing a huge transfer (or running a continuous p2p application) to be stepped-down from whatever the default limit is to 56kbs until they stop.

Auto-learning

The AutoMgr has the ability to "learn" what addresses are in use on your network, which makes it useful when there are a very large number of customers that aren't continuously active (residential) or when you have an extremely lazy admin staff. Its most useful when "most" of your users are subject to the same, general policies. its not practical to have 10,000 static rules, and its not efficient when only 20% of users are active at any given time. Auto learning allows you to limit your rulesets and only monitor active addresses.

Enabling AutoMgr controls

In order to configure the AutoMgr you must enable it in the Bandwidth Manager Defaults. Select from the main ET/BWMGR menu and select the "Show AutoMgr" checkbox. When you return to the main menu, should appear under "Bandwidth Management".

Set Up Your Profiles

Its likely that you'll have a set of profiles defined to implement your strategy, but you may want additional ones to use for the AutoMgr function. Supposing the case where you were using the AutoMgr to completely manage your network, lets use the following profiles:

The profiles define a default level of service (512Kb/s incoming, 56K out, burst to 800K for up to 60 seconds). Normally this may be more than you want to offer. But with the AutoMgr you can monitor users that burst continuously and "kick them down" using the kickdown-1 and kickdown-2 profiles.

Adding a Group

The first step is to add a group to manage. When you first access the AutoMgr page, you'll see the following:

 

Press to add a group:

I've filled in the settings for our example to illustrate. Below is an explanation of each field:

Interface:	The interface name for the policies
Position:	Whether the interface is attached to your internal network (inside) or the internet (outside(
Group Name:	The name to use for the AutoMgr group
Start Index:	The index for the Group Name (rules will be placed at lower indexes)
Max Rules:	Maximum number of rules to learn/create
Learning:	Enable learning (a learning rule will be created ad Start Index + 1)
Profile	The profile to apply when creating a new, learned rule, and to apply when a condition terminates

The above settings set up a completely automated group. Alternatively you could create a static group with or without custom learning rules, in which case only the interface and the group name would be required.

After saving, you'll see the setup options in the status menu:

The general status screen shows the group name, the interface, whether learning is enabled and how many controls are currently in effect. Clicking on the Group Name link will allow you to manage group-specific functions:

Auto-Learning

When you click "start", if learning is enabled the group will be created (if not already present) and the rule to facilitate learning will be created at index + 1 of the group index. The learning rule will cause the system to "learn" all of the addresses on the network by monitoriing traffic. In this example, for each address, a policy will be put into the AutoMgr group which can then be acted upon by the AutoMgr system. Note that you do NOT have to have any AutoMgr policies. If you wanted to, you could just use the learning feature to apply a default profile to all of the addresses on your network. After clicking Start and then viewing the bandwidth rules, you should see something similar to the following:

Note the trigger rule at index 50 that is required for the profile trigger. Rule 500 has been setup as the AutoMgr group. Rule 5001 is a reverse learning rule that has been assigned the "default" profile and has been attached to the AutoMgr group. Assuming the system is on a live network, it will immediately begin learning rules. After a short while, our display looks as follows:

As you can see, the AutoMgr group now shows 2486 members and 4.4 million "hits". Clicking the Group link, we can view the entries:

The group is shown here sorted by usage, so you can see the IPs in descending order of bandwidth usage. Note that each policy has been assigned the default profile. These rules are temporary rules that will be deleted if there is no activity for some period of time.

Note that the software has a built-in throttle that limits the number of learned rules to 200/second, so it may take a while when you first start it up.

Adding Controls

Adding controls does require a bit of thinking particularly if you will be cascading your rules. In this case, we want to slow the user after some period of time of continuous activity. This will allow us to permit higher throughputs to those that only pull down small files like webpages or small applications.

The policy ID is arbitrary, however they do have meaning relative to other policies. Policies are checked in sequence from low to high policy ID, so you must order them properly to implement your strategy. The policy says that any IP address (or other rule you have manually put into the group) that averages over 512Kb/s for 180 seconds should be set to the "kickdown-1" policy for 300 seconds. Note that this is an average, so someone bursting to the full 800Kb/s may get to this average in 150 seconds.

Taking a look at a full ruleset:

As mentioned before, rulesets are "checked" sequentially, so first policy 1 will be checked, then policy 2, then policy 3. A lower policy cannot override a higher policy ID. So if a rule is set by policy 3, it cannot be changed because policy 1 also applies.

The effect of this ruleset is simple. If anyone has incoming or outgoing throughput of more thatn 512000bps over any 180 second period, the kickdown-1 policy will be applied (this is a 256kb/s policy) for up to 300 seconds. The second rule checks for longer term usage. Note that you must be careful here. For example, anyone who has averaged 512K over 180 seconds is already averaging 256K over 360 seconds. So you must make sure your policies don't overlap. Policy 2 checks for usage over 240000bps for 10 minutes. Since the 'kickdown-1" is in place due to policy 1, this must be less than 256K or there will be no chance that it can occur. Anyone over this limit is set to kickdown-2, which is a 128Kb/s policy.

Policy 3 is a "sticky" policy, because its value is less that the profile specified in Action. The policy will keep a user at the kickdown-2 setting until they are no longer averaging 120Kb/s. Since the profile is above that (128Kb/s), the user could stay set here indefinitely. The time limit of 300 seconds will get reset each time the policy applies. So effectively, the time limit of 300 seconds requires that the user be UNDER the policy setting for that long before the default profile will be reapplied.

As mentioned above, when a policy no longer applies, the AutoMgr default profile will be re-applied (not the rule named 'default', unless that happens to be your default as it is in the example above). Take the case where a user starts a download of a large file that ends up taking 40 minutes. He starts the download, and goes into the other room to watch a ballgame. Initially he'll get 800Kb/s (assuming bandwidth is available) for 3 minutes. Then he'll get 256K for 5 minutes, and then he'll get 128K for the remainder of the download. After a period of no activity for 5 minutes, he'll be reset to the default profile.

Overriding AutoMgr Controls

If you have hosts or users that you don't want to be subject to AutoMgr controls simply put them before the AutoMgr ruleset. The above example puts the Automgr group at index 5000 and allows for 1000 rules. This implies that any rule below 4001 may be used for rules that will "hit" before the AutoMgr would have any effect.

Advanced Topics - Multiple Groups

You can add other groups to the AutoMgr configuration the same way you added the first group. Note that you can only have learning enabled for 1 group. If you want more than one group to learn entries, you have to add the learning rule manually. The reason is that the "learning" rule by default learns all addresses. So once a learning rule it "hit", no traffic will every go further. So all of your other rules must be BEFORE the learning group.

I've added a group called WidgetCorp with learning disabled. The assumption is that this group exists and was created manually, as we'll do next.

Advanced Topics - Static AutoMgr Group Entries

You can add static entries to an AutoMgr group or you can create a completely static group. Consider the case where you have a customer with a range of addresses that you want to limit to the "default" profile.

In the example above, WidgetCorp is a group of 14 addresses that is limited by the default profile. The AutoMgr will manage the group as a single entity. Note that rule 2000 for AcmeCorp is a static entry that is also included in the group.

A not of caution is that if you issue a Clear from the AutoMgr menu ALL entries in the group will be cleared. To just get rid of the "auto" and learned entries, use Reset instead.

Advanced Topics - Creating a Custom Learning Group

We can expand the previous example by adding some custom learning rules. The default behavior is the learn all of the addresses in a particular direction. But suppose you only want "some" of your networks to be included?

This example adds 3 reverse-IP rules at 5001, 5002, and 5003 that will learn addresses for the 10.1.1, 10.1.3 and 10.1.17 networks only. Make sure you disable learning if you use custom learning or rule 5001 may be overritten or deleted.