There’s been a lot of traction and interest around software defined networking lately. I posted a video blog last week comparing features and functionality of VMware NSX vs. Cisco ACI. A reader left a comment on the post with a really interesting question. Since I have heard similar questions lately, I figured it would be worth addressing it in it’s own post.
The question was:
“Great discussion – one area that needs more exploration is when NSX is riding on top of any physical infrastructure – how is the utilization and capacity of the physical network made known to NSX so that it can make intelligent decisions about routing to avoid congestion?”
Here was my response:
“You bring up an interesting point that I hear come up quite a bit lately. I say interesting because it seems like everyone has a different answer to this challenge and a couple of the major players in this space seem to think they have the only RIGHT answer.
If you talk to the NSX team at VMware, they would argue that since the hypervisor is the closest thing to your applications, you’d be better off determining network flow requirements there and dictating the behavior of that traffic over the network as opposed to reactive adjustments for what could be micro-burst type traffic that could lead to a lot of reaction and not much impact.
If you were to pose the same challenge to the ACI team at Cisco, they would argue that without intimate visibility, control and automated provisioning of active network traffic AND resources, you can’t make intelligent decisions about behavior of application flows, regardless of how close you are to the applications themselves.
I think the short answer, in my mind anyway, to the challenge you outline lies within the SDN/API integration side of the NSX controller. I always need to remind myself that NSX is a mix of SDN and SDN driven Network Virtualization (NV) and Network Function Virtualization (NFV). That being the case, the behavior of the NSX NV components can be influenced by more than just the NSX controller. Through mechanisms native to the network like Netflow, NBAR2, IPFIX, etc. we can get extremely granular application visibility and control throughout the network itself and, by combining that with API NSX integration, we can evolve the NSX solution to include intelligence from the physical network thereby enabling it to make decisions based on that information.”
Like I said, an interesting question. There’s a lot to talk about here and everyone (myself included) has a lot to learn. If you have any more questions around software defined networking, leave a comment or reach out to us at socialmedia@greenpages.com and I’ll get back to you.
By Nick Phelps, Principal Architect