ET/BWMGR User Manual

(Version 3.3)

Table of Contents

ET/BWMGR Overview

ET/BWMGR is a bandwidth management system that provides a rich set of tools for monitoring and controlling the flow of traffic to and from your network. The System Monitor allows you to view traffic on your network with a variety of criteria, allowing you to learn about the composition of traffic on your network and also to view current usage by devices or protocols. The Firewall allows you to control the type of traffic that is allowed to flow in and out of your network. The bandwidth manager controls the rate of the flow of traffic through your network. The Prioritization Manager organizes the flow of traffic so that critical streams have the priority they need to meet service level agreements.

Theory of Operation

The ET/BWMGR is a complex subsystem that identifies types of traffic flowing through your network and acts upon it based on rules (or "policies" as some of our more marketing oriented competitors like to call them) that you set based on the specific needs of your environment. In order for you to create your own set of policies for your network, its important that you understand the basic flow of operations performed by the ET/BWMGR subsystem.

The ET/BWMGR considers each "interface" as a separate entity. Typically an "interface" is an ethernet card or a supported WAN adapter. The ET/BWMGR acts on every interface that has even a single setting. This clearly implies that the most efficient use of system resources is to have all of your policies on a single interface, if possible. For the sake of discussion, we will assume that all bandwidth management is being done on a single interface.

The flow of traffic can either be "IN" or "OUT". INcoming traffic is traffic being received by the interface. If its an ethernet card, its ethernet frames that are being received from the network. OUTgoing traffic is traffic being transmitted on an interface. If the interface is an ethernet card, its traffic being sent from the card to the network. Rules can be specified as INcoming or OUTgoing or as most usually, both. The ET/BWMGR software acts on the traffic the same in both directions. To understand the flow of operations within the ET/BWMGR software, let's examine what happens to an ethernet frame as it passes through the subsystem:

Lets look at a received frame and assume that policies are set in the receiving interface. When a Frame is received, it is copied by the system into a "buffer" which is then passed around until something is done with the data. It can either be acted upon, forwarded or discarded. First the ET/BWMGR checks to see if there are any settings or policies on the interface. If there are none, no action is taken and the frame is either passed up the protocol stack (which would be the case all the time if operating as Router, or if the source MAC address was the local machine's address if operating as a Bridge), or forwarded if in Bridging mode. If there are settings or policies on the interface, the buffer is then decoded into its protocol components. Decoding involves identifying the protocols and addresses and other interesting info. Once decoded, the Firewall is checked to see if the frame is allowed into or through the system. If a policy "Match" occurs with a firewall "Deny" rule, the buffer is discarded. If no Match is encountered, or the frame matches an "Allow" rule, then the procedure continues. If prioritization is enabled (ie. there are priorities set on the interface), the data's priority is determined and its placed on the proper priority queue. Data frames are then dequeued in priority order, and sent to the bandwidth management processing routines.

The Frames are then passed through the bandwidth management subsystem, which determines if the packet is to be forwarded immediately or if it is to be delayed. If the Frame is to be delayed, then the frame is sent to a bandwidth management queue and the process stops at this point. If a Match occurs on a discard rule, the frame is discarded.

If the Frame is not delayed (or after the delay is complete), the frame is either passed up the protocol stack (if it is destined for the local machine or if the machine is configured as a router), or forwarded to the appropriate interface directly if the machine is configured as a bridge.

Utilizing the ET/BWMGR involves establishing Rules which give you powerful control over the flow of traffic in your network. A command line utility is provided which allows you to manually configure ET/BWMGR parameters and to establish rules (or "policies") to achieve your goals.. Alternatively, a GUI (Graphical User Interface) is available which greatly simplifies the policy creation process. The remainder of this document will address the installation of the ET/BWMGR software into your system and using the command line utility and GUI to create a set of Rules to manage your network. If you have purchased the complete solution from us, you can skip the installation section below, however you will need this info if you decide to manually update your system later.

Throughout this document, em0 will be used for examples of setting up rules and policies. em0 is the first interface for the Intel gigabit controllers on our ethernet bypass cards. If you are more familiar with LINUX, you would replace em0 with eth0. FreeBSD has different names for each type of interface, while LINUX names all ethernet interfaces eth#..

Getting the ET/BWMGR product

The ET/BWMGR software can be purchased in 3 distinct forms. You can buy a complete appliance, which includes hardware and all software and external utilities needed for a complete bandwidth management solution. You can purchase a CD appliance, which is a CD that will install an appliance image on your hardware, or you can install the software manually onto an existing FreeBSD or Linux system.

Buying an Appliance

If you need more than 10Mb/s, then an apliance is your only option. However there are many advantages to an appliance vs the software version of the product. Anyone who's ever used a computer knows that there are so many diferent chipsets, NICs, video cards and memory types that running any os will always result in some small problems. Our appliances run on hardware that we've rigorously tested. We've fixed and tuned drivers, and we have 100s of customers all using the same hardware. If you encounter a problem, we will help figure out what it is, because we don't want our other customers to have the same problem. With our appliances, you get a solid product with full support. Its a piece of mind thats very important for such an important piece of your network.

Another advantage is performance. Tuning a system, and getting the most out of a NIC are critical at the high end of performance. Our systems are optimised to perform on our hardware.

The CD Appliance

The CD appliance is an appliance image that is built from the ET/BWGR demo CD. First you download and burn a demo CD. While you're testing, you can just boot off the CD. If you decide to purchase a license, you can use the CD to build an appliance. This allows you to test your hardware before you buy. In order to build a system, you will need to access our update server, which requires a license. Once you receive your license, you will be able to build a complete system on your own hardware. The advantage of a CD appliance over self-installation of the software is that you get all of the correct versions of companion software needed (mySQL, snmp, kernel configuration, driver patches), plus you get to use our update service to download updates directly to your system. Because we know that you are using the corect software versions, we can provide more help. (you are required to buy a subscription to get updates and support). The disadvantage of the CD appliance is that you may have hardware problems; some variation of a NIC that we haven't encountered, some chip that isn't supported well. Luckily you can test our hardware with our CD demo before making a purchase, so you should be able to find problems.

Manually Installing the ET/BWMGR Software

For information on manually installing our software distribution, please see the software installation page.

Editing default.cfg

If you have a document root that is not the default used in the installation script, then you need to edit the file /usr/local/etc/bwmgr/config/default.cfg. The defaults file has information about your document root for proper generation of graphs, and also information about interfacing with the statisics database. The default file will put the graphs in /usr/local/www/data on 'BSD systems and /home/httpd/html on Linux systems. The default file consists of a single line as follows:

HTTP_ROOT,/usr/local/www/data

simply change the directory to whatever your document root is and save the file. Again, if you are using the standard apache configuration no change should be required to this file. Other options supported in this file can be set using the GUI and the "Edit Defaults" button on the main menu. The options are:

Configuring Stats-only Mode

Stats-only mode is used if you just want to gather statistics and/or monitor your network activity. It allows you to plug only 1 ethernet port into a passive hub without putting the system "inline", so that the system cannot and will not affect your network in any way. Note that you must use a hug and not a switch, as switches will filter the traffic so the ET/BWMGR software will not see everything.

To configure stats-only mode, configure the interface that is plugged into the hub as follows:

bwmgr em0 -ifac -statsonly

From the GUI, go into the bandwidth rules screen, click on the interface link and select "Edit Interface". Then check the "stats-only mode" checkbox.

In stats-only mode, only rules with statsonly priority can be used. This allows you to gather stats by IP, MAC or traffic type and store them in the database. You can also use the system monitor in stats-only mode to view activity on your network.

Setting Up Bridging

The ET/BWMGR software allows you to set up your system as a transparent MAC layer bridge. Bridging allows you to put a PC with the ET/BWMGR software in between any two segments without having to worry about renumbering your network. To set up a bridge you need to do the following:

1) Assign a primary interface

If you need to access the machine through one of the bridged ports, you will need to give the port an address and assign it as the "Primary" port. This tells the bridge subsystem where the IP stack is for this bridge group. You dont have to have a Primary adapter in the bridge group (such as the case if you have a separate administrative port), but you cannot have more than one for a group, and the Primary MUST be an ethernet interface. If you have an ethernet controller on each bridge group, then you can just assign IPs to each ethernet and them specify it as primary. Assuming that you have assigned an IP address to em0, you could do the following:

bwmgr em0 bridge 1 primary

2) Enable bridging and assign bridge groups to secondary interfaces

You can assign your secondary interfaces to bridge groups for which you have assigned a primary interface.

bwmgr eth2 bridge 1
bwmgr eth3 bridge 1
bwmgr etha16 bridge 1

The above assignes eth2, eth3 and etha16 to bridge group 1, whose primary is em0. This allows all 4 interface to act as if they were all on the same wire.

Following is an example of a simple, 2 interface bridge setup (use em0 on a Linux system):

ifconfig em0 215.17.1.11 netmask 255.255.255.0
bwmgr em0 bridge 1 primary
bwmgr em1 bridge 1
bwmgr em0 start demo

And thats about it. You can now run ifconfig on the interface and check to make sure that the PROMISC flag is set. Note that promiscuous mode is not enabled until you issue the start command.

ifconfig em0

should yield

em0: flags <UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500

on a FreeBSD system and:

em0       Link encap:Ethernet  HWaddr 00:90:27:26:D0:73
           inet addr: 200.1.1.1  Bcast:200.1.1.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:281172 errors:0 dropped:0 overruns:0 frame:0
           TX packets:267533 errors:0 dropped:0 overruns:0 carrier:0
           collisions:36 Interrupt:9 Base address:0x6400 

