Tuesday, September 13, 2016

Opinion - NSX's tipping point, aka, it's first "vMotion"

As I study for my VCP6-NV (6.2) beta exam and I read Elver's excellent book, my thoughts wander off to the VMworld 2016 vExpert party and Pat Gelsinger explaining that he thought NSX hadn't reached it's big "oh wow!" moment yet - like when you showed someone a vSphere vMotion for the first time.

The more I've thought about what would make that happen for me, I realize that I believe that NSX should control IPAM in an organization. Hear me out.

IPAM - IP address management - is a perennial challenge in organizations. Any request for a new server is waiting on three things - approval, assigning specifics and delivery. Where it comes to assigning specifics, IPAM is a function that is either shared between network and sysadmin teams, or is owned by the networking team, with an enterprise solution deployed in the best cases, or an excel in a share in the worst cases. This is one of those things that I know very few organizations handle in exactly the same way today.

Lots of cloudy org's use DHCP instead of static IPAM to avoid this time-consuming step - why waste time on IP address assignment, when it's just a number. However, the majority of enterprises are still managing static IP assignment and probably won't move to this DHCP model (for many valid, and traditional, reasons).

NSX has a phenomenal capability that most other networking products don't have: it has native and absolute connections to each server's OS thanks to VMware tools. That means that NSX could in theory always 1) know all the real IP address of a server 2) change the IP addresses as needed 3) confirm that IP addresses are available using ARP as well

I bolded the word control in my statement above. I visualize an NSX-integrated IPAM solution where administrators never again have to set a static IP on a server. Once the VM is turned on and a nic is assigned, I envision NSX ensures the IP address on that VM and corrects/sets if it finds it to be non-compliant.

When your IP address management is tied to a solution that has the level of interaction that NSX has, talking about VLANs and IP addresses could become a thing of the past. This means you can gain the advantages of DHCP (just don't worry about assigning the IP addresses) while still having static addresses in your environment. It's a win-win scenario - no one can change an IP if it's not validated in the IPAM, and no one assigns an existing IP (or wrong IP address details, think of all the other things like DNS server information) that they shouldn't.

This, co-incidentally, also makes changing things like the default gateway IP on a whole subnet of servers a breeze. Try to do that today in a 100% automated, "this will just work" manner, without spending a lot of planning, testing and resources!

The other side of the IPAM coin - another big thing - that NSX should potentially do is help, or fully control, DNS after an IP address change. Remember, NSX sees every packet out there. 

If we just let it help (to appease MS AD for example) DNS, then I see it going like this. Sync operations after a change, in it's default settings, can take a while, due to several things. NSX could inspect the packets and since it knows the authoritative information thanks to it controlling IPAM, could even help DNS information to spread quickly, by doing things such as dropping outdated replies from DNS servers and prioritizing replies from updated ones.

If we let it fully control, then DNS sync operations become a thing of the past - with the level of effort that we push a change to each host's vib, the DNS information in the network is automagically updated. Wouldn't that be a sight! Would it be called Distributed DNS?

In essence, what I'm proposing is to let NSX take care of traditional "building block" services that a typical network needs. Why stand up DNS servers when each host can participate in a distributed and updated mesh that just provides that service? Why assign IP addresses when you have an underlying control plane that sees all traffic and can do it for you, in a much more reliable fashion than you could? This idea does not conflict the NSX designs of today, where we manage the network's IP addresses in a control plane, and the actual workloads are in a different plane.

I'm sure there are many more services that are crucial in today's TCP/IP world that could potentially be integrated - network virtualization is simply that big of a deal. TCP/IP got to where it is today because of it's robust survivability, but as many vendors with optimizations have shown us, there is both a functional and operational overhead that can be tweaked. That world is changing - we don't have to wait because of unknowns - with NSX, we know!

We can start abstracting more and more from the details and simplify. We already see this in the firewall rule making capabilities of NSX today, and I think the tipping point for NSX will be when the workload IP details will be  a "worry of the past" - IP addressing and name resoution "just work".

Don't agree? Would love to hear your comments below, or through twitter!


Monday, September 12, 2016

NSX news you should not have missed (September 2016)

This is a very quick recap of some major events which have happened within the last few months regarding NSX:

1) The first major licensing change for NSX was announced back in May 2016. If you are buying NSX today, you should read KB 2145269 . The typical customer that starts with micro-segmentation needs at least the Advanced tier, while customers upgrading from VCNS (which is no longer under support on September 19, 2016) can use the cheapest version of the product. This post by the register is a nice summary.

2) NSX 6.2.3 was recalled as it had problems (KB 2146227 and KB 2146293 are two examples) that caused downtime. 6.2.4 was released shortly after to correct this, and customers were advised to skip 6.2.3. This link is great to keep up to date with any NSX KBs and issues: http://blogs.vmware.com/kb/nsx

3) VCP-NV Exam news : the first version of the VCP-NV exam, VCPN610, was retired on November 30, 2015. The current version is called VCP6-NV and its code is 2V0-641. This is based on NSX v6.0. A new version of the exam, 2V0-642 which is based on NSX 6.2, is now in Beta (go to mylearn.vmware.com, head to the Pearson site using the new single sign on, and check under the Beta category). At a cost of only $50, it's worth taking, even if the timeline makes this more of a "practice run" than a serious study target. 

4) The official study guide for the VCP6-NV 2V0-641 was officially released August 17. This book was written by Elver Sena Sosa, who I had the pleasure to meet in VMworld (more on that in another post). I bought my copy and had him sign it :)

Right now you can get it a discount using this post-VMworld promotion: http://www.pearsonitcertification.com/promotions/vmware-press-138356

If the promotion expires, you can also get it from my Amazon affiliate link below and you would automagically send me a very small cut of the sale price :)

vExpert NSX!

Last August 17 the vExpert NSX program was announced to the world. 

"vExpert NSX" is a sub-program within VMware's vExpert program - only current vExperts were allowed to apply. As a believer in the trans-formative power of NSX and network virtualization in general, and thanks to the VMUG/vBrownBag contributions and posts in this blog, my application was accepted and I am very proud to have been awarded this designation.

I believe I have a particular background which helps me in helping others for this topic:

  • I have a networking education background (took up to CCNP3 in my college years) of which I never had the opportunity to actually work in a dedicated fashion (ie, I was never a network engineer, the closest was a Network Control Center engineer which did give me access to routers and firewalls, but it was not my responsibility to design and do changes)
  • I enjoy networking in general. Currently I am a fan of the OpenvSwitch work that is entwined with cloud computing and OpenStack and is also related to NSX, and I've always had an admiration for the OpenBSD project, their pf firewall and their network implementations
  • My day to day role is a dedicated VMware engineer serving a large enterprise environment - and I'm busy! So my posts won't be fluff :)
  • I speak both English and Spanish fluently and enjoy making connections in the vCommunity
Taking these things into consideration - things I'd already covered somewhat in the mission for this blog - I gladly accept the vExpert NSX award and further commit to help others in learning and adopting NSX and related technologies. I will blog in both English and Spanish as the content becomes available, with a focus on not repeating what is widely available but highlighting relevant news that should not be missed, covering certification exams, and taking you along on my journey.

As always feel free to reach out on twitter and let me know if I can help!