Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Of course, if your network is uncongested, network logons are quick, and users find all their business applications are running at top speed, then you’re probably not too concerned about a handful of people using KazaA somewhere in your organization.
Sadly, though, this ideal state of affairs is rarely witnessed, except perhaps in administrators’ dreams. The truth is that most corporate networks carry far more network-clogging leisure traffic than they can cope with. That’s because leisure apps are often particularly aggressive bandwidth users.
The key concern here is that mission-critical applications get the bandwidth they need at all times. Beyond that, it’s also important that other applications that enable users to do productive work run at acceptable speeds.
When this doesn’t happen on a regular basis because of network congestion, the reflex reaction is often to throw more bandwidth at the problem, but it’s fairly obvious that increasing bandwidth in isolation is unlikely to be an effective solution. Doubling a 512 Kbps connection to 1 Mbps, for example, simply gives more capacity to bandwidth hungry apps, without guaranteeing that performance for mission-critical application users will be improved.
And increasing bandwidth is expensive — especially when you hit the 2 Mbps mark and find that any bandwidth increase will probably entail new physical cabling. A new data pipe costs a lot: how easy is it to justify a costly infrastructure upgrade when chances are high that you’ll find you’ve filled the new capacity — with more traffic you don’t really need — in a very short period of time?
The fact is that bandwidth upgrades by themselves are very unlikely to solve bandwidth problems in anything but the very, very short term. Most network managers clearly understand this — research from Cupertino, CA-based network management software vendor Packeteer shows that about 40 percent of businesses delay deploying new applications because they don’t believe their WANs will be able to cope.
Page 2: Reserving Bandwidth and Identifying Traffic Hogs
A better and more elegant solution is to reserve some bandwidth for the apps that really need it and to decrease the overall traffic on the network. To do that, of course, it’s necessary to analyze what you’re carrying on your network, and then decide what traffic you really want and what you want to restrict. “Most people are aware they have a problem, but they don’t know what it is until they take the time to find out at the application layer,” says Roger Hockaday, a marketing director at Packeteer.
The surprising thing is that solutions for traffic identification and shaping aren’t really that expensive. Packeteer’s PacketSeeker only costs a thousand dollars or so, yet it can automatically discover traffic from hundreds of applications and provide a clear picture of what’s really causing problems on a network. And the revelations are often disturbing. When you do find what’s on your network, it’s not uncommon to discover that most of the problems are being caused by a handful of P2P users.
The good news is that once you know what you’re facing, it’s not that hard to make changes and get the network in better shape. To do this you’ll need a policy-based network management tool like Packeteer’s PacketShaper, Israel-based Allot Communications’s NetReality, or any of the other products from vendors competing in this space.
How Policy-based Management Tools Can Help
How can policy-based management tools actually help? By enabling network admins to set up policies dictating which applications are mission critical and how much bandwidth they need to run properly, which applications (like Web browsers) are important and should have a certain amount of bandwidth available to them, and which traffic is unwelcome (possibly streamed media, probably P2P traffic) and therefore to be discouraged.
For example, with Packeteer’s PacketShaper it’s possible to set policies such as:
- Per-App Minimum: Protect all the traffic in one class. You specify the size of the reserved virtual link, choose if it can exceed that size, and optionally cap its growth. For instance, reserve a minimum of 20% of the WAN link for MS Exchange. Allow Exchange to exceed the minimum if bandwidth is available, but cap it at 60% of the link.
- Per-App Maximum: Cap all the traffic in one class. Even when the traffic bursts, other applications are not impacted. For example, limit the FTP total to 128 Kbps in a T1 link.
- Per-Session Minimum: Protect latency-sensitive sessions. Deliver a minimum rate for each individual session of a traffic class, allow that session prioritized access to excess bandwidth, and set a limit on the total bandwidth it can use.
- Per-Session Maximum: Keep greedy traffic sessions in line. For example, cap each FTP download at 10 Kbps.
- Dynamic Per-User Minimum and Maximum: Dynamically control per-user bandwidth without having to resort to tedious per-user configuration. Unused bandwidth is loaned to others.
Mission-critical apps typically don’t need huge amounts of bandwidth — SAP, for example, only needs 16 Kbps per user — so it’s fairly simple math if you have 10 SAP users to set a policy that makes a reserved virtual link for SAP traffic of 160 Kbps at all times.
While you might like to get rid of “leisure” traffic like P2P traffic completely, you’re probably better off tolerating and containing it rather than trying to eliminate it altogether, according to Hockaday. “If you try to prohibit P2P, the apps look for ways through the firewall. If you contain them, they won’t port hop. In educational establishments, some of them find that a huge amount of bandwidth, like 90 percent, is outbound P2P. We suggest they don’t prohibit it, but only allow inbound traffic.”
Page 3: Added Security via Network Traffic Management
Network traffic management can have a useful side effect: added security. By setting policies for unknown applications, they can in most circumstances be contained, so the risk of a worm flooding your entire bandwidth is reduced.
Allot has introduced specific features on its NetReality WAN appliance to help against denial of service (DoS) attacks. “If the server has 100 connections per second, and this suddenly jumps to 800 per second, then there’s a good chance that a DoS attack is under way,” says Antoine Guy, Director of Global Marketing at Allot Communications.
“If this happens, we can set off an alarm and execute a script automatically to create a policy and shrink the bandwidth allocated to it, so the hacker probably concludes he has succeeded, when in fact the rest of your network is operating normally. You can then store the IP address and blacklist it.”
Limitations of Router-based Traffic Control
As an alternative to installing dedicated network management appliances, many companies try to control traffic at the router, but there are several problems associated with this. Routers can’t actually look into the application layer, so the control they offer is necessarily very much less targeted. And a dedicated appliance — installed on the WAN, like NetReality, or behind the WAN access router, like PacketShaper — is also much quicker to implement, as setting up each router can potentially be a long-winded and complex affair.
“This technology can deliver benefits on the first day, and a reason that these appliances are popular is that their cost is very low compared with the cost you’d incur on consultancy and upgrading all your routers,” says Guy. A NetReality solution for a 45 Mbps WAN costs under $20,000, he says. “Our studies show a typical ROI of 4-5 months, with 10 months at the longest.”
It may be that an organization simply does not have enough bandwidth to run all its mission-critical applications — after all, companies’ needs change, and WAN bandwidth upgrades are inevitable from time to time. But what seems clear is that without some way of managing the traffic on a network, it’s almost impossible to ensure there will ever be enough bandwidth, whatever the capacity of the WAN. So if your company has shelled out hundreds of thousands of dollars for an SAP or a PeopleSoft implementation, for example, then spending a few thousand dollars more is not an unreasonable additional investment to consider for ensuring your mission-critical apps don’t run too slow and your business doesn’t grind to a halt.
Article courtesy of CrossNodes.
