Longtime vendors might not want to admit it, but the OpenFlow protocol is turning out to be an important development in the world of networking. The latest evidence comes from Illinois, where 13 OpenFlow switches from scrappy networking startup Pica8 are empowering academics to more easily monitor their networks for security problems in real time and other functions.
Researchers at the University of Illinois at Urbana-Champaign ended up deploying Pica8′s P-3290 switches because they support OpenFlow and because they boast 1-gigabit Ethernet. They could have gone with, say, Hewlett-Packard or NoviFlow, but they heard others saying positive things about Pica8, said Brighten Godfrey, an assistant professor at the university.
Godfrey and his colleagues at the university’s Ocean Cluster for Experimental Architectures in Networks have been running an application they call VeriFlow in their network to spot how a configuration change might affect the security of the rest of the network or violate existing policies, so an administrator can centrally keep an eye on these things down to the millisecond.
They have also been testing out a novel network architecture called Jellyfish, which lets administrators add switches into their networks quickly and basically at random. It might sound like that behavior could bring on capacity issues, but Godfrey said the method turns out to be 25 percent to 40 percent more efficient with the same hardware than with a legacy design such as a spanning tree.
“That kind of thing would have been pretty difficult in traditional hardware and is quite feasible with OpenFlow,” Godfrey said.
Finally, the switches are in place for experiments with migrating whole virtual networks to different physical gear without causing service disruptions.
When scalability calls, network admins shouldn’t be faulted for wanting to throw hardware at the problem, and these sorts of applications could help the cause. As OpenFlow makes these applications possible, it’s worth asking why it’s not yet ubiquitous in network gear. Cisco and Juniper have been less taking gradual steps at providing customers with small steps in the direction software-defined networking (SDN).
The subject is hot, and it’s one that could well come up during a conversation on SDN with Juniper’s Bob Mulgia at our Structure conference in San Francisco on Wednesday.
It’s unclear if existing Cisco or Juniper customers will defect and jump at switches that can be programmable with a common protocol and controlled on commodity servers by way of SDN controllers from a number of emerging vendors. But with more of these cases emerging, the shift looks increasingly palpable.