Features

Like many colleges, Louisiana State University is continually trying to curb a seemingly insatiable appetite for Internet bandwidth. The Baton Rouge campus even upgraded its Internet access link three times in less than 16 months–boosting capacity from 24 Mbps to 155 Mbps–but user response times did not improve, and the school’s WAN services budget was getting stretched to the breaking point.

LSU’s network operations center manager, Terry Doub, had a hunch that students’ unbridled use of peer-to-peer (P2P) applications was causing the bandwidth bottleneck, but he needed a way to confirm his suspicions. Should they prove true, he also needed a tool to curtail P2P use.

A reseller suggested temporarily installing a traffic-management evaluation unit between the university’s LAN switch and WAN access router for monitoring purposes–just to learn what was happening on the network. The rest is history, says Doub.

Because of the appliance’s ability to recognize and monitor traffic based on protocol and application type (Layer 7 packet-header information), the university could verify that it was primarily P2P applications that were unpredictably gobbling up volumes of network capacity. Armed with this information, LSU used the tool to restrict the amount of bandwidth that P2P protocols were allowed to consume as a percentage of overall network bandwidth. The frequent capacity upgrades immediately subsided, and the university’s $200,000 upfront investment paid for itself in about 15 months by delaying additional network bandwidth investments, Doub says.

“Once we installed the appliance, we didn’t hear another peep from the people who had been complaining about (slow) Web browsing,” he says.

LSU’s initial test used Allot Communications’ NetEnforcer 155-Mbps AC-701 traffic-management appliance. The university upgraded to the vendor’s gigabit-speed NetEnforcer model (the AC-1010) when it became available a year later, because the AC-701 was hitting its limit of 500,000 concurrent TCP sessions, says Doub. The university had struck an agreement with Allot at the outset that it would trade in the AC-701 for the higher-capacity version when it became available, so as not to lose its initial investment.

Bandwidth for emergencies
The university has solved a number of other problems with the appliance. Among them are sectioning off pieces of virtual bandwidth to provide guaranteed emergency communications services to the Federal Emergency Management Agency (FEMA), the U.S. Army and the University of New Orleans (UNO) during Hurricane Katrina.

“We were a resource left standing that people could use,” says Doub. “We created a pipe for them on our network using the NetEnforcer that bypassed our policies and didn’t affect our network.”

LSU lets cross-institution collaborative computing groups and certain research agencies piggyback on its Internet access connection with guaranteed bandwidth and separate utilization policies. LSU is also using the traffic-management device to monitor, troubleshoot and manage incidents, such as denial-of-service (DoS) attacks and suspicious activity indicating possible intrusion attempts.

The university functions partly as an enterprise, serving internal faculty and staff with business applications and Internet/intranet access. It also functions partly as an Internet service provider, providing Internet access to students, agencies and other institutions. All traffic to and from the Internet pass through the NetEnforcer, which inspects, classifies and assigns actions to each packet based on priority policies established by the LSU IT department.

As an ISP, LSU requires the NetEnforcer to support 40,000 users across the student body, faculty and staff, Doub explains. The university also apportions separate logical Internet access links with guaranteed bandwidth for adjunct bodies, such as sister schools and emergency-response agencies.

A big challenge for university IT departments like LSU’s is to maintain network accessibility to all users, while controlling misuse within budgetary confines. In addition, P2P traffic involving copyrighted material, such as music and video content, can cause liability exposures to the university with organizations such as the Recording Industry Association of America (RIAA) and the Motion Picture Association of America.

“In a university setting, you’re expected to provide a lot of freedom in what you allow on the network, permitting the broadest possibility of network traffic without opening the network to compromise,” says Azim Ashraf, incident response manager at LSU. “It’s a slippery slope.”

So the university shapes traffic a bit differently among students, faculty, staff, researchers and outside agencies. “Based on the IP address, different rules apply,” Ashraf explains.

traffic changes made
When LSU first deployed the NetEnforcer, for example, the policy was that dormitories could use some P2P applications, but were limited in how much bandwidth was available for that type of application. For faculty and staff, this type of traffic has always been disallowed.

“We now give each student in the dorms–each IP address–1 Mbps outbound and 2 Mbps inbound, which students can use for whatever they wish,” explains Doub. “If they want to use their entire bandwidth allotment for P2P or gaming applications, that’s fine. If they want to download music and play a game at the same time, they’ll be competing for bandwidth with themselves.”

One restriction that has not changed: “Students can download music, but we prevent others from coming in and taking music from us, because it creates a liability for us” with the RIAA, Doub adds.

LSU needed to specifically identify traffic at Layer 7, but many tracking applications only do so by Layer 4 port numbers. This approach was not granular enough for identifying and assigning different priority and rate policies to, for example, the myriad Web applications that share HTTP’s port 80.

Once it got its P2P under control, LSU discovered it could classify various kinds of traffic based on application, protocol, IP source and destination, and other variables. From there, it could set an automated policy for each traffic class to keep the network and its various applications humming.

It still uses the system for creating separate, logical backup connections for emergency responders during hurricane season. In 2005, it created a similar access connection for the University of New Orleans (UNO), a member of the LSU system, after Hurricane Katrina, says Doub.

