Introduction
Getting Started
Logging InÂÂÂÂ
General Administration
The Main Menu
Configuring Defaults
Setting the Outside Interface
Getting an Authentication Key
Starting The ET/BWMGR
Viewing and Editing Rules
Interface Rules
Bandwidth Rules
Creating Groups
Adding Comments
Reverse Rules
Name Address Rules
URL Rules
Time of Day Settings
Firewall Rules
Priority Rules
Adding Multiple Rules with Do Range
Setting Bandwidth Controls (Quotas)
ÂÂÂÂ
Introduction
The ET/BWMGR HTML interface provides a graphical interface for managing Emerging Technologies' appliances as well as a vehicle for viewing statistical analysis. The interface allows non-unix savvy administrators to effectively manage this powerful technology from any host with an HTML browser.
A prerequisite is that you read and understand the command line manual first. The GUI is just a tool that simplifies tasks and, although its easy to do simple things with the GUI without understanding what you are doing, you will not be getting the full benefit of the product's most powerful features if you don't understand the inner workings of our bandwidth management techniques, which you can only get from the command line manual. The GUI also assumes that you know the meanings for all of the fields for creating rules.
The structure of this manual is as a guide to utilizing the graphical interface with an expectation that you understand the options and settings available on the command line. The GUI is, after all, just a tool for entering commands in a more intuitive manner.
Logging In
The ET/BWMGR GUI implements security in the form of "session IDs", which are created when a user successfully logs into the system. The start-up page provided is a page namedbwadmin.htm which has 2 fields, a user name and password. The system uses unix system names and passwords to authenticate rather than implementing a separate mechanism. Currently, only users that are members of the "wheel" group or the "bwadmin" group will be granted access to the bandwidth manager administration pages.
For initial access, enter a Username of admin and a password of saturn5 press the "Log In" button.
The Main Menu
The main menu provide details about your system and up to 4 graphs of your choice.
The BWMGR column
This column shows information about the installed software and the licensing of the system. The fields can be described as follows:Hostname - The name of the system, set by the hostname command.
Current Time - The time of the last screen update.
Last Boot - The time of the last system boot.
BWMGR Status - The current status of the bwmgr module. Running or Not Running.
Bridge Status - The current status of the bridge as it relates to the bwmgr. Running or Not Running.
Version - The version of ET/BWMGR running on the system.
License - The license level running on the system.
BWMGRD Status - The current status of the bwmgrd monitor appliacation. Running or Not Running.
Interface - The default interface.
Throughput - The traffic throughput on the default interface.
The Resources column
This column shows some resource information currently utilized by the system:
CPUx Usage - The usage percentage, 0 to 100, of the specific CPU. Up to 8 cpus are supported.
MySQL Usage - The percentage utilization of mySQL.
Free Memory - The amount of Free Memory available to USER processes. Note that this is the amount of memory in the free pool. Applications which are running that free memory do not release the memory into the free pool unless it is needed. So if this number is low, you can use top to determine with applications may be holding memory.
Memory Used - This is the amount of memory used by the BWMGR in the kernel. Depending on your setting for kern.vm.kmem.size, you can use this number to see if you need to allocate more memory to the kernel.
Buffers - This shows the current / high usage / max usage of packet buffers. If you're maxing out you may need to adjust your system settings.
Streams - This shows the current / high usage / max usage of protocol streams. Streams are used to track protocols that are not running in standard ports, or that have been identified more specifically than the base protocol.
The Settings column
This column shows the status of internal protocol detection. These can be used to tune the performance of your system. If you don't care about protocol decoding, you can increase your system performance by not decoding protocol headers. Here is an explanation of each setting:
Protocol Watch - Enables protocol decoding. If set, each tcp and udp packet is decode in an attempt to find the protocol associated with the connection.
P2P Decode - Enabled extra checking to detect p2p application traffic. If you have no p2p rules or don't care about detecting p2p traffic you can increase your system performance by disabling this feature.
HTTP Decode - Enables breakdown of HTTP traffic into content type.
FTP Tracking - Enables tracking of FTP connections. Typically, ftp transfers do not occur on the ftp ports. Enabling this feature will allow the system to track the ftp connection and to detect the file transfers.
TCP Tracking - Causes all TCP connections to be tracked as a stream. Normally, only protocols that are running on non-standard ports or that are detected only in early packets. This is an experimental feature. Under some circumstances, it may be more efficient to track streams rather than having to match every packet.
URL Decode - Enables the decoding of URL parameter strings. Normally, only the uri portion of the string is parsed out. Decoding parameters allows you to catch exploits (such as page=http:) at the expense of cpu cycles as much longer strings have to be parsed) at the expense of cpu cycles as much longer strings have to be parsed.
Monitor - This is a status indicator which is green when the monitor is running. Note that the monitor can have a serious impact on performance.
Compression - This is a status indicator which is green if compression is enabled
Setting Defaults
The first thing to do is to view your "defaults". For most systems, these settings can be used without modification, but it is a good idea to familiarize yourselve with them: You can view and edit them by clicking the "Edit Defaults" button. Below is a screen shot of a typical setup.
The defaults menu allows you to coordinate the bandwidth manager environment to your system environment. Following is a description of each variable.
ÂÂÂÂ
| Graph Period | The statistics gathering period used by bwmgrd |
| Default Interface | The Interface to use by default in the main menu. Typically this is the interface directly connected to the internet. |
| Rules Per Page | Number of rules to display per page. |
| Default Email | Notification Email Address |
| Save Zero Entries | When enabled, zero data entries are stored in the DB. This will make your database much larger but will graph zero instead of no data |
| Swap Graph Data | Swaps incoming and outgoing data, useful if you have your rules on the inside interface |
| Show Controls | Wnen disabled, Controls will not be shown in the menu |
| Show AutoMgr | Wnen disabled, AutoMgr will not be shown in the menu |
| Show Compression | When disabled, Compression will not be shown in the menu |
| Auto Rebuild | When selected, the startup script will not be built automatically |
| Database Host | If your mySQL database is on a remote system, this is the address. Can be host+domain or numeric. |
| Database Name | Must be etbmgr. If this is blank, then bwmgrd will assume that mySQL is not to be used. |
| Database User | The User name for access to the mySQL database. |
| Database Password | The Password for the User to access the mySQL database. |
| Data Colors | Default plot colors for graphs |
| Primary Color | This it the default color for single color graphs, such as the cpu graph |
| In Data | Color for incoming data |
| Out Data | Color for outgoing data |
| Transparency | The alpha/transparency of the graph fill colors |
| Graph Pulldowns | When check, graph pulldown menus are enabled. With 1000s of rules, this pulldowns can be quite cumbersome, and it may be easier to type in the graph names |
| Graphx | The graphs shown on the main page, where x is 1 to 4. Standard graphs are defined in the bwmgr_graphs table in the database. These graphs require a php graph file with the same name in the root directory. Other graph names are assumed to be traffic graphs, in that they must have named rules and associated data in the data base to work properly. |
ÂÂÂÂ
Once you have set your defaults, you are ready to start the bwmgr on your machine. As you can see from the menu above, both the bandwidth manager and the bwmgrd daemon are shown to be "not running". If you previously were using the ET/BWMGR then your existing configuration will be shown here and the bwmgr should be "running". In this case, the daemon may still show "not running". In either case, you should click on the "Start BWMGR" button to display the following screen:
If you have previously started the bwmgr your startup interface and license key will be displayed in the form fields. If you are running the ET/BWMGR for the first time then you will see a screen similar to the above. The fields in the startup menu allow you to tune your system, but be careful changing these settings before you understand their impact. Following is an explanation of the settings:
ÂÂÂÂ
| Status | The Status of the Bandwidth Manager. |
| Count Headers | The 14 byte header on ethernet packets are not really data, since this is stripped off when he router forwards the data. Checking this box will cause the header to be included in the traffic count for stats and for bandwidth management. |
| Stats Period | The Stats Period is the time period (in seconds) in which maximum and minimum thresholds are calculated, and is also the time period over which instantaneous statistical values are displayed. This setting should not be set to be less than 10 seconds. |
| Unburst | Unburst defines the amount of time that a rule must be under the burst limit, in seconds, before the burst is cleared. This allows you to be assured that traffic bursts or downloads have fully completed before granting bursting capability to the rule again. |
| Max Buffer Usage | Max Buffer Usage allows the system to drop traffic when this threshold is reached, which can help keep your system from running out of memory and also help from distressing a machine under attack. For FreeBSD, this should be less than your NMB_CLUSTERS setting by 10% or so. |
| Max Streams | This is the maximum number of streams to allow for protocol tracking. Without this limit, the allocation of streams could exhause physical memory in the kernel and cause serious problems. |
| Key Interface | This is the ethernet interface used to generate your serial number for your license. If you are running FreeBSD 4.9, you will see 2 entries for each, and you'll need to the serial that matched your license key. |
| Key | This is your license key. |
ÂÂÂÂ
Setting the Outside Interface
In order for your system to be able to detect protocols and the direction of your traffic, you must tell the system which interface(s) is connected to the outside world, which is usually the internet, or your WAN for a corporate network.
Typically your default interface is your outside interface. So select the interface link for your default interface (if in fact this is also your outside interface), and then select edit interface:
As you can see, the interface settings are shown and it is not set as an outside interface. Select the Edit Interface button to display the Edit Interface menu:
select the Outside checkbox, and then click Submit to save the settings. If successful, you'll see the interface set to Outside set to Yes.
Starting the ET/BWMGR
Once your have reviewed your settings, you're ready to start the ET/BWMGR subsystem. To do this, return to the main menu and select the Startup/Registration:
To start the system for the first time, use to word demo in the Key field to start the system in demo mode. Demo mode allows full use of the software for 6 hours at a time for 20 days. After the 6 hours expires, you'll have to reboot to start the demo again. A requirement is that your system be able to contact our server to authenticate. So you'll need to open your firewall to bwserver.etinc.com to allow the necessary exchanges.
Getting an Authentication Key
Once you have run the demo and decide you want to purchase the ET/BWMGR, you will have to obtain a key from Emerging Technologies. From this Start-up screen, the pull-down field will contain all of the interfaces that can be used in this machine. For example:
the above shows that there is an ethernet card (bge0) with serial number 0f:a5:f6:0a:4f:02:71:ff:99:50 and also 5a:50:99:30:4f:09. The 10 digit serial is for a v4.0 license key, and the 6 digit serial is for a v3.2 license. On a FreeBSD 7 system, you will not see the 6 digit serials, since v3.2 keys don't work on FreeBSD 7. When you start your system, you must use the entry that matches the serial that is associated with your license key. In order to find out what level license you need for your system, you'll need to run the command line utility with the keyword 'serialize'. See the ET/BWMGR User Manual for information on this procedure.
When you get your key, select the interface with the serial number that you gave us and replace "demo" with the key provided. If you have a new key, or you are setting up a new disk, you'll need to register your key with the Register BWMGR button. Note that you cannot register keys for versions before v3.2. You must register you license key before you can use the ET/BWMGR software. See the ET/BWMGR v4.0 Licensing for specific information.
Next, click "Start BWMGR" (or "Restart BWMGR" if you're already running the demo) to start the bandwidth manager. If both the bwmgr and bwmgrd are shown to be "running' in the main menu, they you are ready to go! Normally you will not start the software from the GUI, but from a startup script. Make sure you review the section on "saving your rules" in the user manual.
When you start the bandwidth manager, your license information is written to /usr/local/etc/bwmgr/LICENSE. This information will be used with "bwmgr rebuild" or when the GUI builds your script when making a change with the HTML interface.
Once the bandwidth manager and bwmgrd are running, you need to add rules to tell it what traffic to manage and what parameters to use. You should, at this point, have a screen that looks like this:
Note that the bwmgr and bwmgrd are both "running".
Viewing and Editing Rules
To start adding rules, use the top menu to navigate:
Select the "Rules" link, you would see a screen like the following:
The configuration above represents a "null" configuration, that is there are no bandwidth limits on the interface, no rules (and hence processing on the interface is Disabled), the burst manager is disabled and there is no statistical gathering enabled. It also shows the current rule indexing level and whether or not bridging is enabled. On top of the page are links that will take you back to the main menu or allow you to go directly to other rulesets. All ruleset pages have a link back to the main menu.
Interface Rules
The top 2 rows show the settings for the interface, with the ruleset below. To edit the interface settings (ie the -ifac option on the command line), click on the Ifac link, which in the above case is em0. To enable statistical gathering and graphics for the entire interface, click the Stats link marked Enable. To edit any of the interface settings, click on the em0 link. First you will see the interface rule in detail along with current statistical information:
As you can see, above is an interface summary for an active interface. It shows all of the settings for the interface, as well as the current throughput. The bridge group and features (showing FastForwarding enabled) are also displayed.
Underneath the interface summary is the statistical information for the interface. "Last" in and out represents the throughput in the last completed stats period (set in Defaults). This is an actual number for a full time period. The "Current" in and out is a snapshot of the current stats period, with a granularity of 1 second. Unless the snapshot occured at exactly as a second lapsed, there will be some error. The smaller the stats period, the larger the potential error.
To edit the rule, Click the Edit Interface button.
Adding and/or Editing an Interface Rule
After clicking the link to add an interface rule, you will see a screen as below:
Below is a description of each field. Leaving a field blank leaves the default setting. Please refer to the command line manual for a more detailed explanation of these settings.
ÂÂÂÂ
| Ifac: | The Interface name |
| Outside: | Check if interface is outside (towards the internet) |
| Statistics Only Mode: | Check to set interface to "Stats Only" Mode |
| Discover,Sticky, Learning, STP | These are FreeBSD bridge functions. Use at your own risk |
| Span Port: | When checked, all bridge traffic on the selected group will be sent out this interface. This can be used to send to an external traffic monitor |
| Fast Forward: | This bypasses much of the learning and routing circuitry for bridging. If you only have 2 ports defined and you don't have a lot of local traffic (non-routable traffic), then enabling fast forward can significantly improve performance. |
| BW Index: | The index level for bandwidth rules |
| FW Index: | The index level for firewall rules |
| TCP Window | Set the default minimum TCP window for all traffic on the interface |
| Bandwidth In (bps) | The Bandwidth Limit in the incoming (into the interface) direction. |
| Bandwidth Out (bps) | The Bandwidth Limit in the outgoing (out of the interface) direction. |
| Combine | Use the Bandwidth In setting as the Limit for Total Bandwidth In and Out (ie -bwboth) |
| Enable Stats | Check to enable stats gathering on the interface. |
| Auto-Shaping Threshold (bps) | The Auto-Shaping threshold |
| Auto-Shaping Period | The time period over which to average usage to determine the Auto-Shaping threshold. |
| Burst Threshold (bps) | The burst threshold for rules that use this interface as its burst trigger. |
| Burst Period | The time period over which to average usage to determine the burst level. |
ÂÂÂÂ
Adding Bandwidth Rules
The main function of the ET/BWMGR is that it can manage bandwidth. The key to doing this requires that you create rules (ie policies) to enact your goals. Adding rules is done on a per interface basis. If your bandwidth management box is acting only as a filter (that is, you are using it just to limit traffic and not as a server also), then you can enter your rules on either interface, as all traffic that passes through one interface will also pass through the other. If you are, for example, running a web server on the same PC that has the bandwidth manager, AND you have multiple ethernet cards in the box, then you will have to know which interface is connected to the outside world in order to set your rules properly. The bandwidth manager can only control traffic if the traffic passes through the interface on which the rule is set. Assuming that the interface you have selected is the correct interface, you can now add a rule that will limit traffic to a particular host on the network. To add a rule, enter a number in the input field and click the "New Rule" button:
Note that rules are enforced in low to high rule# order. There is currently no way to renumber rules (without deleting and adding them again), so be careful to leave index number room between rules for changes that you may make in the future. We recommend numbering in increments of 100 and then using the binary half (that is 50, then 25, etc) when inserting rules in between later.
Select the type of rule you would like to create, and then hit the "Go" button. Select "Bandwidth",and you will see the following:
To add a rule, fill in the fields with the appropriate info and click the "ADD RULE" button. Below is a description of each field and checkbox as they relate to command line options. Note that some of the fields (like "useprot" and "reverse timeout") are not shown above, as they only apply to reverse rules. Only fields relating to the type of rule selected will be displayed in the GUI. For an explanation of the command line option, see the ET/BWMGR User Manual.
ÂÂÂÂ
| Rule#: | Rule index number. (-x) |
| Logging: | Check to enable logging for this rule. (-l) |
| Name: | Label the rule with a name (-name) |
| Group: | The group this rule should be a member of |
| Reverse Timeout: | The idle timeout for dynamic learned rules |
| Max Links: | Maximum dynamic rules to allow |
| Use Prot | Create reverse rules including the protocol of the triggering packet |
| Use Address | Create reverse rules using the selected IP addresses of the triggering packet |
| Use Port | Create reverse rules using the selected port of the triggering packet |
| Balanced Bandwidth: | The bandwidth for this reverse rule should be balanced among active dynamic rules. (-rb) |
| Bandwidth Ceiling: | The bandwidth specified for this reverse rule should be shared up to this amount. (-rc) |
| Direction | Check In for Incoming Rule, Out for Outgoing, both for both directions (-i -o) |
| When Enable: | The time of day to enable this rule (blank for always) |
| When Disable: | The time of day to enable this rule (blank for always) |
| MAC Protocol: | Hex MAC Protocol (ie 0x800 for IP) to Match. ARP, IP, VLAN and IPX text allowed. (-mprot) |
| MAC Address: | MAC addresses, colon separated. Match All by default (-maddr), or source MAC (-smaddr) by selecting SRC radio button |
| Dest. MAC Address | Destination MAC address, colon separated. (-dmaddr) |
| VLAN: | vlan tag (or vlan number) in decimal. |
| IP Protocol: | Set to the IP protocol to Match (tcp, udp, etc) (-ipprot) |
| TOS | Hex mask for tos field in IP header to Match (-tos) |
| Port | Set to tcp or udp port. Default is all (-port), use Dst, Src buttons to select -dport or -sport |
| Port Range | Match ports in A to B range (-portrange). When src or dst is selected, only match the source or destination port range. |
| IP Address | Match IP address / subnet bits. Match All by default (-addr), or select source address (-saddr) with SRC radio button. When the Do Range checkbox is selected, this field is transformed to mean the start address and the number of rules to create. See Do Rangebelow. |
| Do Range | When selected, the IP address field indicated the start address / number of rules to create. See Do Range below. |
| Dest. IP Address | The destination IP address / subnet bits. (-daddr) |
| Name Address | Virtual Host Name (-nameaddr) or URL with URL box checked. |
| Bandwidth In | Incoming Bandwidth Limit in bits/second (-bwin). Check "combine" box for (-bwboth) |
| Bandwidth Out | Outgoing Bandwidth Limit in bits/second (-bwout) |
| Guaranteed BW | Minimum (guaranteed) Bandwidth in bits/second (-bwmin) |
| Burst BW | Allow Bursts to this value in bits/second when interface is under the burstlimit (-bwburst) |
| Burst Max | The maximum allowed time to burst before bursing is terminated (-burstmax) |
| Burst Trigger | Burst trigger to use as criteria for Burst BW (-bursttrig) |
| Burst Threshold | The threshold to use if this rule is to be used as a burst trigger. |
| TCP Window | The default TCP window for each TCP connection. Overrides internal settings. |
| Priority | The priority (1-10, pass-thru, FW-Deny) or rule type (stats-only, Group) (-priority) of this rule. |
| Diffserv Tagging | Check this box to enable automatic diffserve tagging for this rule. |
| Enable Gathering | Enable statistics gathering for this rule. (-stats) |
| Combine with | Combine stats for this rule with another rule. Enter the other rules name. |
| SNMP Interface | The name of the physical stats interface if this is to be exported via SNMP. (-statsifac) |
After adding the rule, you will see a screen which shows the detail of the rule that you just added:
ÂÂÂÂ
Note that host addresses are displayed without a mask. If you had selected a mask for the address, it would be displayed in address/maskbits notation. You should now check the rule and make certain that it is displayed the way that you want it to be implemented. If it is not correct, you can click the "Edit Rule" button and make any changes necessary. When you are done, you can click the Bandwidth link at the top of the page to display all of the interface settings, which should at this point look similar to the following:
Above is a listing of all of the rule we just added on em0 .
Creating Groups
We have created a group with our HTML interface called "GroupA":
To refresh your memory, a "group" is a named group of rules linked together with some common properties. The purpose of this group is to limit all of the members in the group to an aggregate of 1200000bps, and to allow no more than 512000bps per address. This allows bandwidth to be shared up to a maximum of 1200000bps between the group members.
To view the just the group (which may have dynamic members, members on different interfaces, etc), just click on the Group link and only the group members will be displayed:
Adding Comments
Comment rules allow you to document your ruleset so others can better understand why certain rules exist (or so you can remember why you did things long after doing them). To create a comment, chose "Comment" as the rule type from the pulldown, and enter an index for the positioning of the rule. Then enter the text you want, and add the rule. Make certain that you don't use quotes or apostrophies as these may be misinterpreted by the command line utility when rebuilding your ruleset the next time you reboot. Here's an example of what a comment rule looks like:
Reverse Rules
Reverse rules are unique in that they work backwards when compared to other rules. The way reverse rules work is that when a data frame Matches your match criteria, a new dynamic rule is created and linked to the reverse rule. The original reverse rule is actually a "target" rule, which signifies an event which causes the source address (the host on which the target hit) to then be subject to a bandwidth rule. For more details, see the ET/BWMGR user manual.
To create a reverse rule, enter the index as you did with the previous bandwidth rule example, and select "Reverse Bandwidth" as the rule type. The following is an example of a rule that will limit each client accessing the server at 192.168.15.1 to 256000bps, which might be useful for a download server or a porn site that wanted to limit each client regardless of how many connections they had open:
Notice that the "use SRC address" is checked, indicating that all hosts accessing this site will be limited to a total 256000bps. This rule works nicely, because regardless of what port or how many sessions the host has active, the traffic will be limited because the entire address realm is managed as a single entity:
Notice the settings for the rules **TODO **
Notice that the "learned" entries begin at 499 and move downward (group members will be displayed in the order they are added, so they may not be sequentially indexed). Also in the flags field, there is a number in parenthesis, which represents the time that the rule has been idle. When the idle time matches the timeout parameter (300 in this case), the rule will be deleted.
Name Addresses
Name addresses are reverse rules that can be used to manage or gather statistics for virtual name hosts. Note that this only works for HTTP traffic (it cannot be used to limit all traffic of a domain, for example), as it uses the HTTP header to track the appropriate sessions. For detailed information on the application of name addresses, please refer the the ET/BWMGR Online Manual.
To enter a name address rule, do the same as with a reverse rule except enter the host or domain name in the Name Address field. Suppose you entered "etinc.com". Whenever an http request is made for a URL with a host part containing "etinc.com", the requestor's IP address will be added dynamically and the host will be limited (optionally including the port number, if you put "use" into the port field).
One caveat of the name address mechanism is that hosts that access the site by IP address (if that is possible) will not be limited by the name rule. In order to stop accesses from circumventing the limits, you can add a rule which prohibits accesses directly to the IP address. Name address rules do work with addresses, so that using a name of "10.1.1.1" will limit hosts that access the address directly, however typically this is not possible with virtual hosts anyway, as many hosts are on the same address and it is ambiguous.
Name address rules are viewed in the same way as other reverse rules. The address field will show (N) to indicate that the address is a name Rule
URL Rules
A URL rule can be created in the same way as a name rule by simply checking the URL checkbox under the Name Address field. URL rules "look into" HTTP and FTP packets for GET, PUT and POST operations. If any part of the URL matches what you specify in the URL field, a Match will occur.
Time of Day Settings
Each rule can optionally have a time of day element, which controls whether the rule is enabled or disabled at any given time of day. For changing bandwidth settings, profile transitions can be used. But if you want a rule to only be in force during a particular time, then you will need to give it the approproiate setting. Each rule has an "Enable" and "Disable" setting, as well as a modifier which can further indicate which days it is in place. For example:
The above settings would set this rule to be "enabled" between 8AM and 8PM. The modifier pulldown menu allows you to specify whether the it should be enabled every day, on weekends or just during the week.
Adding Firewall Rules
Adding firewall rules is similar to adding bandwidth rules, except that you will see fewer choices.
You'll notice that the fields for adding bandwidth limits and statistics are not present, and that there are extra fields for entering policy routes and packets per second rules. Please refer to the ET/BWMGR user manual for specific info on these. Also worthy of note is that the Priority field is labeled "Action" (which is more appropriate for Firewall rules, and that the only choices are FW-Allow, FW-Deny and log-only. "log-only" rules should be placed at the beginning of your ruleset and can be used to log specific actions. The Match algorithm will not stop when log-only rules are encountered, so they can be used without concern that they will interfere with other policies.
The Priority Ruleset section allows you to add global priorities (-gpriority command line option). The only options allowed are for Matching and the priority. The operation of global priorities are outlined in the ET/BWMGR user manual.
Adding Multiple Rules with Do Range
Many times you want to add the same rule over a range of IP addresses. The most obvious example is if you want to set a default policy for each device on your network. You can use the "Do Range" checkbox to add multiple rules over a range of IP addresses. When you check the Do Range box, the address/bits fields are interpreted as "First Address / number of addresses". So if you were to enter 10.1.1.1/254 it would create 254 rules as 10.1.1.1, 10.1.1.2, 10.1.1.3, etc. The rules are added with consecutive rule numbers starting at the current rule. Its suggested that you gain experience with adding 2 or 3 rules at first, as there is no automatic way to undo or delete all of the rules that were created if you make a mistake.
The above rule will add 256 rules starting with 10.1.1.1. Note that 256,5 is an optional notation that causes the rule index to be offset by 5. Additionally, the rule name will be set up as rulename-n where n is the rule number in the range:
As you can see, the rules are 5 indexs apart, and the names are unique and include the index in the range of 1 to 256. Note that you'll probably want to remove the broadcast rules manually as its likely you don't want to include those in your limits.
ET/BWMGR - Gathering and Graphing Traffic
Feedback is an extremely important component of managing your network, and the ET/BWMGR provides detailed traffic analysis in an extremely flexible manner. There are many add-on products on the market that allow you to gather and analyze your network traffic, but few can compete with the simple yet powerful features we provide. There is no additional software required (ie SNMP is not required) and configuration and enabling and disabling graphics is a simple function in the provided HTML interface.
For legal reasons regarding mySQL, graphing is optional, as is the GUI. The ET/BWMGR can do a perfectly good job of managing your traffic without mySQL or the GUI. That being said, its likely that very few if anyone will use it that way. So this document assumes you're using the GUI interface.
Setting up Gathering
By default, all protocols are gathered by bwmgrd on your outside interface(s). If you don't see any protocol stats, make sure you've set an outside interface.
In order to enable gathering, you need to do 2 things to a rule. First, it must have a name, and second, you must enable gathering:
The rule above matches all traffic, is given the name 'All Traffic' and has Statistics enabled. Note also that the Global Rule checkbox is checked, which allows this rule to work when you have other rules, which is usually the case. After submitting the rule, you'll see the following:
You'll notice that the name, AllTraffic, is a link. Selecting this link will display the graph for this rule. Graphs are covered later in this document.
Configuring a Rule to Graph a Specific IP Address
One of the pitfalls of SNMP is that it is limited to gathering info from interfaces, which may not be what you want. While interface traffic analysis is interesting and useful, you typically have many hosts and many services on a network and you need to see a breakdown of the individual hosts. ET/BWMGR integrated graphics make this simple.
To gather statistics for a specific IP, create a stats-only rule from the Bandwith Rules screen, enter an IP address and enable stats:
When you are done, press the "Add Rule" button the system will create a "stats-only" rule and will also create a default (empty) configuration for the rule, which will tell bwmgrd to store this rule's usage in the database. If you want to customize the stats config (ie enable user graph access or change the Title), you can go to the main menu and you should see "AcmeCorp" listed in the "Select Report" pulldown menu.
If you are using an external gathering system (such as MRTG), you can optionally specify an SNMP interface. This will create a pseudo interface in the system that will be accessible from external SNMP devices (assuming you have snmpd running of course. Interfaces must be named in the format A# where A is an alphanumeric string no more than 7 characters and # is a digit. An example for the above might be "Acme0" (AcmeCorp0 is too long). Note that theEnable Gathering function and the SNMP Interface can be used together or separately. If no stats interface is specified then statistics will be kept internally only; if only a stats interface is specified then only a stats interface will be kept, but not gathered by bwmgr (and thus no graphs will be accessible locally).
Note that ANY rule can have stats gathering enabled. So if you have a bandwidth limiting rule for an IP you don't need to create a stats-only rule, as long as the rule matches everything for the IP. You can graph protocols, groups or any other class of rule that you can create. If the rule gets hits, the data can be gathered and graphed.
Notes on Using SNMP with the ET/BWMGR
When you create an SNMP Interface with the bandwidth manager software the interface is created immediately, and usage stats will begin to be recorded. However, the SNMP agent on your system will not report the new interface unless you restart it, because SNMP agents typically don't account for dynamic interfaces that are created after system startup. This implies that you will have to kill and re-run snmpd (HUP-ing it won't work) to get your SNMP agent to report the new interfaces. Additionally, if you are running standard MRTG or some other client that (annoyingly) uses interface numbers rather than names, you should reboot your system and the client with the new interface number as the relative interface numbers may change.