Speaking in Tech: WTF is Software Defined Networking, anyway? speaking_in_tech Greg Knieriemen podcast enterprise It's another episode of El Reg's enterprise techcast with The Dude of Tech Greg Knieriemen, storage meister Ed Saipetch and new media maven Sarah Vela. Their special guest is Greg Ferro of the Packet Pushers Podcast and EtherealMind.com, who gives us the skinny on software …
I think this may be the first "podcast" I've ever listened to myself, at least of the audio variety.
In listening to this obviously smart networking guy talk about SDN it's still not clear to me. He seems to indicate that SDN is a means to control network devices from a central location (ala vCenter). He also says that networking doesn't have that now..
Anyone heard of SNMP? Now for me I have only used SNMP to read values, never to write. But going back at least a decade I'd expect there have been management tools out there leveraging SNMP to do both reads and writes.
Most network switch manufacturers have had SNMP-based management tools for many years now. Some even have their own scripting languages which can auto configure devices when they come on the network.
I remember when F5 networks first came out with their network management tool, it got the nickname "F5 Network Mangler" (officially it was F5 Network Manager or something like that).
The standard is there, it's supported on everything already, what's wrong with using SNMP as the interface to the network? SNMPv3 has been around for years which secures the connection as well?
If SNMP didn't cut it what makes anyone think SDN will do a better job where SNMP fell short?
I'll be the first to admit that SNMP appears to be a black art on it's own. I've spent literally hundreds of hours writing custom scripts and stuff over the years to query various things out of switches, load balancers, firewalls etc. Documentation for the most part is lacking, and SNMP traps are pretty vague for the most part.
I have a decent background in networking, nothing too spectacular but I've worked with switches(L2 and L3), load balancers(L4 and L7), fault tolerance(L2 and L3), firewalls(L2 and L3), etc..
To-date the only SDN stuff I have seen talked about is in the switching area. I haven't seen any load balancers jump on board, nor firewalls or other devices(VPN etc).
I swear the more I see people talk about SDN the more confused I get on it.
As someone who has a storage background as well I sort of disagree with the network guy's view that storage has something similar to SDN - it really doesn't. Virtualization within arrays have existed for some time now, but things break down pretty quick when you start trying to mix & match vendors, much like they do in the networking realm. There are some very limited exceptions, I think fewer exceptions than exist in the networking realm.
Maybe if someone could say whether or not SDN could be considered "SNMP v4" (assuming v3 is the latest I haven't checked) ? I'd assume the "management console" would be available from a variety of sources assuming SDN is as open as people try to make it seem. I'd also expect this management console to really not be part of SDN itself, just a benefit of having such a software layer on top of the network.
If SDN cannot be considered like a next generation version of SNMP, what kinds of things will SDN do that SNMP does not do now?(assume for a moment that SNMP works perfectly).
follow up Q ...
I listened to more of the podcast (I had it paused while I wrote the above). The networking guy says SNMP sucks and SDN is better.. but doesn't really get into the details as to what SDN does, is it just "SNMP that works?"
He goes into Openflow and the ability to define in advance how you want packets routed. For the most part I find this nice if your say developing some new way of routing, for the most part I don't think people will use this functionality because the current way packets are routed pose no real problems. I'm sure there are edge cases where people have issues but for the most part this is not a wide scale issue at least that I've seen or have heard people talk about in the past.
There seems to be a race to replace STP - which is fine.STP has always sucked - in fact none of the networks I've personally built used STP. There have been alternatives to STP for more than a decade, some better than others. I've used one of them for many years now and it has worked well - has the added benefit of supporting Layer 2 as well as layer 3, and eliminates the need to run the protocol on anything other than the core. It doesn't do fancy stuff like TRILL by making all links active, the network is still active/passive. But active/passive does in it's own way make things easier to troubleshoot if there is an issue. Also can help ensure you have adequate capacity to serve in the event of a network failure.
I agree with the Network guy's view that we need a TRILL for layer 3. I was horrified when I learned that TRILL was layer 2 only, what a wasted effort, all those years and they only thought of layer 2!! WTF
anyway going to listen a bit more..
but for me at least this podcast raises more Qs than As.
The concept of putting a load balancer in a switch isn't new either. There were switches in the late 90s that had this. One of them even had licensed F5 code. I recall evaluating whether or not to use them in the early 00s but eventually went with a real F5 since the feature set on the switch load balancers was poor by comparison.
Cisco had their load balancer module for their 6500 for a long time as well, some used it, but it too fell far behind F5 and others.. I think Cisco stopped supporting it several years ago.
I don't see much load balancing occurring in switches, load balancing for the most part is fairly CPU driven, and CPU intensive, companies have moved away from ASIC-driven load balancers because the ASICs were not flexible enough (one such company used FPGAs I believe - Crescendo networks - their assets was acquired by F5 a while back). A10 uses ASICs/FPGAs still in limited cases - primarily to load balance their various CPUs in the systems. ASICs are also used for SSL offload and compression.
But the vast majority of work is done on x86 CPUs for load balancers.
Arista had a partnership with Citrix a while back to offer Netscaler on Arista switches, as far as I know nothing ever came of it. The processors in the switches just are not powerful enough to be useful for more than the most trivial of workloads (where trivial means low single digit megabits of throughput).
Load balancing came out of the dark ages (layer 4 round robin) many years ago, it would have to go back into the dark ages if we put it back in the switches.
Just look at the amount of CPU power required to drive even 2Gbps of traffic with a modern day Layer 7 load balancer - it's no small amount. It's probably 2-4 orders of magnitude more CPU power than a switch has.
I remember the last F5 devices I had - with our workload we could drive the F5 equipment to about 10-15% of it's "on paper" performance - at which point the CPUs were pegged.
In theory it can sound nice to have load balancing in switches - until you look into the details and see that it really is not feasible to do, especially if you are maintaining feature parity with the leading load balancers of today.
Hi Nate
I'm the networking guy that was on the podcast. I can suggest watching this Youtube from a year ago about the fundamentals of OpenFlow. May provide some insight into how it works.
It's really hard to explain why SDN/OPenFlow changes everythin without pictures.
http://www.youtube.com/watch?v=cZmbajtbNVk
48 x 10G ports under $10k
those have been available for a while as well, I bought some last year :)
Actual cost was closer to about $8500 (after discount), and that was without any volume purchasing power (though I do have some friends in good places).
they were SFP+ switches, not 10GbaseT.
This switch has full L2+L3 support as well as Openflow support(w/bigswitch). It can be upgraded to support things like BGP etc with a license upgrade.
I think there are many other companies that have similar things. The key thing to get it under $10k is to remove the PHY. The same switch with the PHY is about double the cost. The main limitation without the PHY is there is some distance limits on cabling(for the most part nothing major- you can't run cables that traverse multiple kilometers for example). Though without the PHY this particular switch lacks the ability to do 40G uplinks, the PHY variant has 40G support(with an add-on module).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
