Alright… so Cisco announced a Q4 2012 availability of a new version of the Nexus 1000v virtual switch in September. Of course, the release is going to have so many features and functions that there is no way we could not justify paying the $695/CPU that they charged (plus support) for the virtual switch.
A mere 4 hours into October, a blog post was published from Cisco (http://blogs.cisco.com/datacenter/new-nexus-1000v-free-mium-pricing-model/) dramatically reducing the cost of playing with their toys to a big fat $0 (plus support). Check out the break down of the features:
[Note: the graphic above was taken from the blog post and can be found by following the link above]
I have three very differing reactions to the announcement that I am struggling with determining which one wins out:
1. Nice move Cisco
This was a very smart move on Cisco’s part. The adoption of the Cisco 1000v has been anything but spectacular. Functionality sounds great from a high level. However, when compared with the price and availability of the VMware Distributed Virtual Switch that is available out of the box, why make the jump to a per CPU solution?!
Plus, with the up and coming virtual network changes coming our way, getting customers to buy in to the Cisco ecosystem before will get them locked in for whatever the future holds. Nicira has the potential to shake up the virtual switching in upcoming releases.
2. Great… more people using Nexus 1000v
My experiences in $CurrentJob involve using an environment with 1000v deployments all over the place… and the results have been less than spectacular. All too often, a networking issue arises that we lose visibility to, ports being blocked with no explanation, VSM upgrade failures, VEM upgrade failures, etc… To say I am a fan of the 1000v would be pretty far fetched. Probably better stated: To say I am a fan of our 1000v implementation would be pretty far fetched. I am sure 1000v implementations out there are more successful. I just have a hard time recommending to people to implement the 1000v in their environments when the provided distributed virtual switch is good enough.
3. Great! More people using Nexus 1000v
See what I did there?! (“…” vs “!”)
In my self-admitted limited times with the Nexus 1000v, it really seems like there is a lack of people that know ANYTHING about the 1000v. Understanding the NX-OS side of the switch is critical (obviously). But, so is understanding the nature of a virtual environment (especially with vCloud Director making more of a play in datacenters) and the virtual environment implemented (1000v will support VMware, Microsoft, Xen, and KVM hypervisors) is equally as important. The nature of the workloads and behaviors change.
So, by having more people using the Nexus 1000v, there will be more and more people available as “experts’ or at least legitimately “experienced” with the product than before. This can bode well for future implementations for sure.
Ultimately, I think this is a good move. Cisco is acknowledging that getting another “advanced” product into the ecosystem a gratis helps drive purchasing for other Cisco products in the datacenter. Plus, at a much higher level, it is an acknowledgement in the direction that the market is moving… and they’re trying to get a toe-hold before the SDN wave takes hold. Will this fix what I am working with? Not one bit. Will this fix what I will be working with in the future? With more people having experience, it may for sure.
Can you believe it?! Issue and resolution in a single post! What a day!
Like many businesses, my company is experiencing penetration of OSX-based machines in our environment. Personally, I love the products… Work-ally, they drive me up the wall. But, that is the topic for another post some time in the future.
A couple of the new machines are MacBook Pro devices. With the latest version of OSX, 10.6 – Snow Leopard, Apple has licensed the Cisco IPSec VPN client functionality and has included it baked into the OS. Pretty cool, huh?! We have seen the same functionality added with a recent version of iOS for iPhones and iPads. So, these devices can natively connect to an IPSec VPN tunnel without installing the Cisco VPN client.
Our environment hosts VPN connections through a nice ASA at the datacenter. There have been no issues terminating VPNs at the ASA using devices with Cisco VPN Client installed as well as proof of concept connections using iPhones and an iPad. Everything just works… as it should.
The song changes, though, when we tried to connect the new Snow Leopard laptops to the corporate network with the baked in VPN client. Configuration worked well. Group name, server name, PSK, username, and password. Everything was quick and easy. Both the ASA and the Mac was showing successful connections! However, we were missing something. It did not work quite right.
The issue was that the VPN client had no idea which traffic to send over the VPN and which traffic to send over the public Internet (gotta love split horizon configurations). Routes existed properly to route internal 192.168.0.0/16 traffic, which was excellent. I could ping everything I needed to over the VPN connection and reach resources via IP address. However, the issue appeared with proper DNS lookups.
Ideally, and as we have seen with the Cisco VPN Clients, iPhone, and iPad, when the client connects, the internal DNS servers are passed along to the client to handle the resolution. In this situation, though, this was not the case. Everything was resolving using external DNS. So, any internal services were not available to the client because DNS was not being queried properly.
As a work around, in the VPN configuration advanced settings, we could specify internal DNS servers and search domains… which worked. Upon completion of the VPN session, the changes would need to be reversed. For the average end user, this was a really ugly and unprofessional way to operate. Plus, this SHOULD NOT BE THE CASE… out of pure principle.
At this point, I was pulling my hair out. Seriously… what could be the problem? Everything works out perfectly for all of the other clients… including the iPhone and iPad. There had to be something missing! But, what could it be…
Well, after poking around on the ASA (and confirming online), it turns out that the OSX baked in client needs the addition of a single group policy attribute. Specifically:
group-policy PolicyName attributes
split-dns value internal.domain internal2.domain
This nifty little line of code tells the OSX client that for the listed domains, you should query the internal DNS for resolution. Otherwise, continue using the standard resolv.conf DNS servers for resolution.
Why in the world would we need to make this change when other Apple provided Cisco VPN Clients work perfectly without it? To this day, I still have no idea. But, it works, and I am going with it. Logically, the line makes perfect sense… just not the necessity of it.
So, if you are in a similar situation, I sincerely hope this little nugget of joy stops you from pulling your hair out and having embarrassing random bald spots as a result… maybe you can convince your company to expense an new hat until your hair grows back.