SDN and the coming Net'apocalypse

What are everyones thoughts on the new SDN buzzword in the industry? What kind of impact will we see on Capx and Opex for the infrastructure landscape? What should a networking professional learn to prepare for the next 5 to 10 years in the industry?

I've seen so many articles and opinion columns on the subject - I'm not sure what to think.

I love change and technology maturing, as do many of you, but is this just another throw around word like "Cloud"?

Let's hear some thoughts!

~

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Jackace

Once it finally matures (and it's use become more mainstream) it will create a lot of change in the industry, but I don't see it maturing and hitting mainstream as quickly as some are saying. I think the biggest change is going to be for entry level and intermediate levels. There just won't be as much need for people to do the day-to-day repetitive tasks. I think those who apply themselves and strive to become true experts, they will always have a solid career, especially if you learn to script and do some programming.

jmritenour

I think there needs to be some standards around it before it really goes anywhere. At this point, VMware is doing their own thing, MS is doing their own thing, Cisco is doing their own thing, and that's not even getting into open source SDN.

Part of me feels like it's just another ploy to put off actually learning/using IPv6, but that's just me.

networker050184

Just another tool to use to get the job done. There are already software platforms in use that do things like manage and configure traffic engineering tunnels on the fly so centralized software based network control is nothing new in our industry. I'd love to learn everything about it I can so when/if the time comes I'm still able to do my job.

it_consultant

I have been reading up on this lately and once we get a better handle on how SDN will be implemented in most of our enterprises it will dramatically change our lives. Ethernet is already very reliable so the main driver will be whatever automated processes can be offered through vSphere and System Center. Eventually we will be telling younger admins how we used to have to use a "command line" to control our switches. They will be amazed.

pert

I think low level network administrator positions will go the way of the dodo, it will become harder than ever to break into the field, and that the people at the very top will make even more.

darkerz

Does anyone think SDN will be a transition from manual implementation and deep understanding of protocols to managing devices, flows, policies, quality assurance, monitoring, etc. from a central application or series of applications?

It seems like the potential is there, but it will take existing network engineers and have them learn both SDN concepts & networks with traditional ones, by the time the transition is complete... We'll see network engineers enabled into more "analyst" and "specialist / operator" roles.

I'm unsure how to feel about this, because I know the next 10-20 years we'll see a lot of these "boxes" being built out will stay until they need to be replaced. But a part of me wants to learn to program so I can take this new trend and ride it hard at a Sr. level, hehe.

What kind of languages would people need to learn to contribute to this new "evolution"?

networker050184

For larger networks there has been a transition away from manual implementation for years now. No one wants to go configure 1000+ routers. People logging into boxes and running commands leaves room for user error. Things are as scripted and hands off as can be in larger networks. Putting that much into automation just really doesn't make sense in smaller deployments though and probably still won't in the foreseeable future.

I don't think a deep understanding of the protocols will ever go away though. SDN is just another way to implement these protocols. Not having an understanding of the underlying technologies will get you in trouble just as it will now.

I wouldn't worry about learning programming language unless you plan to develop SDN rather than being an admin/engineer. I've played with quite a few of the implementations at NANOG and other conferences and programming knowledge wasn't needed.

The only real change I see coming with this is the centralized control plane. Again this is something that is already in the network with things like multishelf platforms such as Juniper T series and Cisco CRS.

it_consultant

From what I have seen from people who are in the "know"; the aim of SDN is to eliminate as much of the protocol suite as possible. So yes, there will be a transition to managing flows from a centralized location.

darkerz

it_consultant wrote: »

From what I have seen from people who are in the "know"; the aim of SDN is to eliminate as much of the protocol suite as possible. So yes, there will be a transition to managing flows from a centralized location.

I've begun to study the topic quite abit, the videos and documentation all aim to destroy the RFC's in regards to the pool of protocols used...

...

When we talk about OpenFlow, specifically.

Vendor specific SDN seems to understand the criticality (and importance, due to their sheer market domination cough Cisco Juniper Brocade Extreme etc) of holding onto their vendor specific hardware, their NOS's, their protocols, their CLI, etc.

I know a handful of CCIE level consultants who are a little shaken by the concept and have admitted to avoiding the topic all together because the SDN prototypes that aim to eliminate the protocols they've mastered would render their decades of expertise irrelevant.

So,

If SDN aims to eliminate existing protocol stacks replaced with a single controller, a single control and single forwarding mechanism on LAN, WAN and ISP/CORE infrastructure, what is one to do?

networker050184

The point of that is to make forwarding decisions on traffic flows or custom constraints made by the operator such as ingress port, application etc. In essence a 'controller' that tells the 'dumb switches' how to forward traffic based on these rules rather than things we use now like routing metric to destination IP. There are already technologies that do this as well (content switching for example), but not in a centralized 'controller' and 'dumb switch' model.

What is one to do? Learn it!

One example that was used on a few of the presentations I have sat through is traffic ingress on Switch A port A is to be egress on Switch F port A. So a rule is created and pushed to all switches in the network that says any frames entering this port on this switch is sent to switch F and out port A. So it's not recreating the wheel, it's more of just using different forwarding rules and consolidating the control plane.

gorebrush

So, what is SDN exactly?

I don't even know what it stands for...

EDIT: Quick scan read of Wikipedia means that I don't think it'll do away with anything, probably make life a bit more difficult, but not the end of the world for us networkers.

As said above, just another tool for the job

networker050184

Software Defined Networking. In laymen terms making forwarding decisions on customized programmable rules rather than our current destination address based forwarding on a per device basis. A controller (usually a cluster of servers) is programmed with these rules and pushes them to the switches (current biggest way to do this is OpenFlow but there are also vendor specific protocols) to forward the traffic.

Think of it kind of like a 6500. The supervisor engine runs the control plane and then pushes the forwarding table to the line cards. Only with SDN you are making decisions on custom flow rules.

darkerz

It's like a single control plane but not just for multiple core switches like a 6509-E in VSS mode, but for every single device on the network from sea to shining sea.

...

What kind of magic will work around the entire "single or central points of failure" piece of this mess?

In the real world, not all sites, networks, etc. are stable or immune to latency like the fiber laid in metropolitan areas.

it_consultant

darkerz wrote: »

I've begun to study the topic quite abit, the videos and documentation all aim to destroy the RFC's in regards to the pool of protocols used...

...

When we talk about OpenFlow, specifically.

Vendor specific SDN seems to understand the criticality (and importance, due to their sheer market domination cough Cisco Juniper Brocade Extreme etc) of holding onto their vendor specific hardware, their NOS's, their protocols, their CLI, etc.

I know a handful of CCIE level consultants who are a little shaken by the concept and have admitted to avoiding the topic all together because the SDN prototypes that aim to eliminate the protocols they've mastered would render their decades of expertise irrelevant.

So,

If SDN aims to eliminate existing protocol stacks replaced with a single controller, a single control and single forwarding mechanism on LAN, WAN and ISP/CORE infrastructure, what is one to do?

Short answer, become a sysadmin too. The protocols wont go away completely and the idea that all switches and routers will be controlled by an openflow controller is not practical for on premise equipment or mounted on the sides of buildings. However, in our virtualized datacenters this will become something that we will HAVE to know. Oh, and learn IPV6 too.

Check out the demos on the ride side of this page:

http://www.brocade.com/solutions-technology/technology/software-defined-networking/openflow.page

The "open flow hybrid mode" shows you how to configure a Brocade MLX with an open flow controller. Very cool. This is much closer to reality than people think.

darkerz

My soon to be new environment is using Cisco, Juniper, Brocade and Extreme gear and hybridizing the ways the boxes work - leaving the underlying protocols alone (because they work and have worked for a decade) while implementing controllers and flows on the devices in a similar fashion.

Super exciting!

Does anyone else here work with what we know or "will know" to be as SDN?

~

Jackace

networker050184 wrote: »

I wouldn't worry about learning programming language unless you plan to develop SDN rather than being an admin/engineer. I've played with quite a few of the implementations at NANOG and other conferences and programming knowledge wasn't needed.

This comment was pretty interesting to me. Granted I have no experience with SDN, but I have read a handful of blogs, listened to podcasts, etc and everyone of them seemed to make it sound like SDN will make network admins more like sys admins. We will be doing a lot more of our work with scripts in languages like Perl, Python, and PHP.

fredrikjj

Jackace wrote: »

This comment was pretty interesting to me. Granted I have no experience with SDN, but I have read a handful of blogs, listened to podcasts, etc and everyone of them seemed to make it sound like SDN will make network admins more like sys admins. We will be doing a lot more of our work with scripts in languages like Perl, Python, and PHP.

Why would you develop your own scripts when you can use a nice tool set that actual programmers have developed? As far as I know, sysadmins don't program either for the same reason; their tools are developed by someone else.

instant000

I dislike that it is called "software defined networking" which is just some buzzword.

From my perspective, all networking is software-defined already.

From my perspective, what people are calling SDN is really just centralized control-plane networking.

The same way you can centrally orchestrate all of your workstation configurations via group-policy, they're basically trying to do the same for networking.

As other posters have already stated, people that deploy 1,000s of routers and switches in their environments already utilize automated solutions for pushing configuration changes, tracking changes on the network, monitoring the network, backing up configurations, etc.

Decentralized control is going to be prevalent in smaller environments, and centralized control will be prevalent in larger environments. That is how it has been already.

I do not envision this eliminating network admins. It might eliminate those who refuse to learn something new. For most environments, that usually have only one or two admins anyway, how can they afford to make cuts to that staff?

Now, if this idea was extended (hear me out) to a remote controller (or remotely-controlled controller)

The MSP can do full discovery of your network, and then orchestrate traffic flow. If you have an issue any time of day or night, you have 24x7 support on standby to assist you. If hands on is required, they dispatch a technician to assist you.

This model might work for some businesses. For others, it is a non-starter (need quicker response than a dispatch).

Jackace

fredrikjj wrote: »

Why would you develop your own scripts when you can use a nice tool set that actual programmers have developed? As far as I know, sysadmins don't program either for the same reason; their tools are developed by someone else.

Maybe not actual programming, but I have not met a single sysadmin that didn't script in powershell (Microsoft) or Perl/Python/PHP.

darkerz

Learning multiple languages for scripting and even creating your own programs is super exciting as well - I don't mind dicking around with languages and practicing, userboards, etc. on my weekends if it means my resume will bring me 20-30k more / year because of it.

I will code for food - and for a new car!

What I like is the emphasis will be on intelligent administration, automation, scripting, 24/7 support, packet analysis/captures/debugging, smart provisioning and technical issue resolution - whether you are the MSP or the Enterprise or the Data Center.

I hate configuring new devices, it's mind numbingly boring - so I templated the configs out, and created scripts for my environment to do it for me.

In the SDN future, we're just scrubbing MPLS, BGP, OSPF, STP, vPC's, VDC's, PVLANS, etc. with OpenFlow or something similar, but that TCP/IP layer 1-4 core is still there, Ethernet is still there, a segment is still a segment and a packet is still a packet - a frame is still a frame.

I wonder,

Does anyone at Techexams actually work with any of the proposed SDN controllers in their environments? I would love to hear from them!!

networker050184

Jackace wrote: »

Maybe not actual programming, but I have not met a single sysadmin that didn't script in powershell (Microsoft) or Perl/Python/PHP.

There aren't many networking professionals that work on large deployments that do not script in some sort either. Again, configuring thousands of routers or switches is not something someone wants to do by hand. So write a script!