Software Defined Network

[Dolby]

I've read up a little on SDN and if I understand it correctly, have a question.

My understanding is that it removes the intelligence from the physical hardware, and the benefit is that hardware can be dynamically changed to cope with peaks and shift resources where needed.

What exactly are the resources?

 

[froot]

If I understand correctly, the resources here would be the processing power, and memory.

 

[nand]

There are a lot of protocols and services as well. They could be seen as resources too.

 

[Dolby]

So currently, todays routers, switches etc have memory onboard for the device itself?
Does that mean you'd need an entirely new network for SDN, ie new router/switch/firewall etc etc?

 

[syntax]

SDN is still being 'thawed' out.

You have the idea of it correctly. It separates control and data planes completely.
I did a course recently on it and even after it, SDN is hazy at best.

To answer your question, yes, new equipment will be required. a migration to an SDN network is also going to be a challenging task, and I see it happening in the vm space first across vm clusters before hitting real world devices.

the idea that the network can be elastic and controlled by API's etc is great but its not something i see becoming concrete for some time still.

There are a few vendors who are pushing SDN a bit more than others, ALU for one is doing some decent stuff. Juniper has contrail, which is a now free SDN controller, and they have 'SDN' ready devices, but they still dont really know where they are gong with this.


I saw a lecture about how it might be possible to do Peering with other networks not just based on IP's and ASN's but rather on an application level. I must actually watch it again because my brain is porridge at the moment

 

[srothman]

What syntax said. I have to add Cisco's Nexus 1000V to the list as well. I use it quite extensively in our non-production virtualized environment to provide multitenant service across our Dev/Test/UAT environments.

The beauty, or biggest benefit at least, that I have found with this is that our Devs can use each of the associated domains as upgrade domains without having to change any configs around the networking. This means that they can develop and configure an IP, for example 10.1.1.10, in Dev, and have 10.1.1.10 in Test, and 10.1.1.10 in UAT as well, making their debugging and troubleshooting a lot less complicated.

 

[Dolby]

Thanks guys!

 

[nand]

What syntax said. I have to add Cisco's Nexus 1000V to the list as well. I use it quite extensively in our non-production virtualized environment to provide multitenant service across our Dev/Test/UAT environments.

The beauty, or biggest benefit at least, that I have found with this is that our Devs can use each of the associated domains as upgrade domains without having to change any configs around the networking. This means that they can develop and configure an IP, for example 10.1.1.10, in Dev, and have 10.1.1.10 in Test, and 10.1.1.10 in UAT as well, making their debugging and troubleshooting a lot less complicated.

Links for the last parts please. That sounds really awesome!