TSE Beta 2 Guide TSE 0.93c
Before You Start If you are new to the Traffic Shaping Engine, please review the Beta 1 Network Managers Guide. All the information provided in that document still applies to Beta 2 in terms of the operation of the TSE, and basic concepts. Review the README provided with the Beta 2 distribution. The README provides a complete revision history, bug & caveats list, etc. for the build of the TSE. Introduction This guide is a summary of changes since Beta 1. It should be used in conjunction with the Network Managers Guide provided with Beta 1. The documentation for the TSE is being revised and clarified. Until this is complete, this document serves to outline the changes between the two versions, new features, tricks and tips. Apology I have received numerous inquiries about the status of this project, and enthusiasm for the "next version" and so on. To those of you who have been using the TSE for the past year I offer the following explanation. This past year has been a very difficult, exciting, and exhausting year. We had deaths in the family, the birth of our first child, and on... and on... well, that's life! Things have calmed down a bit. So I hope to have some significant developments in the next few months. I appreciate each of you who take the time to test, take the "risk" of running the Beta on your servers, and especially those who find time to give valuable feedback. Thanks to all of you! NetWare 6 Both Beta 1 and Beta 2 have been run under NetWare 6. There do not appear to be any special issues. Added Features: Summary For a complete list of features and commands added to Beta 2, please read the README file provided with the Beta 2 distribution. There are several new features in Beta 2. Priority Queuing has been added to allow for better management of traffic at the border of your network. Beta 2 can import and export connection tables, this allows you to construct lists of IP addresses and assign individual data rates to each. Connections can be audited so that you can maintain a record of traffic usage. Rule processing has been enhanced to allow for improved performance compared to Beta 1. Beta 2's ability to assign individual data rates to a connection now scales to over 1,000,000 simultaneous connections, and is theoretically limited by available server memory. Entries in the connection tables can be grouped into distinct search domains. This allows the same address key to exist on multiple interfaces, while being treated completely separately. The TSE can now be bound to as many as 16 interfaces. The TSE has limited support for DiffServ / TOS tagging of IP frames. Rule actions allow you to tag and forward IP frames with the desired TOS / DiffServ priority. The configuration tool, while still rather brutal, has been slightly improved. Rules and other items can be rearranged so that configurations can be maintained more easily. Address Masks offer a template feature that allows an address key to be selected by drop down boxes. These templates are then used in the connection import / export to show human readable addresses. Rules offer and IP and ECB "wizard" that allows simple selection of common parts of an IP / TCP / UDP frame. Future versions will have additional wizards for IPX and IP related protocols, such as ARP, DHCP, and ICMP. So good bye to the hexadecimal calculator. Of course these can be tweaked by hand as needed. Installing / Upgrading If you already have the TSE in place, be sure to backup any existing files, then simply copy the new `SHAPER.NLM` and `SHAPER.SYM` files to your `SYS:SYSTEM` folder. Replace the old `SHAPER.EXE`, the config tool, with the new version. That is it. Then unload and reload SHAPER and run your configuration script to rebind and configure the TSE. It is a drop in replacement for Beta 1 - less a few bugs. To use additional features, you must upgrade the `SHAPER.CFG` file, which you will be prompted to do when you edit it using the new config tool. If you do not have the TSE installed, follow the installation instructions in the Beta 1 guide. If using Windows 2000 or NT, the SendTo folder exists for all users. Place the shortcut to `SHAPER.EXE` in the desired user's SendTo folder, or in the "All Users" SendTo folder. Using Priority Queuing The idea behind priority queuing is to maximize bandwidth used while minimizing congestion for "important" traffic. Priority queuing only comes into play when there is congestion. There is obviously no need to prioritize traffic when all of it can fit on the wire. In addition, if you are using a "pay per byte" sort of service, then priority queuing is perhaps not the best thing, as it encourages high levels of utilization for fluffy content when no important traffic is pending. There are numerous priority queuing algorithms. Many require a lot of computational overhead, or use algorithms stolen from alien space crafts or something. For the TSE we needed a simple, reliable, and very quick algorithm. The TSE's priority queue is "interesting" in that it is state-less. This means that priorities are enforced as each packet passes through the queue irrespective of any past traffic. The TSE uses a statistical method for predicting when a packet should be sent on its way. The end result is the enforcement of weights places on each priority level, as well as preserving the FIFO nature of each priority level's traffic. Suppose you have three priority levels and you assign them weights 250, 100, and 50. If each priority level has a backlog of traffic, then the actual traffic stream will consist of a 250 : 100 : 50 mixture. Or a 5 : 2 : 1 ratio. For ever 5 K of high priority traffic you also get 2 K of medium and 1 K of low. The ratio can also be based on packet size, which means the ratio refers to the actual volume of traffic in bytes, or on frames or both. Suppose there is no high priority traffic pending, then the mix is 100 : 50 medium to low. I.e. a 2 : 1 ratio of medium to low traffic. So the algorithm preserves the relative priority compared to the other levels. The overall effect is to keep your internet connection close to saturation while prioritizing any important traffic over fluff. Lower priority traffic consumes the unused portion of the bandwidth maximizing overall utilization. `Client 6107: 446395200 Bytes, 810300 Bytes / Sec` `Client 6108: 446583256 Bytes, 805484 Bytes / Sec` `Client 6109: 445090680 Bytes, 803000 Bytes / Sec` `Client 6110: 126473988 Bytes, 165416 Bytes / Sec` `Client 6111: 126435612 Bytes, 162060 Bytes / Sec` `Client 6112: 126362896 Bytes, 160600 Bytes / Sec` The above table is output from a traffic generator. The traffic of TCP connections for clients 6107-6109 has a weight of 100, the traffic of TCP connections for clients 6110-6112 has a weight of 20. The QoS node was set to 3.000 M bytes per second, the above traffic uses 2.900 M bytes a second. The discrepancy is that the traffic generator does not count the bytes used by IP and TCP headers per packet. Despite the fact that the TSE manages the traffic purely based on a statistical method, the ratio of 100:20 ( 5:1 ) is preserved, no matter how many clients. For example, a single high priority client competing with three low priority clients for the same bandwidth yields: `Client 6109: 46289512 Bytes, 2400240 Bytes / Sec` `Client 6110: 3324632 Bytes, 154760 Bytes / Sec` `Client 6111: 3365512 Bytes, 151840 Bytes / Sec` `Client 6112: 3355292 Bytes, 154760 Bytes / Sec` Again, the ratio of 5:1 is preserved, the moment there is no high priority traffic, the lower priority traffic is promoted to use the entire 3 MB / sec... `Client 6109: 651371748 Bytes, 0 Bytes / Sec` `Client 6110: 68082932 Bytes, 963600 Bytes / Sec` `Client 6111: 67847872 Bytes, 972796 Bytes / Sec` `Client 6112: 66555772 Bytes, 963600 Bytes / Sec` The same is true for any number of priority queue levels. With the ability to create any number of priority levels with a variety of weights, the TSE's priority queuing facility is very flexible and is functionally equivalent to the priority queuing available on traditional router platforms. Priority queuing can also be used on the Rx as well as the Tx side of an interface, allowing the priority queue to manage both inbound and outbound traffic as a single stream or separately. In applications where NetWare acts as a router and merely passed the traffic on its way, you have the ability to manage either the ingress or egress interface, or both.
FUNHOUSE TCP TRAFFIC TOOL
The tool used to obtain the above results is not really ready for production use. Its a quick hack. However, as so many have asked for it to be released, I have. Beware of what you wish for! Read the FUNHOUSE.TXT document prior to using FUNHOUSE.NLM.
Configuring Priority Queuing Note: The Priority Queuing features of the TSE are recent additions to the TSE code. As such, be sure to configure priority queues properly, use the Configuration Validation Tab ( see below ) to ensure your priority queue configuration meets basic requirements. Configuring the TSE to perform priority queuing starts just like any other. You need to construct rules to identify the traffic you want. You need to construct a QoS node to specify the data rate for the queue. Then you create your priority queue by adding two or more sequential priority queue levels in the priority queue tab. As you add levels you will see the queue's levels grouped in cheesy ASCII graphics. From the Priority Queue Tab you see a list of your priority queue levels and their relationship to each other. Select a vacant entry to start building your queue and choose Edit... An edit dialog will appear... For the first level, ensure the "Highest Priority" check box is checked ( as shown above ) - this tells the TSE this is the first level of a new priority queue. For the highest priority level, you must fill in the QoS node that traffic is ultimately to be sent to. The QoS node selected directly determines the total throughput of the priority queue - and so determines when the queue is in a congested condition. The QoS node should be configured to a value slightly below the total throughout of the connection you want to manage. For additional levels, just select the next vacant entry and similarly the dialog will pop up. For these "medium" priority levels, ensure that both Highest... and Lowest... check boxes are unchecked. When you have created your final priority level for the queue, ensure the "Lowest Priority" check box is checked - this tells the TSE this is the last level in the priority queue. When you are done, the Priority Queue Tab will show a similar layout as seen above. Then you must specify the Metrics values for the level. Currently Metric 1 and 2 are used, and may range from 0 to 65535. At least one of these two Metrics must be non zero. The 32-bit integer weight of a given packet is determined by the following formula: Weight = Metric2 + ( 8192 * Metric1 / PacketSize ) The heavier the packet, the more likely it will be to make it on to the wire. Metric 2 is the per packet weight, and Metric 1 is the per byte weight. If you wanted a 5 : 2 : 1 ratio, you could specify 5, 2, and 1, in the respective Metric 1 values for each of three levels. To get more precise ratios, just use larger number. For example, 55 : 18 : 13. and so on. Here are some pointers... The Metric 1 value is multiplied by the "inverse size" of the packet. The "inverse size" of the packet size is used because smaller packets must have a proportionally larger chance of being transmitted. For example, given two packets of equal priority, one 50 bytes and the other 100 bytes, obviously we should transmit 2 50-byte packets in the same period of time as 1 100-byte packet. So the statistical chance a given packet will be transmitted is inversely proportional to its size. So for a 1000 byte packet with a Metric 1 value of 100, the resulting weight would be 819200 / 1000 or 819. A packet of 500 bytes would be twice that, and so on... This also underscores the need to pick reasonably large metric values. If you want to 5 : 3 : 1 ratio, use 5000 : 3000 : 1000 instead. The Metric 2 value is the per packet weight. Normally you will want this to be zero unless you need to give higher priority traffic an added advantage. Suppose, for some reason, you wanted longer packets to be given an advantage. with the above example, the packet has a weight of 819. Setting Metric 2 to a value of 819 would mean that a 1000 byte frame has twice the priority it would have otherwise. However for smaller frames, say 10 bytes, the per byte weight is already so high that the Metric 2 value is negligible. For example it increases the priority by a measly 1 percent! The idea here is to provide added pressure for large packet data streams, such as video and audio. Note that the Metric 2 value does not prioritize large packets over small packets within the same priority level. All traffic within the same level is processes strictly in FIFO order as you would expect. Metric 2 can also be used on its own by setting Metric 1 to a low or 0 value. In this latter case, the prioritization is performed on a packet per second basis rather than by bytes per second. In such as case a 5:1 ratio of Metric 2 would result in 5 : 1 ratio of packets passed through the priority queue. This is normally not desirable is it does not take into account the size of the packets. But it may, rarely, be appropriate for certain circumstances. Priority Queue Caveats For queues with 7 or less levels, any values for Metric 1 and 2 can be used. If you need to construct queues with more than 7 levels, limit the Metric 1 and 2 values to less than 8192. This will prevent the 32-bit counters used to calculate the total weight of all pending packets from overflowing causing the queue to behave erratically. The Highest and Lowest priority check boxes only serve to tell the TSE where one queue ends and another begins. These have no effect on the behavior of the prioritization. Some testers have indicated they would like a means to guarantee certain traffic is passed with "flash" priority. This can be done by sending the traffic directly to the QoS node referred to by the priority queue. This can always be done and allows ultimate priority traffic to be directly deposited in the QoS queue ahead of any pending packets in the priority queuing system. Such frames are processed in FIFO order as if they were sent to a priority level with infinite priority. However this defeats the whole idea of having a priority queue. If you need to do this, just create an additional priority level with really high priority. Web Status All the information on the TSE status screen and console debug commands can be periodically written to a web page which can then be published by a web server residing on the server running the TSE. This new facility is rather crude, however it does eliminate having to RCONSOLE into the server to view the current status of the TSE. It also allows you to publish this information for your users to view. The `SHAPER WEBSTAT filename` command starts the web status process writing the information to the specified file on a periodic basis. The frequency of this update is controlled by the `SHAPER WEBSTAT PERIOD x` command which specifies the refresh interval in seconds. For example using a file name of `SYS:NOVONYX\SUITES~1\DOCS\SHAPER.HTM` would, for NES installed under NetWare 5.1, publish the status page. The page can be written to a folder requiring authentication, etc. Future versions of the TSE will offer more "pretty" versions of this facility, as well as a template which allows you to customize the page and determine what information is presented. If you decide to try this feature, I plan on creating a gallery of publicly accessible status pages. If you want your page to be linked in to the gallery, please send me the URL. Config Tool Enhancements: In General The config tool has be updated a bit and includes the ability to move Rules, Address Masks, and QoS node entries using Up and Down buttons located on the tabs. The config tool makes an effort to fix up any references to the items moved. For example if you take QoS node 30 and move it to slot 23, rules and address masks which refer to it are modified to reflect the new QoS number. Address Masks The address mask edit dialog supports the use of templates. The templates allow the selection of pre-defined address masks such as IP address or port or combination thereof. The same for IPX address and socket. Enabling the use of the Key Group ID field allows several address masks to use similar address keys without the possibility of false hits. Specifically it allows address masks to be used on the inbound and outbound NICs of a router to apply differing data rates without packets sent to one address mask being matched to connections built for the other. A unique key group ID partitions the address mask into its own search domain. Conversely, several address masks can use the same key group to share connections. Generally, a unique key group should be used for each address mask. The default ID is 0, which is backwards compatible with TSE 1. Address masks can still be built in the traditional way, by selecting an offset type and manually entering a mask in hexadecimal. However, most of the time, you can enable Templates with the Use Standard Templates... check box. This reduces the address mask dialog box to two drop down lists, one for source and the other for destination. Suppose you wanted each TCP conversation to be considered a unique connection and assigned a data rate. You would pick "IP addr+port" for both source and destination. If you cared about separating the traffic by source IP only, then choose IP addr for the source and "don't care" for the destination. All the traffic for each IP address would be treated as a connection with the distinct data rate applied to it. Under Beta 1 there was no way to expose the connection tables or manipulate them. With Beta 2 you can export, import, and edit them dynamically. So after the default data rate is applied, as specified by the referred QoS node, you can modify the data rate as needed and import the connection tables to create individual data rates for given workstations, services, even individual TCP connection. These features use the selections in the Address Mask to form the address in a human readable form. For example, for a mask using source and destination IP addr+port you see entries like `192.168.20.30:5190 --> 192.168.100.30.123:2056` ... in the connection tables. Rule Management The config tools as a couple basic additions to the Rules Tab in the Config Tool. The Comparison drop down list allows you to select a couple other types of tests. For example test to see of the frame matches any connection for a given address mask. When a parameter is required for such comparisons, use the edit box just to the right. This encodes the proper data into the Data and Mask portions of the rule. The Wizards buttons for ECB and TCPIP allow for easier construction of rules - without the need for a Ph.D. in hexadecimal. Click the button when building a new rule and you can easily test for common fields in a TCP/IP frame. If you already have a rule, activating a wizard will force the wizard to try and "figure out" what the rule does - this is not 100% perfect. If you have a hand crafted rule, it may be properly interpreted by the wizard, then again, it might not. So exercise caution and ensure the wizard properly displays the rule information. For the IP wizard, just check the boxes of the components would want to check. Then enter the data to match. The Data and Mask fields are built as you type. The IP wizard will create a rule which check for all of the conditions being met. I.e. boolean AND for all conditions. Obviously you can chain several rules together if you need to check for several conditions connected by boolean OR. The above example shows a very specific combination of IP address and port. If you enter an IP address ending in zeros, like 192.168.20.0, the Wizard assumes this is a Network address and creates a corresponding mask. You are still limited by the 16 byte span which an individual comparison can test. It is possible to check off components which span more that 16 bytes. You will be warned when this happens and you are asked to select less components or break up the comparison into more than one rule. After the fields are filled in, you can accept the new Data and Mask contents by clicking OK. You can then tweak these in the rule edit dialog if needed. The ECB Wizard is, frankly, pretty lame. Currently you can only use the ECB to identify protocol / frame type combinations. So it is not exactly a computationally challenging endeavor. Check the Protocol ID check box and use the list to select the protocol & frame type you are interested in. Once your selection is made, the wizard fills in the proper Protocol ID information. This saves time in guessing and fumbling for manuals. If you have a rule which detects protocols in this way, the Wizard should be able to figure this out. QoS Not much has really changed in the QoS area. However like other tabs, the Up and Dn buttons allow you rearrange QoS items while preserving the relationships in other tabs. Verify Configuration Tab As your configurations grow in complexity, it is sometimes difficult to ensure you have completely checked all the references from one part of the config to the others. The Verify Configuration Tab shows the current state of these references and points out any inconsistencies it finds. This tab is refreshed each time you view it, showing the effects of your changes, moves, deletes and so on. For example, in the above sample, two rules refer to non-existent "next rules" as well as problems with the structure of a priority queue. This does NOT detect myriad other issues, but some of the more serious ones which could result in the TSE malfunctioning or abending are detected. The Config Tool does NOT prevent you from saving an incomplete or invalid configuration, as configs are often works in progress and enforcing complete consistency would hamper editing the configs. Please check the state of this report prior to saving any changes which might go into production. Priority Queue Configurations MUST be consistent, even if you are not using priority queuing. DiffServ / TOS Tagging The TSE rule actions can tag IP frames with any desired DiffServ or TOS tag. Choosing a DiffServ or TOS action and entering in the desired tag value tells the TSE to modify the tag and recompute the IP header checksum. This works for inbound and outbound frames, but as the NetWare OS does not look at the inbound tags, retagging received frames is of limited use. Since the DS / TOS field is easily checked by rules, inbound tags can be used to effect different actions by the TSE as well. The overall effect is to allow the TSE to make the NetWare server look like a DS / TOS aware device. In addition, since your rules can apply arbitrary tags to outbound traffic based on your priorities, the outflow is DS / TOS aware and will result in upstream DS / TOS aware devices imposing traffic priorities on the transmitted data. This capability exists only in Rule actions, not via QoS nodes ( where it rightly belongs. ) However, with the ability to build connection tables, and the ability for a rule to test for membership in a Key Group, a set of rules can divert traffic based on connection tables to differing DS / TOS tagging actions. Ultimately this will be part of the QoS node as an alternative to queueing. However it is a powerful feature if you already own equipment capable of dealing with tags. Connection Tables The purpose of an address mask it to allow the TSE to build an address key for each packet it sees. The address key can be as vague or as detailed as needed. It could be source IP address, destination TCP port, or various combinations thereof. An address key does not even need to refer to an address, any two parts of the same packet can be used as an address key. Think abstract. Traffic is separated out into data streams by address key. A default data rate is assigned to the data stream based on the QoS node referred to be the address mask. However once created, this data rate can be modified. This is where the connection tables play a role. There is a single connection table which holds an entry for each unique address key + key group combination. The connection table can be saved to a comma delimited file using the `SHAPER SAVE CONN filename` console command. This file can be edited, or perhaps even generated by another application, and then loaded back into the TSE using the `SHAPER LOAD CONN filename` console command. If a connection entry is present for an address, it is used until the entry expires, based on the TTL value specified. So loading the modified table into the connection table will add connections entries which do not already exist, and modify those which do. Ultimately the TSE will be managed by agents which act on policies stored in NDS, so they will need to be able to manage traffic down to individual TCP connections between hosts. Even in relatively small networks the number of persistent TCP connections can be in the thousands, and hundreds of ephemeral connections might churn per second. Keeping this in mind, the TSE is designed to operate with enormous connection tables, with up to 1,000,000 entries. Exporting Connection Tables The `SHAPER SAVE CONN filename` command allows you to dynamically save the connection table to a file. The file consists of a comma delimited ASCII formatted records which include the address information, data rate, configuration flags, and operational information. This file can be directly re loaded into the TSE using the `SHAPER LOAD CONN filename` command. Alternatively, the last 6 fields containing ephemeral information can be omitted. The format of the files is simple enough that these can be generated, for example by a Java or Perl application running on the server. When you use the `SHAPER SAVE CONN` command, the shaper export process is started. It runs in the background until the entire connection table is saved to the export file. When finished, a summary of the number of connection exported is displayed on the console. The speed of the connection export process will depend on the number of connections and the server utilization and speed. The export process runs as a low priority task. Editing Connection Tables You can edit the connection tables using any ASCII text editor, including NOTEPAD. However these files can grow to be very large, so a more sophisticated text editor may be needed such as UltraEdit32. You can modify the data rates, time to live values, etc. and then reload the connection table. Generated Connection Tables You can load any number of connection table files ( only limited by the amount of RAM allocated for the TSE ) so it is unnecessary to re-import 1000 entries just to change a single entry. As a result of this, it is also possible to write small programs, either on the client or server side, which generate properly formatted connection tables for import. For example, it would be very easy to use scripting on a NetWare web server to webify the process of dynamically adding / editing connection entries. After all, they are just ASCII files. Spreadsheets are also convenient tools for creating these files. Suppose you have a list of IP addresses for all your workstations and wanted to assign different data rates to each... no problem. Importing Connection Tables The `SHAPER LOAD CONN` console command adds / updates the connection table with the connection entries in the import file. The operation is a "freshen or create" process where existing connections are updated if they already exist and those connections which do not exist are created / added to the tables. This allows you to maintain several separate import files and load them in an additive sort of way. When you use the `SHAPER LOAD CONN` command, the shaper import process is started. It runs in the background until the entire import file is parsed and uploaded. When finished a summary of the number of connection imported is displayed on the console. The speed of the connection import process will depend on the number of connections and the server utilization and speed. The export process runs as a low priority task. Import / Export Caveats During connection import and export the connection expiration process is suspended to prevent connections from being deleted. Otherwise, since these deletions occur during interrupt time, it would be possible for the import / export process ot refer to a connection entry which was simultaneously being freed. During this period, connections with expired TTL's are not deleted and so accumulate. When the import / export process is complete, the expiration process resumes and cleans these connections as normal. If you have huge connection tables, or the import / export process runs for a long time, say minutes, you may find the number of connection entries building. Normally, on a decent server, the import / export process can process 2000 to 5000 entries a second or more. So even relatively large connection tables should take a few seconds. If for some reason you need to, you can cancel the import / export process using the `SHAPER CANCEL IMPORT` and `SHAPER CANCEL EXPORT` commands. Very rarely the import / export process can abend. I believe this problem is fixed. Under NetWare 5.x these abends were survivable, only halting the import / export process. However if the import or export process hangs, or abends and is suspended, it will not have a chance to re-enable connection expiration. Under such conditions, the connection tables will continue to grow, filled with old connections, eventually causing the TSE to run low on memory. You can manually re-enable expiration using the `SHAPER OPTION EXPIRY` command. But this should be used as a last resort. Connection Audit Beta 2 has the ability to log each connection as it expires. This serves as an audit log, with time stamps, the address key, key group, and number of bytes and frames. Auditing is enabled by default and saves the audit information to SYS:SHAPER.ADT. To disable auditing ( which closes the audit file ) use the SHAPER NO AUDIT LOG command. To resume auditing use the SHAPER AUDIT LOG command. Here is sample output from an audit log. `10-30-2001 04:01:04, 192.168.181.5:53 --> 192.168.27.56:3821, 20, 0, 1` `10-30-2001 04:01:04, 192.168.27.56:3823 --> 192.168.181.5:53, 20, 0, 1` `10-30-2001 04:01:04, 192.168.181.5:53 --> 192.168.27.56:3823, 20, 0, 1` `10-30-2001 04:01:05, 192.168.37.75:1962 --> 192.168.181.5:80, 20, 15, 113` `10-30-2001 04:01:05, 192.168.181.5:80 --> 192.168.37.75:1962, 20, 2, 145` `10-30-2001 04:01:06, 192.168.21.132:2651 --> 192.168.181.5:53, 20, 0, 1` `10-30-2001 04:01:06, 192.168.181.5:53 --> 192.168.21.132:2651, 20, 0, 1` The format of the audit log is: `Date Time, Address Key, Key Group ID, KBytes, Frames` Comments are preceded with a # sign. Any spreadsheet / database can be used to accumulate statistics by address key to provide totals. If an address mask is designed specifically for statistics gathering, a larger TTL value will reduce the bulk of the audit log while providing the same data. Internally the TSE counts bytes in a 48-bit binary number, meaning it can record up to 256 TB ( 256 million MB ) before rolling over. So we had to round to the nearest K for export. This means that connections moving only a few packets will show 0 KB, as can be seen in some of the entries above. Connection Table Details When the connection table is exported, each record contains 18 columns. The Import File When imported, the file can be in two formats. It can consist of all 18 columns, where columns 13 - 18 are ignored, but must be present, and may be stuffed with dummy data. Alternatively, the import file may consist of just the first 12 columns. In either case the Key Length field in column 3 is ignored, but must be present. White space can either be spaces or tabs, but commas must immediately follow each field without any white space. I.e.`..., 25, 18, ...` is fine. `..., 25 , 18 ,...` is not. Column Descriptions Column 1 - Address, ex. `192.168.21.115:2270 --> 192.168.181.5:53` or `E0.29.60.EA.46.7A.B1.72.86` In one format, the address field consists of three parts: Source (arrow) Destination. The (arrow) is either "`-->`" or "`<->`" i.e. right pointing or double ended. The right pointing arrow indicate unidirectional flow of traffic, whereas the double ended arrow indicates bi-directional flow. This corresponds to the setting of the "Bi-directional QoS" check box in the configuration tool. Since the TSE uses the settings in the Address Mask when evaluating the address key, either arrow can be used on an import file with the same results. However this behavior is not guaranteed. Source and Destination addresses can be in any of the following formats and MUST match that selected in the address masks when you import. If templates are NOT used, the format of the address is a dotted hexadecimal string consisting of both the source and destination bytes.
`IP Address` | `X.X.X.X:*` | `192.168.20.21:*`
`TCP/UDP Port` | `*:X` | `*:5190`
`IP Class C Net` | `X.X.X.0/24:*` | `192.168.20.0/24:*`
`IP Class B Net` | `X.X.0.0/16:*` | `192.168.0.0/16:*`
`IP Class A Net` | `X.0.0.0/8:*` | `192.0.0.0/8:*`
`IP Address + Port` | `X.X.X.X:X` | `192.168.20.21:5190`
`IPX Network` | `XXXXXXXX:*:*` | `00001234:*:*`
`IPX Node` | `*:XXXXXXXXXXXX:*` | `*:0000E012D029:*`
`IPX Socket` | `*:*:XXXX` | `*:*:0890`
`IPX Net + Node` | `XXXXXXXX:XXXXXXXXXXXX:*` | `00001234:0000E012D029:*`
`IPX Node + Socket` | `*:XXXXXXXXXXXX:XXXX` | `*:0000E012D029:0890`
`IPX Net + Socket` | `XXXXXXXX:*:XXXX` | `00001234:*:0890`
`IPX Net + Node + Socket` | `XXXXXXXX:XXXXXXXXXXXX:XXXX` | `00001234:0000E012D029:0890`
In a second format, you may also specify dotted hexadecimal notation for the address key, up to 32 bytes long. This accommodates keys for which there is no standard address interpretation. For example E0.29.60.FF.EA. With this format, the length of the hexadecimal string MUST exactly match the length parameter in Column 3. Keys which to not meet these formatting criteria are rejected on import. Column 2 - Key Group ID, ex. 25 The Key Group field is used to specify which key group the key should be added to on import. This allows the same key to be added to several key groups without collision with other identical keys. It should be between 0 and 255 and correspond to the key group selected in your address masks. You should only use IDs 0 thru 63, as higher values are reserved. Column 3 - Key Length, ex. 18 They Key Length field is generally ignored and is informational only. Only when the address key is expressed in dotted hexadecimal notation is this parameter actually inspected by the import process. The Key Length is the length, in bytes, of the key at the time of export. The valid range for this field is 1 to 32 inclusive. Column 4 - Time To Live, ex. 2160 ( 120 seconds ) The Time To Live corresponds to the TTL field selected in the address mask. This is expressed in clock ticks, or 1 / 18.2 of a second units. 65536 ticks = one hour. This value can range from 1 to 4G. ( 0.06 seconds to 7.5 years ) Depending on the settings of the Address Mask Flags, the TTL is either relative or absolute. With a relative TTL, the connection entry expires after no packets have been received for the connection during the TTL period. With absolute TTL, the connection entry expires after the TTL elapses. For example, if the TTL is set to 2160 ( 120 seconds ), a relative TTL would expire after 120 seconds of no new packets, while the absolute TTL would expire after 2 minutes fro the time the connections were created. Column 5 - Data Rate, ex. 10000 The Data Rate indicate the number of bytes or frames ( depending on settings on the QoS Flags ) per second. This field is internally translated to nanoseconds per byte or frame. This limits the value of this field from 0 to 1000000000. Column 6 - On Threshold, ex. 15000 The threshold value is the rate of bytes or frames ( depending on the value of the QoS Flags ) per second above which the Data Rate is enforced. The Rate is enforced until the actual rate falls below the Off Threshold. This has a range of 0 to 4000000000. It should be above the Off Threshold. See Sample Period For Caveats. Column 7 - Off Threshold, ex. 5000 The threshold value is the rate of bytes or frames ( depending on the value of the QoS Flags ) per second above which the Data Rate is enforced. The Rate is enforced until the actual rate falls below the Off Threshold. This has a range of 0 to 4G. It should be below the On Threshold. See Sample Period for Caveats. Column 8 - Sample Period, ex. 1000000 The Sample Period specified the period of time, in microseconds, between sampling the data rate and checking / enforcing thresholds. This value can be set to any arbitrary duration. Higher values have the effect of making the thresholds more immune to flailing, rapid cycling between on and off states. The threshold values are stored in bytes / frames per sample period. Extending the sample period scales the threshold values accordingly. This means that ( Threshold Value ) * ( Sample Period in Seconds ) cannot exceed 4G. Column 9 - QoS Flags, ex. A012 The QoS Flags field holds a 4 digit hexadecimal code which corresponds with various QoS configuration options. These options include if the QoS Node is Immortal, if thresholds are enabled, if the rate is by bytes or by frames, etc. This field also contains state information, such as if thresholds are triggered, if the node was every used, and so on. This should be copied from an exported entry with QoS properties you desire. This value rill range from 0x0000 to 0xFFFF. Column 10 - Address Mask Flags, ex. 19 The Address Mask Flags field holds a 2 digit hexadecimal code which corresponds with various Address Mask configuration options. This field controls if the TTL is absolute or relative, and if the rate is bi-directional or unidirectional. This should be copied from an exported entry with Address Mask properties you desire. This value will range from 0x00 to 0xFF. Column 11 - KBytes, ex. 145 The KBytes field records a counter of bytes which passed through this connection since it was created. On import this value is added to any existing connection. If you do not want the tallies to be updated, set this to 0 on import. This field ranges from 0 to 4 TB. Column 12 - Frames, ex. 212 The Frames field records a counter of the number of frames passing through this connection. On import this value is added to any existing connection. If you do not want tallies to the updated, set this to 0 on import. The field ranges from 0 to 4G frames. Column 13 - Last Time Period, ex. 3 This field shows the number of bytes or frames ( depending on the value of the QoS Flags ) which passed through the connection in the last sample period. An indicator of instantaneous data rate. This value will range from 0 to 4G. Column 14 - Time stamp: Last Packet, ex. 505231263 This is a 32-bit microsecond time stamp value for the last time. This value will range from 0 to 4G. Column 15 - ETA, ex. 114472 The ETA is the estimated time of arrival, in microseconds, for the most recently processed packet. This indicate the depth of the QoS queue for this connection in terms of the average delay imposed on the traffic. For example, if this value is 114472, the most recently arrived packet will be delayed by 0.114472 seconds. If this value is greater than 8000000 the ETA is negative. A negative ETA indicate that (A) there are no pending packets in this QoS nodes queue and (B) the last packet was released from the queue that many microseconds ago. Things such as bandwidth banking consume negative ETA, so the actual implications of a negative ETA depend on how the QoS node is configured. In any event, this is informational only and is ignored on import. This value will range from 0 to 4G. Column 16 - Time stamp Last Hit, ex. 505231016 This value is a 32-bit time stamp of the last time the QoS node was touched, e.g. had a packet fed to it. This is used to age QoS nodes and trigger threshold processing. It is informational only and is ignored on import. This value will range from 0 to 4G. Column 17 - Entry Number, ex. 3 This value is an entry number for the entry being exported. It has meaning only to the export process. It is informational only and is ignored on import. This value will range from 1 to the number of connections in the connection table at the time of export. Column 18 - Bucket ID, ex. 32 This value is an internal value used by the connection indexing and search algorithm. I will range from 0 to the number of buckets configured, which is related to the -BUCKETS=x load parameter. If there are an unusually large number of connections with the same bucket number, the TSE will be less efficient in searching the connection tables. When you look at the connection export file, the connections should, roughly, be spread between the entire range of bucket values. Console Command Reference The following commands are prefixed with the `SHAPER` keyword, for example, `SHAPER BYPASS`. `[NO] AUDIT LOG` `[NO] AUDIT SCREEN` These command turn on / off the audit log and audit screen. Currently the audit screen is unimplemented. When set, this option opens the audit log and records audit information gathered from the connection expiration process. When turned off, the audit information is not gathered, and the audit log, `SYS:SHAPER.ADT` is closed and may be accessed by another program. `BIND x [ UP | DOWN | BYPASS` `| [ START | STOP ] [ ELN | RECORD ]` `| RULE n ]` The `BIND x UP / DOWN / BYPASS` command places the bind number ( as can be obtained from the `DEBUG BINDS` command ) in the desired state. In the `UP` state, the TSE processes all traffic through the bind. When in the `BYPASS` state, the TSE passes the traffic onwards immediately without any processing, and so is essentially transparent, as if the TSE were not loaded at all. In the `DOWN` state, all traffic through the bind is dropped / filtered. The `START / STOP ELN` and `START / STOP RECORD` sub command enable very disk intensive logging of traffic passing through the bind. The `ELN` command records queue activity, each time a packet is enqueued, and dequeued and the time the frame spent in the queue. The `RECORD` command records the contents of the ECB and FRAME data to the log file. This can be extremely disk intensive as a 1.5K IP frame may take up to 5K of log space to record. Immediately `STOP` this logging when you have obtained the information you need. `The RULE n` sub command tells the TSE which rule should be the starting rule to be executed for frames passing through this bind. This defaults to rule 0 and should be explicitly changed by your `SHAPECFG.NCF` configuration script. `BYPASS` Forwards all frames for all bindings making the TSE transparent. This command counteracts the `UP` command. `CALL LSLSERVICEEVENTS` For diagnostic purposes only. Used only when advised by Support. `CALL MAPDATAOFFSETTOABSOLUTEADDRESS address` For diagnostic purposes only. Used only when advised by Support. `CALL RND` Outputs a sequence of random numbers. `CANCEL EXPORT` Gracefully terminates all connection export processes. The tables generated by the running export processes will be incomplete. `CANCEL IMPORT` Gracefully terminates all connection import processes. The tables loaded by the running export processes will be incomplete. `DEBUG ALL` Dumps several tables of debug output to the server console. Use in conjunction with CONLOG to obtain this information. `DEBUG BINDS` Dumps information about TSE bindings to the console. This info includes queue depth, and counts of packets forwarded, dropped, queued, and state information. Very useful. `[NO] DEBUG LOG` `[NO] DEBUG SCREEN` These command enable, disable the SHAPER log file and log screen. The log file and screen can be turned off independantly, and as with the audit log, when disabled, the log file, `SYS:SHAPER.LOG` is accessible by other applications. Generally, there is no output sent to this log, only when recording and debugging commands are enabled is this file written to. The log can grow quickly. `DEBUG LOGGER` `DEBUG LOGGER DAEMON` Dumps information about the state of the debug logger to the console. `DEBUG MEMORY` Dumps memory usage information to the console. In particular the number of used, free, and toxic nodes. A toxic node is a node which has been freed, but may be referenced by the OS for callbacks. Toxic nodes cannot be reused by the TSE and are freed when the TSE is unloaded. `DEBUG PRIQ` `DEBUG PRIORITY` Dumps information about the priority queues. This information includes byte and packet counts as well as the queue depth for each priority level. `DEBUG QOS` `DEBUG QOS NODES` Dumps information about QoS nodes to the console. This information includes the actual data rate, number of frame and bytes passing through the QoS node. `DEBUG RTAGS` `DEBUG RESOURCE TAGS` Dumps information aboud resource tag allocation. This information may be requested by technical support if you encounter startup issues when loading the `SHAPER NLM`. `DEBUG RULES` `DEBUG RULE NODES` Dumps information about the current ruleset. This information includes the number of hits and misses as well as state information. This information can be useful when trying to optimize rule performance or troubleshooting rule execution. `DEBUG RUN` `DEBUG STARTUP` These two command show the output from several related `DEBUG` commands which are intended to aid in support efforts. These can scroll a lot of information off the console screen so it is best to use the CONLOG utility to capture the output. `DEBUG TIMERS` Dumps information about the status of internal timers used by the TSE. `DUMP MEMORY` Dumps the current TSE working memory to a pair of files `SHAPER.MEM` and `SHAPER.MAP`. These two files contain much of the dynamic data used by the TSE and may be used for troubleshooting purposes. Since the TSE can be forced to allocate large blocks of RAM, this command should only be used when directed by technical support. `INFO` Shows a short copyright and liability information screen. `LOAD CONFIG` Forces the TSE to reload its configuration file. Normally the configuration file is loaded automatically when the TSE loads and whenever the config file is modified. If you revert the config file to an older version, this command will force the TSE to load the older file. `LOAD CONN filename` This command starts a Connection Table Import thread to load the connection table with entries from an import file. If no import file is specified, the TSE assumes `SYS:SHAPER.IMP` and loads entries found therein. `OPTION` This command displays the current status of all OPTION command switches. `OPTION DROP Overflow` `OPTION FORWARD Overflow` These two command tell the TSE to drop or forward overflow packets. Any packet which would be queued for more than 8 seconds is considered an overflow, and these command determine the action to take. The default action is to forward the frames. `OPTION FORWARD Small` `OPTION FORWARD Zero` `OPTION QUEUE Small` `OPTION QUEUE Zero` These four commands tell the TSE what to do when a frame would be enqueued with a zero or near zero delay. Forwarding frames with a zero delay increases throughput of the TSE, but is not enabled by default as the Beta versions of the TSE are designed to exercise the queuing functions of the TSE. Similarly, the TSE queues frames with near zero delays, comparable to the temporal resolution of the queue for the same reason. These commands allow you to modify this behavior, generally increasing the throughput of the TSE for high bandwidth ( wire speed ) applications. `OPTION [NO] AUDIO` This command enables / disables an audio monitor feature which produces a hideous hissing sound out of the server's PC speaker. Each time the server sends / receives a packet, the PC speaker is vibrated, causing a static noise. It us useless, but interesting. `OPTION [NO] EXPIRY` This command enabled / disables the connection expiration process. The connection expiration process is critical for the normal operation of the TSE and should be disabled for short periods of time. `OPTION [NO] INT D` `equeue` This option allows the TSE to service its queues during packet receive interrupts. This can double the accuracy of the queuing process and provides better performance when the server is under load. However it also forces the server to run TSE code during reception events, which can cause slight latency in receive events which are ultimately not handles by the TSE. Generally this improves performance with very little downside risk to server stability. `OPTION [NO] QUEUE Overflows` This option works in conjunction with the overflow commands above to determine what the TSE should do when a queue gets saturated. When set, this option allow queues to overflow, leaving the outcome t the option commands above. When not set, the queue never overflows, and all frames are "squeezed" into the tail end of the queue, imposing an 8 second delay on each. `OPTION [NO] RACHET` Any 386 or older 486 based server may not properly generate the microsecond resolution time stamps necessary for the TSE to operate properly. This can cause the microsecond timer to appear to roll backwards. When this happens, the TSE generates an error indicating that time apparently went backwards. These Timer Backstep Errors should not appear on modern hardware. To allow the TSE to operate on these servers, the TSE can "ratchet" its internal timer by simply adding the delta between the previous value and the current one. When the timer falls backwards, it is assumed it rolled over and the TSE's internal time stamping mechanism keeps marching forwards. ( Think of this as "synthetic time" as applied to the timer. Setting this option will prevent the error messages from appearing, and does help the TSE a bit -- however the underlying hardware deficiency is still present. Such systems are very capable of dealing with a T1 traffic stream and so are still useful. `OPTION [NO] SORT CONN` This option, when set, forces the TSE to optimize its connection table in response to frequently used connections, making them easier to find on subsequent attempts. This requires a small additional overhead, but this is paid back in a great reduction in the average search times for connections under real world conditions. Of all entries in the connection table, it is likely that a small percent are actually actively moving packets, so this optimization can be very useful. After it is enabled, the Hash: Ratio value should drop, showing an increase in search efficiency. `OPTION [NO] STI` This option allows the TSE to check the servers microsecond timer with interrupts disabled. This option should be left at its default state. `RULE n [ START | STOP ]` This command starts / stops debug logging of rule processing for this rule. The output shows the frame data, the data to compare to and the outcome of the comparison. This is disk intensive so should only be used for short periods and when needed to diagnose rule execution problems where the `DEBUG RULES` command is insufficient. `SAVE CONFIG` This command forces the TSE to save its configuration file. The TSE saves the configuration file only when none exists, as when it is deleted. This can be used to force the TSE to write the config file at any time. The config file will contain ephemeral information which may be useful in troubleshooting. `SAVE CONN [filename]` This command tells the TSE to start a Connection Export Thread to save the connection table to a connection table file, specified by the filename provided. If no filename is provided, the TSE assumes `SYS:SHAPER.EXP`. Output is APPENDED to the end of this file if it exists. Please keep that in mind if you wish to reimport the file later on. `UNLOAD` This command is a safe way to request the TSE unload itself without the risk of hanging the console if the NLM refuses to unload properly ( as might happen after an recoverable abend. ) The console is immediately freed up and the TSE starts its shutdown. The status screen will remain displayed until you press a key to close it. This allows you to view the final status info as the NLM unloads. You will not be able to reload the NLM till this screen is closed. `UP` This command places all binds in an UP state, allowing the TSE to process any packets flowing through them... This command counteracts the `BYPASS` command. `[NO] WEBSTAT` `WEBSTAT PERIOD x` These command enable, disable the SHAPER Web Status process and set the frequency of the periodic update of the status file. This process creates an HTML formatted web page which can be written into the servers web document folder, or any other location. This allows the status of the traffic shaper to be viewed from any browser. Design Principles and Considerations Often I get e-mails about implementing specific, agonizingly detailed, and sometimes picayune / punitive configurations. Very often simple configurations can provide significant relief from bandwidth problems. Focusing on improving the quality of access to critical resources should be the focus. It is easy to get mired down in draconian limits, but in most locations these hard rules lead to exceptions, and then it is death by a thousand cuts. Focus on the problem. Typical problems fall into a couple major categories: P2P file transfers chronically saturate your internet connection Burst traffic from PROXY or GROUPWISE saturate your WAN Need to thwart excessive use ( as a policy ) Guarantee bandwidth for critical applications You may already have preconceptions on how to approach these. But very often big problem have easy cures if you don't go crazy. Your certainly not the first person to face these issues, if you find yourself creating overly complex configs, please ask for help. Expectations First of all, no amount of bandwidth management is going to make a 28.8 modem into a T1. TCP/IP is designed for slow links and so employs various methods to reduce or overcome the latency of a slow connection. TCP windowing allows the workstation to send 8 packets without requiring an acknowledgment. This is approximately 12K of data. The TSE will buffer up to 8 seconds of traffic. The reality is that if there is less than 1.5KB/sec available per concurrently transmitting TCP connection, the TSE will not be able to adequately throttle the traffic with delays alone. In such cases there is simply too much traffic and not enough bandwidth. If you see the Depth field for a QoS node approaching 8000000 microseconds ( 8 seconds ) there are so many concurrent requests piling up that even applying an 8 seconds delay on each packet is not throttling the traffic back. The moral to the story: sometimes you need more bandwidth. However the TSE is a great tool for controlling who gets to use that added capacity should you add bandwidth. Competition Between Workstations Smoothing out bursty traffic with Address Masks The TSE works best when there is are lots of workstations competing for bandwidth. Packets from several workstations are interleaved as they arrive at the server's NIC. This leads to the same interleaving effect as the TSE processes the traffic. As you have fewer and fewer workstations, some odd things can happen because of the way TCP windowing works and the need for the TSE to enforce FIFO on the traffic. Consider a worst possible case of only two PC's: `PC A --- 8 packets DTA --> ( TSE Receives all 8 packets )` `( TSE starts sending A's packets )` `A1 -->` `A2 -->` `A3 -->` `PC B --- 8 packets DTA --> ( TSE Receives all 8 packets )` `A4 -->` `A5 -->` `A6 -->` `A7 -->` `A8 -->` `( TSE finishes sending A's packets )` `( TSE starts sending B's packets )` `B1 -->` `B2 -->` `PC A <-- 1 packets ACK --- ( Remote Host ACKs )` `B3 -->` `B4 -->` `B5 -->` `B6 -->` `B7 -->` `B8 -->` `( TSE finishes sending B's packets )` `PC B <-- 1 packets ACK --- ( Remote Host ACKs )` As you can see, B's packets wait for all of A's packets to be sent before B's packets are sent. The total time for both sets of packets to be sent is the same, however A gets faster response. This is because the TSE receives frames from the workstations over a local LAN at high speed, and so A's packets are completely enqueued before B's packets are sent. Of course A will wait for B's packets to be sent the next time around. So it is not as though A always gets priority. However the flow of traffic is rather bursty from the perspective of each workstation. Or to summarize, each windowed sequence of packets ( transmitted between ACKs ) is processed as a unit and do not, generally, overlap other sequences from other workstations. This is not by design, just a result of the way workstations transmit TCP data on the relatively fast LAN, and how this is then "spread out" as it hits the slow media that connects to the Internet. From the Servers perspective, the TSE receives a rapid fire succession of packets from a give PC one at a time. A way around this is to use Address Masks on the Rx side. Create an address mask to separate the traffic by workstation ( MAC or better yet IP ) and use a QoS node with a data rate comparable to the total throughput available. This QoS node is applied to each workstation individually, creating a separate FIFO for each, and metering out packets per the specified data rate. This data rate can even be much higher than total bandwidth available, the important thing is that now the TSE paces all packets received. Here is why this works, consider the two workstation situation again except with address masks on the Rx side and a single QoS limiting the outbound traffic to the internet: `PC A --- 8 packets DTA --> ( TSE Receives all 8 packets )` `( TSE starts sending A's packets )` `A1 -->` `A2 -->` `PC B --- 8 packets DTA --> ( TSE Receives all 8 packets )` `A3 -->` `( TSE starts sending B's packets )` `B1 -->` `A4 -->` `B2 -->` `A5 -->` `B3 -->` `A6 -->` `B4 -->` `A7 -->` `B5 -->` `A8 -->` `( TSE finishes sending A's packets )` `PC A <-- 1 packets ACK --- ( Remote Host ACKs )` `B6 -->` `B7 -->` `B8 -->` `( TSE finishes sending B's packets )` `PC B <-- 1 packets ACK --- ( Remote Host ACKs )` This interleaving effect happens because each connection generated by the address mask meters out packets and paces them independently. So instead of two distinct batches of packets you have a much more uniform mix. The same effect is achieved by using address masks on the outbound side. So whichever interface makes most sense. This is something worth considering for low bandwidth ISP connections or for perpetually saturated links in general. The added overhead of maintaining connection oriented rates is minimal, and paves the way to manage each separately as outlined above in previous sections. Using this technique is certainly not necessary unless you see issues caused by the granular nature of windowed transmissions... There is overhead associated with using the address masks if they serve no other purpose but this. However if you are using them already, this is an added benefit. The foregoing discussion also illuminates the observations of some testers who saw this seemingly puzzling pattern of transmissions when using a sniffer. Sample Uses For New Features Since Beta 2 is a drop in replacement for Beta 1, all of the applications for Beta 1 from the Network Managers Guide still apply. Obviously priority queuing and connection audit bring to mind some obvious new uses. The following are a few not-so-obvious potential applications which use features released in Beta 2. Automatically Enumerating IP Addresses One thing the TSE does a good job at is automatically building a list of IP addresses for you based on traffic seen. By using an address mask and QoS node to apply some arbitrary data rate per workstation, the connection table is populated with entries. You just wait a while, export the connection tables, and you have a list of every IP address pushing packets. Assign Rates To Individual Workstations, Etc. Beta 2 allows you to build a list of workstations, ports, TCP connections, etc. based on actual traffic. You can use the `SHAPER SAVE CONN` command to save this list of connections to a file. Simply edit the file to reflect the desired data rates and use the the `SHAPER LOAD CONN` command to activate these changes. Prioritize Access to Important Sites One thing I've been asked about by academic institutions is if it is possible to prioritize access "important" web sites. Obviously this is a tricky question as the TSE only knows about IP addresses. However it is possible to build a list of IP addresses or domains ( Class C Networks, for example ) which you want to have greater priority. This list can be managed in a variety of ways. Once nice way to do this is by building a CGI based web form for faculty and staff to nominate sites. The form could be a Perl based CGI running on a NetWare web server, even on the server performing the bandwidth management. The Perl script would accept a URL, and strip out the web server address. It then perform name lookup on the site to get a list of IP addresses it resolves to. This list is then used to add lines to a Connection table file which is periodically uploaded, perhaps by CRON.NLM into the TSE. The TSE would be configured to check this connection table for packets going to / coming from this list of addresses. If its on the list, the rule divers the packet to a higher priority queue level, or to a different QoS node to gain more bandwidth. Limit access to certain IP addresses A connection tables are, in essence, a list of address information. These lists can be as simple as a list of source IP addresses. Once uploaded into the TSE, you can use rules to see if the particular packet being received is / is no matched to a connection entry in the list. Unlike access lists on other systems where additional entries significantly bog down operations, the TSE is capable of handling lists in excess of 100,000 items. You could create a list of all "assigned" IP addresses on your private network and reject all others, or rate limit unregistered IP addresses to use a smaller portion of the bandwidth. You can even use filtering to prevent these workstations from accessing certain resources. Not Just Addresses Address masks can build an address key from any part of the packet. This allows you to build a list of all packets for which a TCP SYN was received, for example. Since SYN's are used to establish a connection, rate limiting the number of SYN's a second to a given TCP port effectively limits the number of new connections that port will accept per second. This also means it is possible to use the Audit action to build a list of addresses keys based "interesting" packets. For example a list of connections for which SYN and SYNACK were received... etc... These entries can be made to time out after a prescribed period using the TTL field of the Address Mask. Traffic Usage Each packet can be passed through a number of Address Masks for the purposes of auditing. This, of course, requires a bit more overhead, but not much. This means you can create a set of Address masks to accumulate statistics about bandwidth usage. For example, if you wanted to find out which services were responsible for the most traffic, create an address mask for destination TCP / UDP port. You can also build a list by source or destination IP, etc. You can manage these in two ways, create connections which never expire and use the `SHAPER SAVE CONN` to periodically, as needed, dump the connection table for analysis. Alternatively, you can force the connections to expire periodically, perhaps every day, and use the connection audit facility to log an abbreviated entry. Web Forms Make Custom Management Easy Since the connection table file is just a comma delimited file, it can be ready and manipulated by simple scripts. As the web site prioritization example above shows, a simple server side script can expose these tables, allow them to be edited, and then uploaded back into the TSE. A simple CGI could allow data rates for a workstation to be modified, connections to be expired ( by modifying the TTL type and value ). In fact this would be a good solution for provide a means to block / monitor workstation traffic usage. A CRON can periodically save the connection table which the CGI front ends. Problems... Please Report Them! The whole point of a Beta is to figure out what the issues are and garner responses from users... i.e. you! Your feedback is critical, especially when it comes to defects in the software itself. Of course I welcome feedback about functionality issues, and hope all of you will keep in touch about your actual use of the TSE and the impact it has made in your environment. From Here... Where? The future... The next question is: now what? So far, the development has focused on the Traffic Shaping Engine, which is designed to implement relatively crude, atomistic, traffic management. The ability to use the TSE as a bandwidth manager via the Config Tool is, frankly, incidental to the real goal: and NDS manageable traffic management tool based on policies, easy to configure, and scalable to deployment throughout an enterprise. The next phase of the development focuses purely on adding DNS / LDAP / NDS smarts to the TSE in the form of add on modules which talk to the TSE and NDS. These agent fall into a few basic categories: Identification. Obviously with a private network, it is insufficient to try and manage traffic by IP address, ports, and networks. You really want to know who is requesting the traffic, what the traffic really is, and where is it coming from. You also want to be able to refer to these in human readable form. In situations where DHCP is used, this information must be gathered dynamically, in addition, if a single workstation is used by multiple users, or roaming users, the association of the User and the IP address, for example, needs to happen dynamically. In addition to the identification of workstations, hosts, and the users using them, we want to identify the type of traffic itself. Some traffic types, such as HTTP, DNS, FTP are readily identified by port numbers. However others are much more difficult. An agent will be designed to monitor not only the initial packet ( which indicates port id and IP addresses ) by look into the payload of the packet itself. Obviously someone configuring a P2P tool to use port 80 ( HTTP ) would evade systems which do not do this. Once the agent has confirmed the type of traffic, then we are safe to apply a data rate. Policy. Ultimately your not going to want to define rules, manage tables, assign data rates to individual TCP connections. When a packet comes in, if the TSE knows what to do with it, then the TSE handles the traffic, applying the desired data rate. For packets which the TSE is unfamiliar ( a new TCP connection, traffic from a new IP address, etc. ) the TSE will temporarily hold the packet and ask a Policy Enforcement agent what should be done with further traffic for this data stream. The Policy Enforcement agent will look at the applicable policies and figure out which ones apply. This information constructs a connection entry in the TSE with the appropriate data rate, priority queue, or other actions such as dropping the frame. The Policy agents use the Identification agents to translate an address into a human readable name. For example, an NDS User Object like .CN=bob.OU=developers.O=shaper. Hence policies refer to NDS entities rather than addresses. Obviously this is much more work than just dealing with raw addresses. So how will the TSE keep up the current levels of performance? First off, once the TSE has been instructed what to do with the traffic, based on that first "unknown" packet, these agents are not needed for further processing of any additional packets for that connection. Based on surveys of network traffic, the TSE might need to refer to the policy agents for less than 1 in 20 packets, worst case. The policy agent will read policies associated with container, group, and user objects and synthesize a decision tree to determine which policies apply. The policy package is built from NDS periodically, and so is rapidly traversed, and is available even when NDS is slow or unavailable.
Last Modified 11-05-2001 | Got Questions? Get Answers! info@TrafficShaper.com