Traffic Shaping and Bandwidth Management For Novell NetWare
|
|||||||
|
Traffic Shaping Engine Sample Uses
Got Questions? Just Ask!
Case 1: Prevent external users from hogging your web server "A single user on the Internet makes huge downloads from my Novell based WWW server, saturating my T1. I want to limit any given external user to 30K bytes per second, while not imposing any limits on my LAN or WAN users."Rules allow you to identify any IP traffic going to or from outside your domains. This traffic would then be sent to an address mask to identify the part of the frames which are unique to a given connection. In your case this would be the source and destination IP address. The address mask would create a new QoS ( quality of service ) node from a template you create. The template would indicate the 30000 bytes per second rate. After loading and binding and enabling the TSE, no external client would be able to use more than 30K per second of your T1.
Case 2: Prevent individual Novell clients from hogging your Netware servers "I have Novell clients on my LAN who copy huge files around which cause performance problems. I want to limit the rate at which any user can copy data down to a server to 500K a second."Rules allow you to identify any IPX frame entering the server and send it to an address mask. In this case the address mask can mask off the source and destination MAC address of the frame. The address mask would create a new QoS node from a template you create. The template would indicate the 500000 bytes per second rate.
Case 3: Use rate thresholds to enforce rates after long bursts of activity "I have Novell clients on my LAN who copy huge files around which cause performance problems. I want to limit the rate at which any user can copy data down to a server to 500K a second, but only after they send more than 1MB per second for 10 seconds."Rules allow you to identify IPX frames entering the server and send it to an address mask. In this case the address mask can mask off the source and destination MAC address of the frame. The address mask would create a new QoS node from a template you create. The template would indicate the 500000 bytes per second rate. You set the sample rate to 10 seconds and enable thresholds. The "on" threshold would be set at 1000000 bytes and the "off" threshold should be set to some value below 500000, say 200000. When the user dumps more than 1MB of data onto the server for more than 10 seconds, the 500K per seconds rate will be switched on. It will turn off only when the user drops below 200K a second for another 10 seconds. Its is magic!
Case 4: Apply rates to IP-IPX Gateway users "I use the IP-IPX Gateway to provide my workstations with access to the Internet. How can I apply bandwidth limits to the individual users of the gateway when the gateway itself has only one IP address?"Similar to cases above, you would create rules that identify the IPX side of the IP-IPX gateway traffic. There are individual connections between the workstations and the gateway, hence a way to apply a connection oriented rate for each workstation.
Case 5: Place limits on WWW traffic passing through a Netware router "I use a Netware server as an IP router. It is mostly used for VPN and WAN traffic. I want to limit the total amount of WWW traffic to 50K a second, no matter where it is going to / from."The TSE can be bound to multiple interfaces on the same server. In this case, if all the desired traffic flows through a single interface, the TSE needs only manage one side of the router. In any event, use rules to identify the desired IP traffic: TCP frames with either a source or destination port of 80. These would be sent to a QoS node with the desired data rate. Since the processing of received frames is more efficient than outgoing frames, it may be desirable to apply rules only to the receive side of the binding for each interface. However this is normally not necessary.
Case 6: Prevent broadcast storms from being seen by servers "Occasionally a workstation will hang, sending a couple hundred RIP or SAP broadcasts a second. Until the workstation is turned off, the servers go crazy trying to respond to all the route requests. Help!!!"In addition to limiting the rate of bytes per second, the TSE can also limit the number of frames per second. In this case you might want to rate limit any workstation to, say, 10 broadcasts per second. That is, the server will see no more than 10 per second - obviously the workstation can broadcast as many as it can. A couple rules can easily identify IPX or SAP broadcasts. An address mask can simply mask off the source and destination MAC addresses. A QoS node used as a template will a rate limit "by frames" to any arbitrary value per second. A more sophisticated QoS node setup will use thresholds to allow bursts of broadcasts for a short period, but severely limit broadcast traffic from that node should the threshold be crossed. For example 20 a second might trigger a 2 per second rate. The rest of the frames would be discarded as overflow and never seen by the server.
Case 7: Limit Concurrent Connections To A Given Site "I subscribe to a database service accessible over the web. But since we access it via PROXY, the external site just sees a single workstation accessing the database. If I cannot find a way to limit concurrent users to this site, I have to pay for an unlimit number, which is VERY expensive."As part of the TSE's connection oriented capabilities, the TSE keeps a count of the number of connections in a given "key group." For example, you can have the TSE build a connection table specifically for the purposes of keeping track of which workstations are accessing the site to be metered. This is best done via transparent proxy, so that the TSE sees the unaltered requests from the clients. Your rules identify traffic to / from the metered site. Then you audit these connections, building a list of workstations in the connection table. Your rules then inspect the number of members in the key group, which is the nunber of currently active workstations. When that exceeds your limit, you drop the new connection attempts. This technique is currently in use at several libraries where web accessible database services are prevalent.
Case 8: Log Traffic / Activity "On occasion I receive complaints about student computers being used to launch attacks ot other unsolicited activity. I'd like a way to record a summary of activity I can search through for IP addresses and ports when I receive such complaints."The TSE's auditing / monitoring capabilities are pretty rudimentary. However you can use the connection auditing feature to monitor traffic by workstation, port, network or whatever. As these connections age out, the TSE records a summary of the number of packets and bytes for the particular address in question. Since this builds off the address key / address mask concept, these records can summarize activity by source / destination IP, port, network, or any combination thereof. You can also use this facility to gather usage statistics per minute, hour, day or other convenient interval using absoluet time to lives..
Case 9: Allow For Exceptions To The Rule "I use per workstation limits to put a upper limit on the amount of traffic a given PC can generate. But I have a rather long list of exceptions where I want to apply a much higher cap."Again, connection tables can help which this too. You can create a list of exceptions and maintain them in a connection table. The table can be imported dynamically from a ASCII file, which you can edit. Instead of using the connection tables to limit the traffic, you can use rules simply to test to see if the traffic is part of a given table, and then treat the traffic differently. For example, use an If Connection Exists ... rule to check the table. This process happens extremely fast, and does not impose any noticable penalty of performance, even with tens of thousands of table entries.
Case 10: Limit Each IP or MAC Differently "I want to apply different rates to each of my 100 workstations. How doI do that?"The easiest way to do this is to let the TSE build a connection table from the workstations it sees. You create an address mask to select MAC address or IP address of ther workstations. You select an arbitrarily high initial data rate as a default. Each "new" IP or MAC seen will automatically add an entry to the table. After a while you have a complete list of all your IP addresses. Use the SAVE CONN command to save the list to a file. Using the information in the Beta2Changes guide, which outlines the colunms in this export file, you can put in any data rate you want. Once done, just upload the edited table and you're done. Case 11: Emulate performance of a WAN connection of performance. "I was asked to connect our regional offices to our corporate LAN using an SMDS connection. My ISP needs to know how high my CIR needs to be, which will determine my monthly bill. I don't want to pay for bandwidth I don't need, but the user's will kill if performance is bad. I'd like to prototype the effect of the WAN of performance of my business apps."A really great application for the TSE! With a single rule and QoS node you can rate limit all traffic through your server's NIC's to any desired rate. If you want to simulate a 512Kbps ( 64KB per second ) just apply that to the interface. Now you can benchmark your apps to find the optimum balance of bandwidth and performance.
Case 12: Emulate the fixed latency of Satellite WAN connections "I have been asked to evaluate the performance of our business applications over a satellite link. While the data moves at 10Mbps, it has a fixed latency of 200 milliseconds."The TSE can also be configured to generate fixed latencies down to .1 millisecond increments. All you need to do is apply the rate to all traffic through the interface and use a workstation to test your apps. Case 13: Record Traffic / Capture Packets "I want to use the TSE to perform packet captures to troubleshoot network problems, or when certain types of traffic is detected." The TSE can be configured to record an audit log of all IP, TCP, and UDP conversations. It can also be used to capture "interesting" packets into an Ethereal compatible file format. Rules can identify when "interesting" traffic is passing by and dynamically enable packet capture for these connections / conversations. Both the packet capture log and the audit logs have a loss-less roll capability so you can roll and archive these files without loss of even a single audit record or packet. The TSE can also record / audit both sides of NAT conversations, providing an effective means to troubleshoot and monitor NAT traffic. |
|||||||
| Last Modified 06-22-2000 |
|
||||||