SDN's dream: Use what you've got, not what you're promised Is hardware turning soft? Yes, if you listen to IT vendors. Companies such as Oracle are investing in Software Defined Networking (SDN) — turning features that were once hardware into apps or part of the networking layer or running as apps on servers. I've recently written about the problems and promises of SDN and find the …
"While Microsoft's SDN networking support is primitive at best"
Microsoft's current solution on the SDN side is currently a way ahead of say VMWare or OpenStack's offerings - is more mature having been production proven for several years now - is standards based (such as supporting DTMF, OpenDaylight and Open Networking Foundation APIs) - and doesn't require custom network hardware to work (being based on GRE)...And will be very simple to deploy with a market leading TCO via Azure Pack...
(Microsoft also supports integration with proprietary solutions like Cisco ACI if required.)
1. This would actually be quite easy, since all the configuration would be centrally managed by the orchestrator. Of course, having all of your eggs in one basket presents other problems, but I digress.
2. Once SDN-tards decide that they have an answer for this, the rest of us would love to hear it. AFAIK, there's no answer presently.
3. I would expect that the centralized management should easily handle separation of duties and role-based authentication.
In general, I don't believe that the typical, management-level features of SDN (e.g. AAA, fault management, CMDB) will present any unforeseen issues, since these features tend to be centralized already with existing systems like Openview, Solarwinds, CiscoWorks, etc. The tricky part is the small margin for error with a single configuration change or an orchestration software bug, as the entire network could collapse in one fell swoop with no documented method for recovery.
SDN command centralization is handled by making the controllers clusterable multi-master affairs that are virtually impossibly to kill. Also, the switches don't stop working if the command processor goes down. It's only certain types of changes to the fabric that cease being processed. Some changes will continue to be processed as they can run on dynamic protocols that - while normally mediated by a central controller - can operate independently of the central controller in a pinch.
SDN can make meeting various standards easier than manual configuration. The reason for this is that the more advanced SDN/NFV controllers can be configured not to allow network changes which would violate given standards rules. (No open paths to the net without various layers of security, for example.)
Also: SDN absolutely has simple methods for recovery when changes are made. Configuration changes are typically documented by the controller. Why not, it's just logging as far as the controller is concerned! You can roll back your entire network to a previous point in time by simply reimposing a previous configuration state, if that's what you need to do.
Hell of a lot easier than changing everything by hand.
so you think hardware is less reliable than software Trevor? Seriously?!?
and sure, the switches keep working if/when the controller dies. But if, for example, you've drunk the kook-aid and decided to implement reactive OpenFlow (having forgotten the disaster that was ATM LANE) then that won't help you much...
SDN is great, I work on it all-day every-day, but we really do need to get past the "SDN is OpenFlow" religion.
I have tested NSX, ACI, Contrail. All three have certain advantages but enough drawbacks where I have been sitting back and waiting for the platforms to mature (price, scale, features, 3rd party integration...etc).
Most recently I have looked at a couple other "SDN" names (I met at Openstack Summit) such as Midokura, PLUMgrid and Nuage Networks. Both seem to be viable competitors to NSX and Contrail in the overlay SDN area. Nuage though seems to be much more complete from a product maturity perspective.
I personally like the idea of overlays for a multitude of reasons.
1) I can continue to leverage existing physical infrastructure until there is a real need to upgrade (pure throughput or faceplate) and when I do upgrade...the application services built in the overlay can span the old environment and my new infrastructure seamlessly.
2) With service provisioning through a centralized web interface or automation against an API my operations guys don't have to login to 10 different boxes just to setup a new subnet. So in short...less human effort, faster service provisioning and more likely less human error.
3) My new infrastructure can be completely IP based. No more spanning tree...no more VPC/MLAG, no more nothing except for /30s (/128s) and BGP. This also in my mind will allow me to mix vendors/products if needed...since my only requirement for the physical side of the house is IP and some protocol such as BGP as relatively small scales.
An IBM employee informed me in 2012 that he was depressed at where the industry was heading. Software defined networking was going to allow outsourcing of all I.T. to India where lower wage I.T. staff could create entire Server/network/database structures for the business by request at the press of a button.
Once all I.T. is virtualised and off-shored, what I.T. is needed in house?
That IBM employee is now a teacher trainer at a large University.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
