Cisco: Hardware is still essential!
Two blog posts -- one on Business Insider, the other on The New York Times' Bits blog -- portray Cisco CEO John...
Chambers as taking a stab at software-defined networking while pushing the concept that hardware isn't going anywhere.
Business Insider's Julie Bort writes that last week that Chambers predicted on a conference call with Wall Street analysts that many a software-defined networking (SDN) company will take on Cisco and fail. She adds that while Cisco has made multiple SDN announcements, most still entail the use of the company's high-end (and costly) hardware. According to Bort, Cisco's approach in this new networking market is to take the SDN challenge head-on by moving from being a company that depends heavily on network equipment to one that offers a variety of IT hardware and software.
On the Bits blog, Quentin Hardy writes about how Cisco's Unified Computing System, USC, is playing a critical role in the company's big data strategy. Specifically, he notes that Chambers explains that big data must be delivered through the network -- and doing that requires sophisticated computing to be built into network devices (think even advanced hardware, not just bare metal with advanced SDN capabilities). Chambers argues that big data analytics companies soon are going to experience something similar to what network security companies experienced 10 years ago: consolidation, as "analytics and computing [become] part of everything."
A tale of two frogs: Embrane blasts Cisco (a little)
Denial is not a strategy, writes Jon Beck, SVP of worldwide field operations at Embrane, in response to Cisco's statement equating SDN deployments with a Bigfoot sighting. The statement made by the company isn't surprising, Beck says, but he does credit Cisco with doing a lot for the networking industry. The company's most recent statements concerning SDN, though, should raise red flags for service-provider customers looking to Cisco for innovation, he says.
Beck continues his post by saying that SDN is here to stay, and instead of comparing the emerging technology to Bigfoot, users instead should compare it to the fable of a frog in a pot of water on a stove: Traditional hardware vendors like Cisco, he writes, are like a frog sitting in lukewarm water (which eventually will heat to a boil and kill the frog, which doesn't realize what's happening), and unless they realize what's happening "they will slowly be cooked as SDN passes them by," he writes.
Read Beck's full argument against comparing SDN to Bigfoot, and his thoughts on why legacy vendors need to jump on the SDN bandwagon.
Is SDN the ultimate con?
That's the question "Mrs.Y" seeks to answer on the Packet Pushers blog. The topic stems from the recent Interop conference, where SDN was front and center, and every vendor was eager to get into the game -- yet not always with technology that fit the bill. Mrs. Y also notes that the SDN architecture is not so new, considering how similar it is to the wireless LAN controller architecture.
Mrs.Y goes as far as to say that SDN is the "ultimate grift" and that most vendors' proprietary implementations of the technology will wind up "on the dung heap, along with all the marketing propaganda." In reality, she concludes, network engineers are bound to continue struggling with automation, orchestration and centralization.
Read more about why and how SDN is the ultimate scam, according to
SDN + DevOps = 'real IT integration'
On the Plexxi blog, author Derek Winkworth explains the importance of DevOps in the development of SDN -- and vice versa. Specifically, he explains the concept of Single System Image, or SSI, in SDN, which evaluates policies against the state of the network, using information from related external systems, and then allows for plain-language network policies to be integrated into existing workflow tools.
All this information can be pushed into an SDN controller, which will "do all the hard work of enforcing the policy," Winkworth writes. He concludes his post by saying the combination of SDN and DevOps tools is the clear way to get "real IT integration," and orchestration in the context of the larger infrastructure is the missing piece in many SDN discussions.
Read Winkworth's full post on creating a network as smart as you are by combining DevOps and SDN.
Radware discusses SDN and application delivery/security
On SDN Central, author Roy Chua interviews Avi Chesla, chief technology officer at Radware, who discussed his view of SDN and his company's strategy around it. Chesla told SDN Central that SDN controllers still need to mature and learn how to work with applications. At Radware, the company focuses on using SDN to bring customers more intelligent application delivery, security decisions and simpler implementations, among other things, he said.
Chesla also explained how Radware's DefenseFlow SDN application leverages SDN technology to provide denial-of-service and distributed DoS (DDoS) protection as a native network service. DefenseFlow uses flow rules and counters on OpenFlow-enabled network devices to get the information the application needs to program basic traffic-forwarding enforcement capabilities, he said. Overall, the solution combines an SDN network with a DDoS appliance, allowing the customer to inspect the minimal amount of flows and use their existing Layer 2/Layer 3 network to block malicious traffic.
Read more about Radware's DefenseFlow application and its other plans around SDN.
Openflow meets Wireshark!
On his NetworkStatic blog, network architect and engineer Brent Salisbury outlines a way to compile Wireshark to install the OpenFlow dissector on a Mac.
Salisbury gives an in-depth explanation of how to do this, and says it's for those looking to learn or begin learning development work with OpenFlow. The OpenFlow Wireshark dissector is "your best friend" for doing so, but it isn't available yet as a built-in plug-in packaged with the Wireshark binary.
For the full instructions on how to compile Wireshark to install the OpenFlow dissector on a Mac, check out Salisbury's post.