LSU carved 45 Mbps out of its OC-3 for UNO so that it could re-establish its Web presence and communicate with evacuated employees who had scattered across 28 states, says Jim Burgard, assistant vice chancellor for university computing and communications at UNO.

“The first thing we wanted was to account for our people, who had evacuated to many states,” says Burgard. “We wanted to communicate to them what they should be doing, whether working remotely or trying to make their way to Baton Rouge, where we set up a temporary office.”

The phone lines were all down, and even cell phones in the 504 area code did not work. “But having the Web site gave us the ability to communicate,” Burgard says.

layered disaster recovery
UNO used the LSU Internet bandwidth for about three weeks, says Chris Marshall, UNO manager of enterprise networks. About that time, UNO was able to provision its own Internet bandwidth from the state Internet service provider, LAnet, to service UNO’s emergency resources in LSU’s Baton Rouge Frey Computing Center. Meantime, it brought up its Exchange e-mail server on the LSU network, as well as some Oracle and PeopleSoft applications.

Traditional disaster recovery addresses what to do if your data center is gone. LSU Chief Information Officer Brian Voss, however, advocates “protecting not only your own assets but those of your neighbors and supporting them when they get hit.”

Entire communities should consider collaborative disaster planning on a nationwide basis, Voss says. “Off-site storage, equipment and local hot sites won’t be enough for calamities of this scale. We need to think about regional and national collaborations that might allow us to build a grid of disaster-recovery infrastructure, which could be deployed in the areas not affected to serve those areas that have been hit.”

This year, LSU prepared for hurricane season with the NetEnforcer by preconfiguring special virtual Internet connections for FEMA and the Army, “so that, in the event that something should happen, we wouldn’t need a NetEnforcer administrator to come out during the storm to define the networks–so the networks would already be there,” Doub adds.

The university similarly provides guaranteed bandwidth for the Southern Regional Climate Center, which is tied to the National Hurricane Center in Miami. “We guarantee 30 Mbps up and 30 Mbps down,” says Doub. “The neat thing about the NetEnforcer is they have priority for this bandwidth; but when they’re not using it, it is available to others.

The same situation applies to a special collaborative research group that occasionally requires 50-Mbps worth of file transfer protocol bandwidth for a week or two at a time. About 160 universities and research organizations participate in a project called AccessGrid across 56 countries. AccessGrid is an ensemble of multimedia resources, including large-format displays, interactive presentation environments, middleware and visualization capabilities. These resources are used to support group-to-group interactions, such as large-scale distributed meetings, collaborative work sessions, seminars, lectures, tutorials and training among the participating organizations.

“We go in and stick a (virtual) pipe on the network that specifies traffic from an internal LSU research IP address to an outside IP subnet (the AccessGrid collaborators’ IP addresses),” explains Ashraf. “When that address is introduced to NetEnforcer and the destination address matches, the network will grant the 50 Mbps to make communications efficient and smooth. Without that, you have all people competing for the same amount of bandwidth, and it’s a crapshoot.”

incident response tool
The university has learned to use NetEnforcer as an incident-response tool–to discover unnaturally large volumes of traffic generated by known suspicious ranges of IP addresses, for example, then rate-limit the traffic or block it from the network to control its impact. Incident response is facilitated by watching multiple, graphical views of traffic in real time.

Ashraf, for example, was at his desk one day when he noticed 220 Mbps coming from an IP address in Germany cross the LSU Internet border. Using NetEnforcer to build a “troubled pipe”–isolating traffic from a specific IP address or range of addresses onto its own virtual channel–enables Ashraf to see “everything that IP address is communicating with and what protocols it’s using.”

Within two minutes, he says, he was able to determine that the high volume of traffic coming from Germany was illegitimate and blocked all the traffic from that IP address, averting a potentially huge DoS attack.

The NetEnforcer is not a full-blown intrusion-prevention system (IPS), Ashraf explains, in that it cannot scan a packet’s payload, or that of an e-mail attachment, for viruses and other malicious signatures. “There are certain IP address ranges that are generally known in IP security circles to be troublemakers,” he says, however. “The first sign of a potential attack is someone passing an inordinate amount of data,” particularly from one of these IP addresses.

LSU has established a virtual pipe for simple mail transfer protocol (SMTP) traffic that Ashraf says reduces the attack potential for ill-meaning traffic. “The NetEnforcer can catch any SMTP traffic destined for anything but SMTP mail server addresses.”

“Virtual channels” can be established within a given logical pipe. For example, a network administrator might assign an aggregate pipe of 50 Mbps to video traffic and subscribe 10 virtual channels within the pipe, each with 5 Mbps, to each video session. “You can overbook the flight,” says Ashraf, “by assigning, for example, 6 Mbps per virtual channel. But the system will ask you, ‘Did you mean to do this?’”

One problem Ashraf has is that he would like the number of network graphs that can be viewed simultaneously to increase. Currently, he says, if one administrator opens a graph to view performance of a defined pipe only that individual can look at that graph. He would like for his entire four-person net administration staff to be able to view all the graphs simultaneously, as sometimes “two heads are better than one.”

For more information from Allot Communications:
www.rsleads.com/609cn-251