on a LINUX system. Note that in LINUX the PROMISC flag is not shown by ifconfig, so you'll have to cobble through the /usr/local/messages file to find the message that tells you that promiscuous mode was enabled. In FreeBSD, if the PROMISC flag is not set then then bridging must not be set properly. To verify that the ET/BWMGR software has bridging properly set:

bwmgr em0 show

should show:

Data Type Definitions - em0 (NOT RUNNING) 
Bridging:Enabled Forwarding:ALL PROTS Group:1
-----------------------------------------------

You can also issue:

bwmgr bw0 showmac

to see if the bridge is learning addresses from your net. You should, at minimum, see the addresses of the cards in the PC with the LOCAL flag set:

00:C0:A0:43:67:D6 em0 <LOCAL>
00:C0:A0:7D:68:D6 em1 <LOCAL>

The <LOCAL> flag indicates that this is the physical address of the interface specified. Other traffic on the network will be "learned" by the bridge over time. Assuming that there is other traffic on the network, you may see something like this after a short while:

00:C0:A0:43:67:D6 em0 <LOCAL>
00:C0:A0:47:67:D6 em0 Age: 10
00:00:C0:1A:49:78 em0 Age:1
00:C0:A0:7D:68:D6 em1 <LOCAL>

Addresses that do not have the <LOCAL> flag have been detected as being on the same physical network as the interface specified. The "Age" shows the last time that the address was detected. Ages over 5 minutes are considered invalid.

If you have many workstations or servers this table can grow very large. Note that you can also view the MAC addresses of a single interface by specifying the specific interface:

bwmgr em0 showmac

will only show the MAC addresses associated with the network connected to interface em0.

Setting up Bridge Groups

Bridge "groups" allow you to logically separate traffic on different segments of the same machine. Without bridge groups, broadcast traffic is sent to all segments to which a bridge is connected. So, for example, if you have a bridge with 4 ethernets, they are all logically connected and can pass traffic to one another. By allocating a bridge group, you can logically segregate individual wires so that traffic is only forwarded to segments in the same logical group. Each bridge group has a "primary" interface which is the interface that has the IP address associated with it. Without a primary, IP routing cannot occur through the box without the bwmgr, nor can any device on the segments access the bwmgr box by IP address. For example:

ifconfig em0 200.11.1.1
bwmgr em0 bridge 1 primary
bwmgr em1 bridge 1

The above example illustrates the most simple of bridge groups, and the most common usage. The above connects em0 and em1 as a bridge and assiciated the 200.11.1.0 class C to the group. The setup allows fxp0 and em1 to both have the same network addresses and to use 200.11.1.1 as their gateway address. This can be done with any number of segments, simply by putting them in the same group.

A more complex setup includes 2 groups with separate IP space. In this setup, the segments in the different groups can only access each other by IP address; their traffic is not "bridged" and non-IP traffic or traffic for other networks will not be seen on by devices on different segments. For example, suppose you have a 4 port ethernet card:

ifconfig em0 207.11.14.1
bwmgr em0 bridge 1 primary
bwmgr em1 bridge 1
ifconfig fxp2 207.11.15.1
bwmgr fxp2 bridge 2 primary
bwmgr fxp3 bridge 2

The above setup creates 2 separate bridge groups on 4 wires. The setup is the same as if you had 2 segment using normal IP setup, except that each "segment" in this case has 2 wires.

About Bridge Group 0

The ET/BWMGR implementation has one special group (group 0) which is a "global" group in that it is a connection point for any other bridge group. The traffic allowed to pass through group zero is controlled by the "ipmap" commands. By default, no traffic is allowed to go through the bridge group zero interface. NOTE: Do NOT use bridge group zero for general purpose bridging as described in the previous section!

Bridge group 0 allows for 2 powerful configuration options. First, it allows the assignment of single addresses, one at a a time, to any bridged segment (be it an ethernet interface or a frame relay DLCI). It also allows you to protect the IP space by blocking addresses not specifically allocated:

As an example, suppose you had 4 ethernet ports in your bridge, named em0, em1, fxp2 and fxp3. fxp0 is the main segment, and the other 3 each go to different customers. Given that you don't want your customers to see each other's traffic (or to steal each other's addresses), you want to segregate them, but they all need to connect to eth0. Additionally, you only want to allocate one address per customer each of the segments. This can be achieved by placing eth1, eth2 and eth3 in a special "bridge group 0" and assigning individual addresses with the ipmap command as follows:

/* set up the bridge groups */

bwmgr bg0 create 00:00:00:01:02:03
bwmgr em0 bridge 1
bwmgr em1 bridge 2
bwmgr fxp2 bridge 3
bwmgr fxp3 bridge 4

/* allocate the address space */

ifconfig em0 207.14.17.1 netmask 255.255.255.0 ; (setup on bootup most likely)

/* this is the setup for bridge group 0 address space */

bwmgr bg0 218.1.1.1 netmask 255.255.255.252
bwmgr em1 ipmap 218.1.1.2
bwmgr fxp2 ipmap 218.1.1.3
bwmgr fxp3 ipmap 218.1.1.4

The example above sets up em1, fxp2, and fxp3 as separate bridge groups to segregate them from each other. Bridge group 0 is allocated as an anchor for a specific subnet and assigned the address space for all of the members of the group (ipmap command can only assign addresses that are in bg0 address space). em0,em1 and fxp2 are allocated addresses from that space with ipmap commands. Note that bridge groups 1,2 and 3 are allocated without a primary. Since group 0 was allocated previously, all groups with no primary specified will be put into the "global" bridge group 0. If a primary was subsequently specified, the interfaces in that group would be moved out of group 0 and into the real group with the primary interface specified as the address anchor.

Once complete, you will need to have all of the devices on bridge group 0 to use 218.1.1.1 as their gateway, and you will have to make certain that the network is made "known" to other routers via 207.14.17.1.

Viewing Bridge Settings

You can use the 'bwmgr showbridges" command to see the bridge settings currently installed in your system. Following is an example output:

#bwmgr showbridges

ET/BWMGR: Running
em0roup:1 Forwarding:<ALL PROTS > primary
em1 Group:1 Forwarding:<ALL PROTS>

The above is typical of a 2 port setup with both ports assigned to the same group and the first port designated as the primary port. Note that all of your IP addresses for the bridges must be on the primary port.

Advanced Bridge Groups

If you have bridged devices that are not ethernet interfaces that will be in a bridge group that doesn't contain an ethernet device, you can use the bwmgr utility to create a bridge group anchor (which is really a virtual ethernet interface). For Example:

bwmgr create bg16 00:00:04:00:00:02

will create an ethernet interface named bg16 which will use the address 00:00:04:00:00:02 as its ethernet address. The ethernet address can be any 8 hex digits but MUST not be the same as any device on your network and MUST not be a broadcast or multicast address or all zeros. If you dont understand the numbering for ethernet addresses, use 00 as the first number to be safe. The chances of chosing an address that exists on your network is fairly remote, but you can view your arp and routing tables to see what addresses are in use if you want to be sure. The bridge group must begin with bg and be followed by a number which will server as the bridge group number. This command also sets up the resulting interface as the primary interface for the group, so the above command would set bg16 as the primary interface for bridge group 16. The interface is also brought "UP", so after this command the interface is ready to use without any additional bwmgr commands.

Once you have created your bridge group anchor you can define the rest of your bridge group. First you should assign the newly created interface an IP address, then you can set up bridging with your secondary interfaces.

ifconfig bg16 211.14.1.1 netmask 255.255.255.252
bwmgr etha16 bridge 16

The above assigns address 211.14.1.1 to the local machine with a 30 bit submask and sets up bg16 as the primary interface for bridge group 16. Next, frame relay DLCI 16 (interface etha16) is assigned to the group. The effect of this is to create a bridge group for DLCI 16 which has its own IP address space. Devices on the other end of the frame line can be assigned other addresses in the subnet for this group. In order for devices on the bridged interface (that is, devices on the network on the other end of the frame link) to route through this machine they would use 211.14.1.1 as their gateway address.

This mechanism can be use with frame relay and DSL bridged frames to create logically segregated bridged networks each with its own IP address space. See our DSL example for more info.

Filtering non-IP Traffic on Bridged Interfaces

If you are bridging lans that have multiple types of traffic (ie NetWare, Netbios, etc) running on it, you can set a filter that will only allow IP (and ARP) traffic through. This is particularly useful if remote bridge sites must access IP resources on your local network, but you don't want them to see traffic from your other servers. To allow only ip traffic to be passed on a bridged interface, use the following syntax:

bwmgr em0 bridge {group} primary ip

where {group} is the group number, primary is optional if this is the primary interface. The keyword ip will set the filter. To make sure it is set, do a "bwmgr em0 show" and you should see the following:

#bwmgr showbridges

ET/BWMGR: Running
em0roup:1 Forwarding:<IP> primary
em1 Group:1 Forwarding:<ALL PROTS>

Note the "IP" in the parenthesis, which indicates that only IP traffic is being bridged.

Other Filters

Two other bridge "filters" are available but should only be used if you fully understand the inner workings of your network.

bwmgr em0 bridge group forcefwd

The forcefwd setting (force forward) may be used in a point-to-point setup where there is only 1 device on either side of the bandwidth manager. Force forward assumes that any packet received on one port in a bridge group should be sent out on the next port. Force forward mode does not use the destination MAC address for routing. It will only work in a setup where there are 2 ports in a bridge group and there is no communications sent to it that isn't destined for the network on the other port.

bwmgr em0 bridge group lo

the "lo" filter (short for learned-only) will change the default behavior of MAC forwarding in the bridge. The default behavior is to broadcast all "unknown" addresses to all interfaces in the bridge group. Note with MAC bridges the location of a device is "learned" when a frame is sent from a device on the network. Typically, when the bridge is first started up, traffic is broadcast until all devices are learned. Setting the lo filter will cause traffic sent to MAC addresses that has not yet been learned to be discarded.

Setting up a Fallback Interface

If you are using a failover/bypass card you may have a third interface which you want to use as an administration port. Typically, this is no problem as there is no requirement that the data stream passing through the failover card have an address. Usually its fine to just assign your address to the admin port (say em0) and set up a bridge between your 2 failover ports (say fxp2 and fxp3) with no primary assigned. However there may be cases where you want to assign your address to one of the failover ports. This is typically the case with a cache system, since you want your cache proxy (which originated in the machine) to communicate over the main port rather than the admin port. Problems arise because you can't assign an address to both em0 and fxp2 safely, unless they are on completely separate physical networks, which is often inconvenient. Using a the fallback setting solves this problem, but creating an "alternate" port for the primary. When the primary is physically "down", the system will enable the fallback port. So in the case of the failover/bypass card, if you were to take the system offline (by putting the card into bypass), the fall back interface would be enabled and you could then communicate through the alternative port. For example:

Suppose you have a four port system (like our appliances), where em0 is to be used as the admin port and fxp2 and fxp3 are the failover bypass. You're setup would look as follows:

ifconfig fxp2 192.168.0.1 netmask 255.255.255.0
bwmgr fxp2 bridge 1 primary
bwmgr fxp3 bridge 1
bwmgr em0 bridge 1 fallback

This configuration results in em0 being enabled when fxp2 (the primary) is physically down (pulling the wire will do it also, as well as putting the card into failover in this example). When fxp2 is "online", then em0 will be disconected.

System Configuration Parameters

Setting the Indexing Level

The ET/BWMGR incorporates a powerful algorithm which indexes rules for ultra-fast lookup. There are 2 indexing levels available for non-firewall rules, both of which use the -addr (IP Address) part of the rule as the index. The default, level 2, should be used for most installations. Level 1 has less granularity but should be used if you have a lot of subnet rules. So, if you have a web farm and most of your customers have a single web address, then you should use level 2 indexing. If you are primarily limiting by class C network addresses, for example, you should use level 1.

Each interface can index at a different level. As stated before, the default is Level 2, so if you are using level 2 you dont need to do anything to set the level. The GUI (and the "rebuild" command) will always generate a command line to set the index level. The syntax is as follows:

bwmgr em0 indexlevel 2

This sets the index level on interface em0 to 2. Note that you MUST do this before adding any rules to the interface. The driver will reject an attempt to change the level if there are rules presently defined.

Starting with v3.3, the firewall rules are also indexed. Firewalls have 3 index level choices. 1 and 2 are the same as for the regular rulesets, using the IP address. A 3rd choice is available, indexlevel 3, which uses -port. Level 3 is useful if you are firewalling by port rather than by address. Address is more effective, so if you use both, then use level 1 or 2. You set the firewall indexlevel using the fwlevel keyword:

bwmgr em0 fwindex 2

Analyzing your ruleset

You can check the efficiency of your ruleset with the analyze command:

bwmgr em0 analyze

FW Global Rules: 0
FW Indexes: 0
FW Worst Case: 0
BW Global Rules: 3
BW Indexes: 1
BW Worst Case: 3

This shows that the current ruleset has 3 rules that have to be checked for every packet that arrives. Keeping the number of global rules down is the key to efficiency. The "Worst Case" is the rule which requires the most processing. Worst case is always higher than the number of global rules, which is "every case".

Setting the maxbuffers parameter

The maxbuffers parameter will put a cap on the number of buffers that the bandwidth manager will use to store managed data in its limiting or prioritization queues. The purpose of this parameter is to keep the bandwidth manager from exhausting your system of network buffers (which may cause it to fail). You can also use it to limit the amount of backup traffic that the bandwidth manager will manage. Typically, this number should be slightly lower than the number of system buffers you have available for network frames. In FreeBSD, you can check to see how many buffers are allocated in your running kernel with the following command:

sysctl kern.ipc.nmbclusters

Issuing this command will print the number of buffers allocated in your system. To change the setting, you can either change the NMBCLUSTERS setting in your kernel, or you can set the number of buffers to use at boot time by putting a line like the following in /boot/loader.conf:

kern.ipc.nmbclusters="16000"

Remember that each buffer is 2K, so you can't allocate an infinite number of buffers. Normally Freebsd will allocate 1/3 of RAM to the kernel. Our supplied kernels and kernels in our appliances use an algorithm to determine how much ram to use. Note that buffers are allocated on the fly, so the system won't tell you if there isn't enough RAM to implement your setting. If you set it too high, your system may just blow up when it runs out of memory, so be careful.

After determining the buffer allocation in your system, you can then use "netstat -m" after initial boot to see how many buffers your system uses with no traffic (this will vary depending on what cards and devices you have in your system. Suppose your system uses 700 clusters after boot. You could set your maxbuffers setting to say 15000 (which is less than 16000 - 700).

In Linux, you have no way of knowing how many buffers your system has as the memory pool is dynamic, so its pretty much a crapshoot. Usually a setting of 10000 or so is safe for most installations.

When you issue a "show" command via the command line or look at the main menu in the HTML interface, you will see "maxbuffers" shown in the n1/n2 format. The first number is the "high use" counter..this is not the number in use currently, but the most that were ever required. The second number is your "maxbuffers" setting. You can clear the first number by setting maxbuffers to the same number as you currently have. Its not generally a good idea to change the maxbuffers setting when your system is experiencing a heavy load, but setting it to the same value will only reset the high use counter. So, if you have 8000 buffers allocated in your system, you can issue the command:

bwmgr maxbuffers 16000

to reset the high use counter.

Setting the Stats Period

The stats period is the length of the window used internally to manage per-rule statistics. The default period is 20 seconds. For statistics, the stats period is how often snapshots of statistics are saved. For the most part, this is completely arbitrary. When you view stat for a rule, you will see the usage for the current period and the last stats period. The current period will have a slight error unless looked at exactly on the second. The "last period" will be a snapshot of the last stats-period, and will be an exact usage value for that period.

These are the stats that are used with the "sort by usage" feature in the GUI.

Starting the Bandwidth Manager

You can start the bandwidth manager process with the following syntax::

bwmgr interface start authentication_key

where interface is the interface that you used to generate your serial number with the "bwmgr interface serialize" command and authentication_key is the license key that you received when you purchased your license..

Running the ET/BWMGR Demo

Before you purchase a license, you should test your target hardware with out Demo CD. You'll need to run the sofware in "demo mode" by using the word demo as the key. So, for example, to run the bandwidth manager in demo mode, you could use a line similar to the following:

bwmgr bw0 start demo

Demo mode provides full functionality for a gigabit bandwidth license but will only run for 6 hours, provided that your system can contact out server when you start it (ie an internet connection is required). When the demo concludes, a message will be displayed indicating that it has completed. Once the demo completes, traffic will no longer be controlled, and bridging will cease to operate. In order to restart the software, you will have to reboot the system. You will be able to run the full demo for approximately 20 days. If you cannot contact our server or your demo period has expired, the bandwidth manager will start in "Limited" demo mode, which is only 1 hour, disables use of the System Monitor and allows a maximum of 10 rules. Once you have determined that the sofware is installed properly on your hardware, you can obtain a license key from Emerging Technologies that will no longer stop after the demo time period (see the FAQ).

If you are considering a purchase of a 10Mb/s or 2Mb/s software license, you can run a 10 or 2Mb/s demo, which runs at 10Mb/s or 2Mb/s respectively, and will simulate a software license. To run the 10Mb/s demo, use the following:

bwmgr em0 start demo10

for the 2Mb/s demo:

bwmgr em0 start demo2

and for the 100Mb/s demo:

bwmgr em0 start demo100

Obtaining Your System Serial Number

In order to purchase a license, you will need to supply your system "serial number". This is a unique number that is specific to the physical system you are using. When you order the ET/BWMGR software license, you will receive a "key", which is keyed to the serial number, so it can only be used on your physical system. To get the serial number, run the following command:

# bwmgr interface serialize

(where interface is an ethernet interface, such as em0 on FreeBSD or eth0 on a LINUX system). This will print out 6 hex pairs that is the serial number for your system, such as:

c0:fc:d0:00:03:70

When you order your license, you will need to provide this sequence on the order form so that we can generate your license key. When you receive your license key, you MUST start the bandwidth manager on the same interface that you used to generate the serial (em0 or eth0 in the above example).

Registering your ET/BWMGR License Key

When you receive your license key, you will need to register it before you can use it. Before you register it you should make certain that you've tested with the demo for long enough (several 6 hour tests are recommended) to make sure you don't have a hardware problem. If you find a problem with your hardware, you can get a replacement key, provided that you have not yet registered the license. Once you register your license, you will have to buy a replacement license, and you are only permitted to buy 1 replacement.

To register the license, you will need to be able to contact our server. If you can ping www.etinc.com then you have access to the server. Also, you will have to have UDP ports in the 4000-5000 range available. So if you have a firewall be certain that you "open up" the bandwidth management device to allow the registration information to pass. To register, from the command line do the following:

# bwmgr em0 register license_key

where em0 is the interface that you used to generate the serial number and license_key is the license you purchased from ET. If all goes well, you will receive a message such as "Registration Complete". Once you receive this message, you can reestablish your firewall and you will be able to restart the bandwidth manager without restriction.

Note that any time you receive an updated license key, or if you upgrade your OS or change hard drives you will need to re-register your software (you DO NOT need to re-register when upgrading versions of the ET/BWMGR drivers). If you re-register you will need to do it from the same IP address as you originally registered from. If you need to change the IP, you will have to notify ET so that we can authorize the change. Just send an email to support@etinc.com with your license_key or serial number and tell us you need to re-register with a different IP address.

Stopping the Bandwidth Manager

You can stop the bandwidth manager, which will stop it from limiting traffic with the following command:

bwmgr stop

Note that you shouldn't normally use this command unless there is something critically wrong. If you have bridging enabled, traffic will no longer be forwarded. If you are routing and not bridging, then stopping the bandwidth manager will just stop the functions of the software and revert to normal processing of traffic.

Rule Tutorial - What is a Rule?

A "rule" is a specification which defines what actions should be taken when events occur. In the context of the bandwidth manager, a rule is a description of a type of traffic, and a specification of what action to take when that traffic is encountered. The ET/BWMGR is controlled by "rules", which you will set up to allow the sofware to control your network traffic. Some products call these "policies". We'll use both terms.

Rule Syntax

The bwmgr rule syntax is very extensive, and will be illustrated throught this document in the appropriate section. The base syntax for adding rules can be summarized in the following:

bmgr interface [-x rulenumber] criteria [bandwidth controls] [-priority priority_selector]

where criteria is the match critera and the default priority is "normal". Basic criteria includes the following:

-name                           name (a label) for the rule               
-x                              index (precedence) of the rule
-r                              reverse rule               
-l                              enable logging               
-fw                             firewall rule               
-saddr {ip_address}             source IP address               
-daddr {ip_address}             destination IP address               
-addr {ip_address}              either source or destination IP address
-smaddr{ mac_address}           source MAC address               
-dmaddr {mac_address}           destination MAC address               
-maddr {mac_address}            either source or destination mac address               
-nameaddr {hostname}            name address (virtual host)               
-url {url}                      matches URL text for http and ftp requests               
-prot {ip_protocol}             IP protocol (ie TCP, UDP, ICMP)               
-mprot {mac_protocol}           MAC protocol               
-dport {port}                   destination port               
-sport {port}                   source port               
-port {port}                    either source or destination port               
-portrange {startport endport}  port range from startport to endport               
-priority {priority|type}       priority or type of rule               
-global                         specifies a global rule 

Throughout this document the above criteria will be illustrated along with details of their use. First, some basics.

Rule Precedence

Each rule has an "index", which is a number which defines its precedence. The lower the index, the higher the precedence. Rules are processed from low to high. Generally, once a rule "hits", processing stops and the action specified by the rule is carried out, with the exception of global and log-only rules. Use the -x parameter to specify an index:

bwmgr em0 -x 300 ...

specifies an index of 300. If you add a rule without specifying an index, it will automatically select an index for you at the end of your ruleset, with one exception......

Large Rule Indexes

Auto-indexing will not consider rules with indexes of 1 million or greater when determining the next highest index. This allows you to specify rules that MUST be at the end of your ruleset with high indexes that will always be at the end unless you manually place one higher. For example, suppose you have 2 rules:

bwmgr em0 -x 100 -addr 10.1.1.1 -bwboth 256000
bwmgr em0 -x 1000000 -ipprot allip -priority discard

if you were to add a rule without an index specified, the rule would be added at index 200, so your rule 1000000 would still be at the end as required.

Global Rules

Global rules are a new concept in v3.24. Previously, rule index precedence was absolute. With global rules, its possible for a data frame to match multiple rules, which is useful both for statistics and control. Global rules are set with the -global tag. As as example, consider the following:

bwmgr fxp2 -x 100 -ipprot tcp -global
bwmgr fxp2 -x 110 -ipprot telnet -global
bwmgr fxp2 -x 120 -ipprot 10.1.1.1

Now suppose a telnet packet originating from 10.1.1.1 is received. Without global rules, the packet would "hit" on rule 100 and stop there. But since 100 and 110 are global rules, in this case 100, 110 and 120 all will "hit".

Note that is makes no difference where the global rule is located in the ruleset; a global rule will always hit on a match, so the following:

bwmgr fxp2 -x 110 -ipprot telnet -global
bwmgr fxp2 -x 120 -ipprot 10.1.1.1
bwmgr fxp2 -x 300 -ipprot tcp -global

would make no difference; all 3 rules would "hit". Note however the following case:

bwmgr fxp2 -x 300 -addr 10.1.1.0 -addrmsk 255.255.255.0 -global
bwmgr fxp2 -x 310 -addr 10.1.1.1
bwmgr fxp2 -x 320 -ipprot tcp

In this case, the telnet packet would only hit on 300 and 310, since rule 320 is not global. Only the first non-global rule will hit, and it does so by rule precedence.

Naming Entries

Names function as aliases to rule numbers and are used to uniquely identify rules (out of the scope of the interface) for links with other rules. Names must be unique for the entire system. If you will be graphing the data from a particular rule (see the -stats option below) you MUST name it. Also note that names are case insensitive in the database, so if you have rules named "ACME" and "acme" they will be considered the same for graphing (and it will cause problems). Groups must also be named, as must reverse rules. In order to modify or view a particular rule, you need to specify the index number or the name that is assigned to the rule when you create it. To make things easier, you can name entries and use the name to modify or refer to specific rules without having to know the index number. To name an entry, use the -name option:

bwmgr em0 -name GenMotors -x 300 ...

the above entry will associate the name, GenMotors with this rule 300. So, for example, if you wanted to modify this rule in the future, you could simply do the following:

bwmgr em0 -name GenMotors ...criteria...

Note that names must be no more than 16 characters long and cannot include spaces or any other special characters other than a dash or underscore. You also should not use periods.

Specifying Hosts and Network Addresses

You can also specify host addresses and networks with bwmgr to limit the amount of bandwidth that a specific host or network could use. This is done as follows:

bwmgr em0 -addr 207.11.14.1 -bwout 56000 -bwin 56000

This would limit the traffic from and to host 207.11.14.1 to 56000bps. Similarly, an address mask can be used to specify an entire network or sub-network:

bwmgr em0 -addr 207.11.14.0 -addrmsk 255.255.255.0 -bwout 56000 -bwout 56000

This would limit the bandwidth of all of the devices on network 207.11.14 to an aggregate of 56000bps. You can also use host/domain names for specific hosts. For example, to limit traffic of a specific host by name:

bwmgr em0 -addr www.sumdomain.com -bwout 128000 -bwin 128000

Note that if you use internet host.domain names, the name is simply resolved to a host address. So if you do

bwmgr em0 -addr domain.com ...

the rule will be equivalent to

bwmgr em0 -addr 10.1.1.1 ...

assuming that domain.com resolves to 10.1.1.1. No attempt is made to resolve numbers to hosts, so in your configuration files the numeric IP address will be used.

MAC Address Rules

You may want to lmit an entire physical machine, or a customer by his router's MAC address. Assuming that you know the MAC address of the specific machine, you can specify the MAC address using the -maddr option in the same way that you can limit by IP address. For example:

bwmgr em0 -maddr 00:00:c0:a2:ca:bc -bwin 64000 -bwout 64000

The above example would limit all of the traffic to and from the host with MAC address 00:00:00:c0:a2:bc to 64kb/s. MAC rules match all of the traffic from or to the specified MAC address, including non-IP traffic. Alternatively, you can use -smaddr and/or -dmaddr to limit to or from or to control a specific connection. For example:

bwmgr em0 -smaddr 00:00:c0:a2:ca:bc -dmaddr 00:00:c0:01:01:01
bwmgr em0 -maddr 00:00:c0:a2:ca:bc -bwin 64000 -bwout 64000

The above rule pair would limit all of the traffic for MAC 00:00:c0:a2:ca:bc except traffic going from this address to 00:00:c0:01:01:01.

Grouping Bandwidth Entries - Creating a Group

If you want to define a disjoint group of addresses, you can use the "Group" feature to create a group. To define a group, define a named group entry, and then link the other entries to that name of the head entry. For example:

bwmgr em0 -name losers -group -bwboth 128000
bwmgr em0 -addr 207.11.1.4 -bwlink losers
bwmgr em0 -addr 207.11.17.2 -bwlink losers
bwmgr em0 -addr 207.11.17.3 -bwlink losers

the above would create a group with the 3 specified addresses which would all have the same aggregate bandwidth limits, as if they were all in one rule. . Note the use of the -name parameter for the initial (group) entry. You must use the name of the entry when linking to a group head (previous versions allowed the index to be used). Using the name allows for group members to be on different interfaces. Note that if you delete the Group entry the other entries will continue to exist with an unattached link, and they will re-attach when a group rule with the proper name is added. You should avoid deleting group entries when possible, as the remaining rules will work differently (in the above case they will get unlimited bandwidth) when they are not in the group.

More powerful use of groups is discussed in the Group Bandwidth Management section below.

Managing Traffic by Data Type with bwmgr

Traffic can be identified by "traffic type" as well as by previously described IP or MAC addresses. Traffic types can also be specified along with addresses to identify specific traffic sent by or to specific hosts or customers. Traffic types supported are:

Mac Protocol
IP Protocol
TCP or UDP Port
Specials

We will describe each below.

MAC Protocol Rules

The "MAC protocol" is the "ethernet type" in an ethernet frame. While virtually all of your "internet" traffic is IP, you may have many other types of traffic on your LAN. If you have co-located customers, if you are bridging your traffic to remote locations or if you just want to control certain types of LAN traffic, the MAC protocol can be used to identify such traffic. The syntax for specifying MAC traffic is as follows:

bwmgr em0 -mprot Protocol

Where "Protocol" is the hexidecimal representation of the ethernet type (ie 0x800 or 800 for IP, 0x806 or 806 for ARP, etc). The more common MAC types (IP, ARP, IPX) may be specfied by keyword.

There are 2 special types. First is "-mprot vlan", which matches all vlan tagged traffic. Note that such rules will only match vlan encapsulated traffic that contain the vlan header. The second is "-mprot 802.3", which is "typeless" ethernet traffic. Some older protocols (and IPX implementations) may specify the length instead of the protocol type. Specifying 802.3 will match all such traffic, regardless of the higher level protocol.

VLAN (VPN) Rules

You can also Match based on the vlan tag (ie the vlan ID number) using the -vlan option. For example:

bwmgr em0 -vlan 128 -bwboth 256000

will limit traffic containing vlan header info for vlan 128 to 256000. Note that -vlan implies -mprot 0x8100 and that any other setting of -mprot is not valid.

IP Protocol Rules

All IP traffic has an IP protocol. The most common IP protocols are TCP, UDP and ICMP, but there are many more. Most likely, you will not encounter anything different than the "big 3". Other IP protocols are listed in the file /etc/protocols on most unix-like installations.

To match traffic with a specific IP protocol, use the -ipprot (legacy -prot is also supported). The following are examples of how to match "the big 3":

bwmgr em0 -ipprot UDP
bwmgr em0 -ipprot ICMP
bwmgr em0 -ipprot TCP

Note that port-defined and special internally defined protocols can also be specified with the -ipprot setting. These are discussed in the protocol engine section later in this document.

IP TOS Rules

You can use a mask to match bits in the TOS field of ipv4 packets with the -iptos option. Since TOS is used in many different and sometimes non-standard ways, it is your responsibility to set the mask according to whatever scheme is in place on your network. Note also that this HEX value Matches the entire TOS octet, meaning both TOS and priority fields. For example:

bwmgr em0 -iptos 0x18 -gpriority 8

The above rule will set the global priority (explained later) to 8 for any packets containing either the LOW_DELAY (0x10) or THROUGHPUT (0x08) bits. This implies that 0x10, 0x08 and 0x18 and 0x1E will all Match.

IP Protocol Port Rules

While you *can* use ports in rules to match traffic, its more efficient to use protocol mappings than to use ports. Virtually all port matching has been antiquated by the v3.3 protocol engine. You can still use -port to match a port if the protocol isn't defined, but its recommended that you use -ipprot in most cases.

"Special" Protocol Definitions

There are several "special" ip protocols defined that arent really IP protocols at all, but they can be quite useful. "Special" protocols are specified with the -ipprot syntax, although some of them actually combine protocols and ports. They represent special cases that are common and they are not definable by protocol and port alone:

*These are described in detail in "Advanced Topics" below

Note that user-defined protocols can be added to this internal list of protocols using the "loadprotocols" and /etc/bwmgr-protocols file. See a description of the protocol engine later in this document.

URL Rules

URL rules are special rules that look into HTTP and FTP frames and seek requests for specific pages or files. URL rules specifically match 2 types of traffic: HTTP GET or POST requests for specific URLs and FTP RETR requests. These can be useful in filtering known attacks (ie default.ida or root.exe) and also for controlling downloads of specific pages or specific types of pages. Suppose Microsoft just released IE 12.0. You could limit only downloads with a "-url iesetup12" rule possibly. Or "-url .exe" to limit all excutables.

URL rules with "track" any session that is encountered using the URL. So, for example, if you wanted to limit the download or tarballs, you could use:

bwmgr em0 -url .tgz -bwin 64000 -bwout 64000

This would be all that would be necessary to limit the entire download of any file containing ".tgz". ".mp3", ".mpg", ".avi", ".wmv" are other useful choices.

URL rules may contain spaces. If a url contains spaces, it must be enclosed with quotation marks:

bwmgr em0 -addr 10.1.1.1 -ipprot smtp "From: nobody"

As you might gather from above, the url spec is also used within SMTP content sniffing, which is described in the next section.

Its also notable that url rules can be useful as triggers for firewall deny type rules. Suppose, for example, the old "form.pl" virus were to appear again. You could block any such use with:

bwmgr em0 -fw -url form.pl -priorty fw-deny

SMTP Content Sniffing

URL rules can also be used in a special case to look into SMTP packets. This can be somewhat useful in controlling an SMTP attack, or if you are getting spammed by someone and there is a particular message within the packet that you can match. It does require a bit of overhead, so it probably shouldn't be used for a general bandwidth management policy.

bwmgr em0 -x 1000 -daddr 10.1.1.1 -ipprot smtp -url "user unknown" -fw -r -priority fw-deny

The above will create deny rules when a mail server at 10.1.1.1 sees an SMTP message with "user unknown", which will block the server for 5 minutes (the default reverse timeout). Note that case must match.

Also note that "discarding" SMTP rules doesn't always have the expected effect. By the time you receive whatever text you are looking for in an SMTP session, the session is well underway. Dropping a packet from the session will only cause the sender to retry at a later time. So while you may use these rules to detect a server sending you something you don't want to receive, but its not something that will solve the problem for the long run.

Virtual Host Rules

If you are using name virtual hosts you may have many virtual hosts assigned to the same IP address, in which case limiting the IP address may not be flexible enough. You can use the -nameaddr option to specify a host by name. Note that this feature uses the HTTP header information to determine which host is being accessed, which clearly implies that it will only work on http traffic (AND HTTP 1.1 headers are required). For example:

bwmgr em0 -nameaddr www.thishost.com ...

The above rule will match http traffic with a host header specifying www.thishost.com. Note that the entire string must match. So if this host could also be addressed as "thishost.com", you could use "-nameaddr thishost.com" which would match both "www.thishost.com" and "thishost.com", but also "anthingelse.thishost.com". -nameaddr rules are special rules which use internal stream tracking to "keep track" of the traffic associated with a name address rule. There is no need (in versions 3.22n and later) to use reverse rule syntax with these rules.

Enabling and Disabling Rules

You may want to disable a rule temporarily to allow someone into your network or allow someone out. To disable a rule, use the following syntax:

bwmgr em0 disable ####
bwmgr em0 disablefw ####

where #### is the rule number to disable. disablefw is used to disable firewall rules. Note that disable internally flags the rule as disabled, and you must use enable to re-enable the rule (unless you delete it and re-add it of course). To reenable a rule or to change its I/O flags, use the enable keyword:

bwmgr em0 enable 1000
bwmgr em0 enable 2000 i
bwmgr em0 enable 3000 o
bwmgr em0 enable 4000 io

for the above commands, rule 1000 will be enabled as Incoming and Outgoing (the default), rule 2000 as incoming only, rule 3000 as outgoing and rule 4000 as both. There is no danger in enabling a rule which has not been disabled.

Enabling and Disabling Rule by Time of Day

Rules may optionally be given an "enable time" and "disable time", allowing you to specify when the rule should be active. You may want rules that are only active during certain hours of the day, or only during the week. The default setting is for a rule to be active all of the time. To set up other times, use the following syntax:

-timeon XXX-H-0 -timeoff XXX-H-0

where XXX is either ALL (for every day), WEO (for weekends only) or WDO (week days only), and H is the hour of the day in military time (0-23). Only full hour settings are currently supported, so the 3rd parameter must be set to zero. As an example:

bwmgr em0 -x 100 -addr 10.1.1.1 -timeon ALL-8-0 -timeoff ALL-17-0

The above setting would enable this rule at 8AM and disable it at 5PM every day. Note that the XXX setting must be the same for both -timeon and -timeoff. Also note that both must be used, as one has no meaning without the other.

Time management is performed by the bwmgrd daemon, so it must be running in order for rules to be enabled and disabled.

Changing Bandwidth Settings

If you just want to change the bandwidth settings on a rule, you can use the -changebw to indicate that you are changing the bandwidth on an existing bandwidth rule (don't use this on a rule that doesn't have a bandwidth setting). When you issue a rule by name or index, if there is an old rule with the same name it is actually deleted, and then the new rule is added. If you are gathering stats, this can disrupt the counts and cause some information to be lost. The -changebw option will change the -bwin, -bwout, -bwboth, -bwmin and -bwburst settings safely without affecting any other settings or indexes.For example, suppose you had the following rule in place:

bwmgr em0 -x 3000 -addr 100.1.1.1 -ipprot tcp -port www -bwin 64000 -bwout 64000

and you then issued the following:

bwmgr em0 -x 3000 -changebw -bwin 128000 -bwout 128000

the resulting rule would be

bwmgr em0 -x 3000 -addr 100.1.1.1 -ipprot tcp -port www-bwin 128000 -bwout 128000

Note that all of the matching criteria (address, protocol, port) remain.

Notes on Logging

Any rule can be given the "-l" option to enable logging. Note that logging requires that information be written to the system logging system and that the information be written to a file. While logging can be a powerful tool for debugging or intruder detection, you should be aware that excessive logging can and will eat up your systems resources. If, for example, you set a bandwidth rule for a host and enable logging, every single frame that goes to or comes from that host will be logged, which is unacceptable. More acceptable uses of logging might be as follows. Suppose you wanted to know what connections a specific employee of yours was making. You could use the following:

bwmgr em0 -addr 207.14.172.1 -prot tcpconnect -l

The above rule would log all TCP connect requests from host 207.14.172.1.

The information from rules with logging enabled will be sent to LOG_INFO in FreeBSD (kern.info in syslogd) and KERN_DEBUG (kern.debug in syslogd) in LINUX. "Usually", the defaults for these are the file /var/log/messages.

The ET/BWMGR Protocol Engine

Version 3.3. introduces a completly remodeled internal protocol engine. All port to protocol mappings are under user control, and groups of ports are maintained internally in a much more efficient manner than using external rules. This allows you to customize the port to protocols mapping to fit your particular needs.

Internal Protocols:

Many protocols are defined internally, and you can use any internally-defined name in a rule. To get a list of available protocols, use the command:

bwmgr getprot all

This will display all of the protocols defined by the system.

User Defined Protocols: /etc/bwmgr-protocols

Users can define protocols by manipulating the /etc/bwmgr-protocols file. This file is included in your system distribution with many well-known default settings. Using the protocols file, you can define which ports should be mapped to a specific protocol. This allows you to group ports in a much more efficient manner than using groups of rules. The syntax for /etc/bwmgr-protocols is:

port tcp||udp protocol-name

so to define the protocol "myprot" on udp port 11472, you'd use:

11473 udp myprot

Now suppose that ports 11474 and 12800 also were used in this protocols, you could add the lines:

11474 udp myprot
12800 udp myprot

and now when you used the rule:

bwmgr em0 -x 5000 -addr 11.1.1.1 -ipprot myprot -bwprofile lotsabandwidth

the rule would match on ports 11473, 11474 and 12800.

The /etc/user-protocols files is the same format as the bwmgr-protocols file. Its recommended that you define your protocols in the user-protocols file, so that you can use the standard protocols that we include with each release. We'll be updating bwmgr-protocols regularly so any changes you have made with be lost if you want to use our newer file.

The loadprotocols command

To read protocols into the bandwidth manager system, use the loadprotocols command as follows:

bwmgr loadprotocols

This command is included in your rc.bwmgr file when you do a rebuild or when the GUI rebuilds the file. loadprotocols reads 3 files in the following order:

/etc/protocols
/etc/bwmgr-protocols
/etc/user-protocols

/etc/protocols defined your actual IP protocols (the ip_p field in an IP packet). bwmgr-protocols and user-protocols read user-defined port mappings as decribed above. Note that later settings will override previous settings, so if you have:

1000 tcp http

in bwmgr-protocols and

1000 tcp someprot

in user-protocols, port 1000 will be mapped to someprot.

Using the Protocol Module

Version 3.3 introduces a protocol module which can be loaded into your system to implement in-line user protocol definitions. The protocol module is located in /usr/bwmgr/protmod. An example module which can be used as a model is included. Note that the protocol module can be very powerful, and can also crash your system with the smallest bug or misuse. So use it very carefully and don't put anything into production until you've thorougly tested your code.

Setting up the Firewall - Theory of Operation

Beginning with v3.2, the ET/BWMGR software incorporates a firewall function which is separate from the bandwidth management and priority rules. Each manageable interface on your system can optionally have a firewall, which can help you to control the flow of traffic to and from your network.

The purpose of a firewall is to decide which packets are allowed to pass through the network and which packets are not allowed. The default is to allow all traffic. So, if you have no firewall rules enabled, all traffic will pass through the firewall. Typically, you will add rules for traffic that you want to "firewall", or filter, from getting into your network. For example, suppose you don't want anyone on the outside world to access your server whose IP address is 207.11.14.1. You could do the following:

bwmgr em0 -fw -addr 207.11.14.1 -priority fw-deny

the above syntax selects interface em0 (which would have to be the interface connected to the outside world), uses the -fw flag to specify a firewall rule, and selects the address as the match criteria. The "priority" for firewall rules can be fw-deny, fw-allow or log-only. log-only rules will be discussed later. For now, you can either set a rule to allow, or to deny passage through the firewall. The above rule will cause all traffic to or from 207.11.14.1 to be discarded. This results in this address being inaccessable from outside of interface em0.

Firewall Criteria

Firewall criteria can be selected based on IP address or MAC address (source, destination or either), port, port range or protocol. Combinations are also allowed, so you can do thing like "allow all traffic if the source IP is X and the source MAC is Y, or allow traffic from IP A to IP B but not from IP C to IP B. You can use combinations of rules to achieve your more complex goals. For example, suppose you wanted to deny access to all ports over 1024 on a particular system but allow access to port 4718. You could use the following:

bwmgr em0 -x 99 -addr 207.11.14.2 -port 4718 -priority FW-Allow
bwmgr em0 -x 100 -addr 207.11.14.2 -portrange 1024 65535 -priority FW-Deny

Because rule 99 is before rule 100, it will be checked before rule 100, so you have effectively excluded port 4718 from the range in rule 100.

Firewall rules use the same criteria as all other rules, except that bandwidth management and statistical parameters are not allowed.

Viewing Firewall Rules with bwmgr

Use the "showfw" command with bwmgr to display firewall rules:

bwmgr em0 showfw

Packets Per Second Firewall Rules

A special firewall rule allows you to limit the packets per second (PPS) of any type of traffic to prevent overloading of your network and also to twart DOS (Denial of Service) attacks.When the PPS of the traffic matching a PPS rule exceeds the setting, all addition traffic will be dropped for the current time window. The syntax of a PPS rule is specified with the bwmgr utility with the -ppsin -ppsout -ppsboth options

bwmgr em0 -fw -ppsin 5000 -ppsout 5000 -priority fw-deny

The above setting would limit the PPS incoming to 5000pps and outgoing to 5000pps individually. To limit the combined PPS, use the -ppsboth option instead:

bwmgr em0 -ppsboth 7000

You can also limit the PPS of specific types of traffic, or traffic to or from a specify host. For example:

bwmgr em0 -ipprot ICMP -ppsin 1000

The above rule would limit imcoming ICMP packets to 1000pps, which would help thwart Ping attacks or other ICMP indications caused by other types of attacks.

Positioning of Packets Per Second Rules

PPS firewall rules monitor activity but will not cause a "hit", which means that other rules after them in precedence will continue to be checked. However, if they are placed after other rules that "hit" then they will not be checked. So your PPS rules must be at the beginning of your firewall ruleset, and should be before all other rules.

Packets Per Second Suggestions

You may not know what "safe" or "normal" PPS levels are on your network, so you should first use "benign" pps rules to monitor your network activity before setting your FW-Deny rules. "Benign" rules are PPS rules with a specification of FW-Allow, which means that they dont do anything even if the the specified level is exceeded. Also, when displaying PPS rules with the GUI or with "showfw", the maximum level of packets per second encountered is displayed. By using a benign rule for a few days, you could check to see what the maximum PPS levels are on your network over that time period. For example:

bwmgr em0 -ppsin 50000 -ppsout 50000 -priority fw-allow

sets a rule for monitoring overall packet per second on the interface. You must set the values to a number that is larger than you ever expect to see, as you will not receive counts when it hits this value. When you display this rule, it will display the "PPS-HIGH" value, which is the max number of PPS that were received since enabling the rule.

#bwmgr showfw 1

1 PPS-IN: 50000 PPS-OUT: 50000 PPS-HIGH: (1278/640) Priority: FW-Deny (1234321/0) <IN OUT>

When displaying the rule, it shows the setting and also indicates that the high PPS count encountered was 1278 packets per second incoming, and 640 outgoing. You can use this info to determine the normal high levels present on your network.

Log-only Firewall Rules

Firewall rules can be given a priority of "log-only", which means that a log entry will be written when the rule matches, but subsequent rules will still be checked. It is important to position log-only rules before allow/deny rules, because once an allow or deny rule hits, then no more rules will be checked. A good strategy is to put all of your log rules at the beginning.

Example:

bwmgr em0 -x 10 -fw -prot tcp -port snmp -l -priority log-only

note that you must specify -l to enable logging, it is not automatic.

Reverse Firewall Rules

Reverse firewall rules allow you to use a "trigger rule" to block host addresses based on some action. There rules are described in detail in the reverse rules section below.

Setting up Bandwidth Management Rules

Setting Bandwidth Rules and Limits with the bwmgr utility

Bandwidth managment rules allow you to customize the way that certain traffic flows through your network. The following section describes how to use the bwmgr utility to set up your bandwidth management criteria.

Shared vs Allocated Bandwidth

All bandwidth that is not guaranteed is considered by the ET/BWMGR to be "shared" bandwidth. What this means is that bandwidth that is not used by one rule or policy may be used by any other rule on a demand basis. Guaranteed bandwidth must be allocated for a specific policy and will not be available to other policies.

Allocated Bandwidth vs Minimum Bandwidth

"Allocating" bandwidth is a meaningless concept unless there is a finite pool from which to allocate from. If a rule with a minimum bandwidth allocation is a member of a Group, the bandwidth must be "allocated" from the Group's bandwidth pool, in order to guarantee that other members can't use it. A rule that is not a member of a group will have its bandwidth allocated from the pool of bandwidth available to the Interface. The Group or Interface is said to be the rule's "Container", because it defines the amount of bandwidth available to all of the "members" within its scope. If there is no bandwidth allotment for the rule's Container, then the bandwidth can not be "Guaranteed", because there is no reference to the amount of bandwidth available. In this case, the "guaranteed" bandwidth is simply a minimum bandwidth setting.

Auto-Shaping

Version 3.23 adds an "auto-shaping" feature designed to automatically manage network congestion without any "rules" whatsoever. Auto-shaping can be used alone or in co-ordination with any other settings.

To enable auto-shaping, simply set -autothresh on an interface:

bwmgr em0 -ifac -autothresh 5800000

Note that auto-shaping is a pacing mechanism only and will not apply any hard limit or delay any traffic. So your bandwidth will likely be higher than the threshold, but your congestion (ie backup traffic, queue depths, etc) will be much less.

Setting Hard Limits - Allocating Shared Bandwidth with a Rule

The simplest type of bandwidth management rule is the hard limit. Hard limits set a ceiling on the amount of data that a host or type of traffic can use, and will regulate it at the ceiling when operating over the limit. This effectively simulates any data rate you choose regardless of the medium. Limits can be set for incoming or outgoing traffic, or for incoming and outgoing combined. For example:

bwmgr em0 -x 500 -addr 100.1.1.1 -bwin 56000 -bwout 128000

This command sets a bandwidth limit of 56000bps for incoming traffic and 128000bps for outgoing traffic. Remember that "incoming" traffic is traffic received on the interface, so if you have a 2 interface system it will be the opposite on the other interface. To set a combined setting, use -bwboth as follows:

bwmgr em0 -x 500 -addr 100.1.1.1 -bwboth 64000

This setting will allow the total of incoming + outgoing traffic to be no more than 64000bps.

Minimum Bandwidth Allocation

"Allocating" bandwidth can be achieved by setting a bandwidth minimum, which defines the minimum data rate that a host or traffic type will get before any action will be taken on the data stream. When the rules container (ie Group tag rule or Interface) has a bandwidth setting, this setting will represent "guaranteed" bandwidth. Without an interface or Group setting, this value represents bandwidth that will be considered high priority. For example:

bwmgr em0 -ipprot udp -port 15100 -bwmin 64000

Suppose you have VoIP running on udp port 15100. The above setting will set the minimum bandwidth to 64kbs for the port, giving it the highest priority until the minimum is exceeded.

bwmgr em0 -ifac -bwin 1544000 -bwout 1544000
bwmgr em0 -ipprot udp -port 15100 -bwmin 64000

With the above 2 rules, the -bwmin represents a bandwidth guarantee out of the 1544000bps allocated for the Interface.

You can mix all of the bandwidth settings in a single rule. Note that -bwmin and -bwburst (discussed below) inherit the "combined" attribute if -bwboth is specified. So, for example, if -bwboth is specified, then -bwmin and -bwburst apply to the combined (incoming + outgoing) total, if -bwboth is not set, then it applied for each direction.

Burst Settings on the ET/BWMGR

The ET/BWMGR bursting feature allows 2 levels of limits for each defined rule. This allows you to throttle traffic in a precise manner only when a specific condition is met. In order to define a burst bandwidth allocation for the rule, you must define two parameters, the burst limit and the burst trigger.

The burst limit is defined by the -bwburst parameter for a rule. The "trigger" is defined by the -bursttrig parameter.

Defining a Burst Trigger

Any rule or interface can be a burst trigger. A "burst trigger" is a bandwidth level threshold that is used as a criteria for determining whether a particular rule is allowed to "burst" to its burst setting, or whether it should be limited to its "normal" setting. You define a particular rule as a trigger by setting a burst threshold for the rule. For example:

bwmgr em0 -ifac -burstthresh 1000000

This sets the interface em0 as a burst trigger. Any rule that defines fxp0 as their burst trigger will use their -bwburst setting when the traffic level on em0 is under 1Mb/s, and their regular bandwidth limit when fxp0 is above 1Mb/s. Similarly:

bwmgr em0 -x 3000 -name fools -group -burstthresh 800000

This rule defines a group with a burst limit of 800000bps. So any rule that defines "fools" as their burst trigger would burst when the traffic level of Group "fools" was under 800000bps. For example:

bwmgr em0 -x 100 -addr 211.14.1.1 -bwin 64000 -bwout 64000 -bwburst 256000 -bursttrig fools

The above rule specifies that traffic to and from address 211.14.1.1 will be controlled at 64000bps if the usage level of the group "fools" is over 800000bps, and that 211.14.1.1 will get 256000bps when "fools" is below 800000bps.

Setting the Maximum Burst Duration

The -burstmax parameter allows you to set a maximum length of time that a rule can burst. This is designed to prevent long downloads or uploads. With a burstmax setting of 10, for example, the rule with allow "bursting" (which is activity over the standard bandwidth setting) for 10 seconds, and then will not allow bursting again until the rule has activity under its normal bandwidth allotment. So with a continuous download, the rule will be limited to its regular bandwidth setting (non-burst) until the transfer is completed.

Changing The Burst Reset (unburst) Period

Rules using the -burstmax setting need a criteria for determining when the traffic has subsided adaquately. The default setting is 10 seconds. What this means is that once a rule has bursted for its max burst period, the traffic must slow below its non-burst limit for at least unburst seconds before its allowed to burst again. To change the unburst setting, use the following:

bwmgr unburst 20

Defining a Burst Limit for a Bandwidth Rule

Each rule can be given a -bwburst setting which defines the maximum amount of bandwith the rule can use when the burst trigger is below its threshold. When traffic levels on the burst trigger are above the threshold, bursting is disabled. When traffic levels are below the threshold, bursting is enabled. Note that starting in v3.21, the "default" burst is wire speed (ie no limit). In previous versions if you didnt specify a -bwburst setting for a rule, the default was to limit to the normal bandwidth setting all the time. Now you must explicitly set the -bwburst. For example:

bwmgr em0 -ifac -burstthresh 1000000
bwmgr em0 -x 800 -addr 100.1.1.1 -bwin 56000 -bwout 56000 -bwburst 512000-bursttrig em0
bwmgr em0 -x 900 -addr 100.1.1.2 -bwin 128000 -bwout 128000
bwmgr em0 -x 1000 -addr 100.1.1.3 -bwin 128000 -bwout 128000 -burstmax 20 -bursttrig em0

The above settings would set the burst threshold to 1000000bps on interface em0. The second setting (-x 800) would set traffic to and from address 100.1.1.1 to 56000bps when traffic on the interface is above 1Mb/s, and to 512000bps when traffic is below 1Mb/s. The third rule (-x 900) sets a hard limit on address 100.1.1.2 to 128000bps (no -bwburst setting). The third rule (-x 1000) allows bursting to wire speed (ie no bandwidth limit), with a below-threshold limit set to 128000bps, and a maximum burst duration of 20 seconds.

Note that bursting is effectively disabled for a rule if no burst trigger is defined.

Setting Asymetrical Burst Rates

If you want to set different burst rates from each direction, you will have to create two rules. Normally you can create a single rule which controls traffic in both directions, but bursting follows the "both" flag, that is its either the same for both directions or it uses a combined value. Typically you are really only controlling traffic in one direction (in for "client" traffic and out for "server" traffic), so it doesnt much matter. But if you want different burst rates in different directions, simply create an incoming rule with the "in" settings, and an outgoing rule for the "out" settings. For example:

bwmgr em0 -o -addr 10.1.1.1 -bwout 128000 -bwburst 512000 -bwmin 32000
bwmgr em0 -i -addr 10.1.1.1 -bwin 512000 -bwburst 768000

The above -i and -o flag tell the ET/BWMGR to only enforce the rule in the appropriate direction.

Setting a Burst Period

The "burst period" is the window within which the BurstManager will gather bandwidth information about a trigger and enable or disable bursting. Traffic usage is continuously averaged over the period. Longer periods may increase the amount of time that rules may burst, as the longer into the period high activity begins, the longer it will take the average to reach the threshold. Note that values under 10 seconds are not recommended.

Interface Level Bandwidth Control

You may want to limit a complete interface to a specific amount of bandwidth, regardless of the traffic type. You can set a bandwidth limit for the entire interface by specifying the -ifac option. For example:

bwmgr em0 -ifac -bwin 800000 -bwout 800000

The above commnad will set an overall bandwidth limit of 800000 in and out for the interface. This limit is absolute (except for pass-thru rules), so no more than 800000 would be allowed to pass regardless of other rules present. This implies that:

bwmgr em0 -ifac -bwboth 800000
bwmgr em0 -addr 10.1.1.1 -bwin 1000000 -bwout 1000000

with the above rules, host 10.1.1.1 would not be able to get more than 800000 even though its individual limit is higher.

Interface bandwidth limits are useful for defining how much actual bandwidth there is available at your network edge. For the purposed of priorities and bandwidth allocation, setting the outside interface (ie the adapter connected to your edge router's side of the network) to the bandwidth you have (such at 45Mb/s if you have a T3), or the maximum bandwidth you want to use. With an interface bandwidth limit, minimum settings become guaranteed bandwidth on the interface. Without an interface limit, you are only guaranteeing access to the local wire, which may not be what you want to do.

Note that if you have no rules on an interface, you could alternatively use:

bwmgr em0 -bwboth 800000

as a single rule which limits all the traffic on the interface without setting an interface limit.

TCP Rate Limiting

TCP rate limiting is a powerful bandwidth management technique that reduces the amount of traffic in your network and potentially slows each TCP session by reducing the TCP receive window. While some products on the market use rate limiting as their primary bandwidth management mechanism, there are undesireable results when windows are dropped too low, as overhead on your network in terms of the number of packets and bandwidth usage can significantly increase. Because of this, the ET/BWMGR uses rate limiting as one of several mechanisms to manage your network without having an adverse effect on overall traffic volumes.

Specifying a Minimum Window Size

When you set a rule with a bandwidth limit, the ET/BWMGR will use rate limiting as well as other techniques to slow the data rate to not exceed what you specify. However most servers do not honor window "granularity" in that they want to only send full windows of data if possible. Because of this, i f you are running a single session (say a download) on an IP address rule, you will see numbers lower than the limit. This is because the proper window setting for a session may be 1800, but the effective window is 1500 because of the full-window issue. If you have many sessions on a rule (such as a NAT'd client or a server), this is exactly what you want, as you want to force the sessions below the limit until a balance occurs. However if you need a single session to be able to attain the full bandwidth limit, you can specify a minimum widow to use so that the sessions will not be pushed below the point at which they can achieve full bandwidth throughput. For example:

bwmgr em0 -x 1000 -addr 10.1.1.1 -bwboth 512000 -tcpwindow 4500

The above rule will tell the rule to use not set a window below 4500 (which is 3 full packets). The ideal window size varies from connection to connection (depending on intrinsic delays), so there is no exact answer to what this setting should be. You can eliminate TCP window manipulation altogether by setting the window to 64000. While this may seem to be a good way to assure that any connection can reach any bandwidth limit specified, it also defeats one of the primary purposes of bandwidth management, which is to reduce the traffic flows in your network to reduce delays, avoid congestion and reduce the need to drop packets, so you need to weight your objectives carefully.

Per Session Bandwidth Management - Rate Limiting

TCP rate limiting effectively is a "per session" method of controlling traffic. Each TCP session within a container is automatically controlled. When you set a bandwidth limit, the default behavior of the software is to use an internal "adaptive window". The adaptive window algorithm attempts to reduce the window based on the traffic flows, setting it just where the traffic flows at the rate specified without excessive backup. The adaptive window will not go below 1 full packet (1500 bytes), so it will not increase the overhead on your network as some rate limiting products do.

You can effectively "shape" traffic without limiting it by creating a container with a bandwidth setting that is just below your available bandwidth. So for example, if you have 3Mb/s of bandwidth, you could rate shape all traffic with :

bwmgr em0 -ipprot tcp -bwlink GroupA -bwin 3000000 -bwout 3000000

While this may seem trivial, it in fact is quite powerful. The rule with Match all tcp traffic and limit it to 3Mb/s. But the effect of the adaptive window management is to slow each session equally to create overall fairness within the usage of the bandwidth limit. It will also maintain minimum flows, reduce the expectation that a drop will occur, and create a scenario with minimum delay for tcp traffic.

Of course window shaping only works on TCP traffic so you'll need other rules to control other traffic. But this illustrates how you can substantially improve your network flows with a minimum of controls.

Global Controls for Rate Limiting

By default, traffic is not shaped or limiting in any way unless you set a specific rule that matches the traffic type. In order to reduce overall traffic on your network, you could set an interface "default" tcp window, which would apply to all TCP traffic passing through the interface.

bwmgr em0 -ifac -tcpwindow 4000

This would establish a default minimum window of 4000 for all data frames passing through em0. This default is used if no other settings apply to the data frame. You can override the interface default with a -tcpwindow setting in an individual rule, however the interface window will also override the internal rate limiting parameters. For example:

bwmgr em0 -ifac -tcpwindow 4000
bwmgr em0 -x 1000 -addr 10.1.1.1 -bwboth 56000 -tcpwindow 1500
bwmgr em0 -x 8000 -addr 11.1.1.1 -bwboth 56000

With these 3 settings, address 10.1.1.1 would be limited to 56000bps and have a minimum TCP window of 1500, while address 11.1.1.1 would be limited to 56000bps and have a minimum window of 4000.

Packets Per Second Bandwidth Rules

Packet per second rules can also be used to control users. PPS rules create a loosely-defined bandwidth limit which adjusts for the possibility that many small packets can use up resources even at low bandwidth levels. Give that a maximum packet is (usually) 1500 bytes and a minimum is usually 60 bytes, you can use a pps rule to give a wide range of capability to an end user or application without giving them unlimited bandwidth. So the following:

bwmgr fxp2 -x 4000 -name AcmeCorp -addr 192.168.17.1 -ppsin 300 -ppsout 300

would limit the throughout of the specified address to 300 packets/second. This translates to a bandwidth limit of between 144000bps and 2.4Mb/s depending on the average packet size of their transactions. Note that there is no burst setting for packets per second rules.

Combining Global Rules for Bandwidth Management

Using global rules, you can set multiple control criteria for traffic that matches multiple rules. For example:

bwmgr fxp2 -x 1000 -addr 10.1.1.0 -addrmsk 255.255.255.0 -bwin 1000000 -bwout 1000000 -global
bwmgr fxp2 -x 1200 -addr 10.1.1.17 -bwprofile default

The above allows you to set a limit for a class C without having to create a group. Since rule 1000 is a global rule, it will be enforced in addition to rule 1200 for traffic matching .17. Previous to version 3.24, you could only have done this in a group.

Combined BW and PPS rules

Beginning with 3.24b, rules can have both bandwidth and PPS settings. This allows you to create a single rule that can control by both bandwidth volume and activity level.

bwmgr em1 -x 500 -addr 10.1.1.1 -ppsin 100 -ppsout 100 -bwin 512000 -bwout 512000

The above rule would limit address 10.1.1.1 to the EITHER 100pps or 512000bps. If all packets are 1500 bytes, a setting of 100pps could allow as much as 1.2Mb/s of bandwidth, which may be more than you want. So adding the bandwidth setting will ALSO cap the rule at 512000. This rule allows both criteria to be estabished in a single rule. With 60 byte packets 100pps allows for only 48Kb/s.

Using Bandwidth Profiles

Bandwidth profiles are templates that allow you to apply common settings to any number of rules.

What is a "Profile"

A profile is a bandwidth service description that can be referenced by name. The service components are as follows:

• bandwidth in (may be pps also)
• bandwidth out (may be pps also)
• combined?
• burst bandwidth
• bandwidth guarantee
• burst max (duration)
• burst trigger
• priority

Each "profile" has a name and a unique identifier, as well as time of day attributes. For Example:

The above profile defines a profile description named "default", which defines a profile of the same name. The Profile ID and Profile name are case-insensitive (ie Default = default). Typically, if the "When" field is "Always", it makes the most sense to have the profile ID the same as the profile name for simplicity. The bandwidth profile for this description is 256,000bps incoming, 256,000bps outgoing and no bursting. Note that all settings in profiles are K (not really Kilos, but 1000s, so 512 is 512000).

Defining Bandwidth Profiles

Profiles are defined from within the HTML GUI. See the ET/BWMGR HTML manual for info on how to define profiles.

Applying Bandwidth Profiles

To apply a profile to a rule, use the -bwprofile specifier.

bwmgr em0 -x 1000 -addr 192.168.17.11 -bwprofile default

The above would apply the settings of the current "default" profile to the rule, as if you had entered them individually. Note: In the CLI, do NOT specify any specific bandwidth settings in the same command with -bwprofile or you may get the wrong results. In the HTML interface, other settings are ignored when a profile is specified.

The Effect of Using Bandwidth Profiles

At first glance, bandwidth profiles might just appear to be a shortcut for entering rules. But they are much more than that. Profiles are a vehicle for managing large rule sets, and also for implementing large-scale SLAs (service level agreements). Firstly, profiles are not only applied when you create the rule. If you change a profile, ALL of the rules which reference the modified profile will be changed accordingly. So if you have hundreds of customers/users who are using the "default" profile, you can modify global behavior of all of them that reference a specific profile in a single operation.

Profile Transitions

Service levels often (and should) have a time component, and different settings may apply at different times of day. Using the "When" setting with profiles, you can define settings for different times of day:

The above settings define "night" and "early" times of day, with different profile settings for each. A profile is "applied" to all of the rules referencing it at the start time, which is 7AM for default_early and 7PM for default_night. Note that the stop time is not used for profile transitions, it is only a reference so that it can be determined if the profile is active at any given time of day. This implies that "holes" in your time settings are simply ignored: if you had set default_early to start at 7AM and end at 1PM, it still would be applied until 7PM because that is when the next transition takes place. Profiles cannot be turned "off", they are simple overidden by other transitioning profiles.

To take the service level implementation to the next level, you can define other settings that only apply on weekends. This requires that you set default_early and default_late to WDO (weekday only), and you define a third profile which references "default" to apply on weekends. For example:

Now the default service level has 3 settings, one for early times during weekdays, one for late times during weekdays, and one for weekends.

Implementing Tiered SLAs with ET/BWMGR profiles

A simple example of a tiered SLA (service level agreement) would involve defining profiles for various service levels, and then applying them to customers/users who subscribe to that level of service.

Using the above simplistic settings, you have 4 distinct levels of service that simplify the adding new customers.

bwmgr em0 -name cust_a -addr 192.168.17.1 -bwprofile default
bwmgr em0 -name cust_b -addr 192.168.17.2 -bwprofile default
bwmgr em0 -name cust_c -addr 192.168.17.3 -bwprofile silver
bwmgr em0 -name cust_d -addr 192.168.17.123 -bwprofile gold

Reverse Rules

"Reverse rules" are basically dynamic "Groups" that are created automatically by selection of a "trigger". The trigger can be any criteria, but is most usually a single packet which signals that a stream which needs to be controlled is being created. For example, suppose you wanted to limit "each host that accesses Server A" to 256kbs. You could use a reverse rule which triggers on a tcp_connect to Server A which would create a limit on that host (and optionally the port). Once this trigger is detected, you then know that a transfer is occuring on a specific address/port combination and a dynamic control could be put in place automatically.

Another example is a WWW server, where you may want to limit hosts accessing the site on a per session basis; that is to limit individual sessions to an address independently, either with a ceiling, a floor or on a shared, equal basis. This allows you so set up a rule which will limit EACH USER accessing a site to either a specific bandwidth or a percentage of the bandwidth dependent on how many users are currently accessing the site. Actually, reverse rules are better than limiting each session. Other products limit each TCP session to a host, but a host many open many simultaneous sessions (such as browsers typically do for gr