Software Defined Stuff

vmware-nsx

 

So, this is going to be a bit of an informal blog post, but I’m in the middle of a weeklong boot camp for VMware NSX and I wanted to share a few things I’ve learned with the internet.

First, this is one of the first times that I’ve had a chance to get down-and-dirty with VMware. Shameful, I know, but I’ve really been more historically focused on layers 1 – 4. So I appreciate the chance to see things from the other side and broaden my horizons.

Second, and this was the topic of much debate in the class, I think that NSX is going to require that the virtualization team learn networking. One of the big bottlenecks in IT without NSX in place is waiting on the network team to make changes to the physical infrastructure to accommodate the changes put in place at the virtual level. NSX now allows the virtualization team to deploy virtual switches, routers, and firewalls (making L3 routing between hosts in separate subnets possible in a strictly virtualized environment without having to hairpin on the physical network) AND it abstracts out the hardware layer when traffic needs to go between hosts. Frankly, the networking team is not going to be the ones logging in to VMware and creating the new virtual switch port groups every time a change needs to be made…. That’s going to be the virtualization team.

As a side note, NSX’s virtual environment still plays by the same rules as physical networks, so the networking knowledge that you’ve obtained will not go to complete waste in this “bold new future.” OSPF still has all the same timers and requirements, you still need to redistribute routes, subnetting didn’t go away, and good old BGP is still trundling along. And yes, the VMware virtual router can interact with physical routers, creating adjacencies and sharing routes and all that good stuff.

Third, in a completely virtualized environment, this really simplifies the maintenance and design of the physical network. NSX uses VXLAN tunnels to achieve L2 adjacency between VMs. These tunnels are automagically constructed in software, and can be torn up and torn down regardless of where the VM winds up in the datacenter as long as there is basic connectivity between hosts. When I was working through the MASE exam earlier this year, I felt like HPE was shouting to the heavens “Look at us! We can do all this finicky L2 extension to satisfy that blasted vMotion requirement, same as everyone else! We have TRILL! We have SPB! We have VPLS! We have EVI!” Well, now it seems to me that all that doesn’t matter as much anymore because all NSX requires to simulate L2 adjacency across the datacenter is underlying IP connectivity and an MTU of 1600 or more. You can picture the physical network as a rock solid underlay that shouldn’t require tweaking after the initial setup and NSX as the overlay that constructs tunnels over top of it. The networking team of yesteryear can create one big BGP datacenter and let it run… and NSX will do what it needs to do without any outside intervention required.

Fourth, I would highly recommend taking a look at this technology or a similar tech if you’re a network engineer. I know, I know, it’s marketing heavy and virtualization of the network isn’t happening as quickly as any of the highly paid experts predicted, but it is happening. Personally, I would rather be the one having fun designing the network layout in VMware rather than be the one ensuring that the physical underlay is still in place.

Early morning slap-dash blog post with my two cents, make of it what you will.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s