VXLAN Troubleshooting – esxcli commands

So with the release of VMware’s NSX™ product, some of us may have already started down that road of playing with it in our labs.  VMware NSX™ is the network virtualization and security platform positioned as a key part of the Software-Defined Data Center (SDDC).  You can check out more on NSX™ on VMware’s site here: http://www.vmware.com/products/nsx/

After sitting through a great class on NSX taught by @trainingrev in Austin, TX, I have decided to share some of the awesome information I came across about some esxcli commands that can be used to troubleshoot VXLAN from your ESXi hosts.  For those of you who don’t know what VXLAN is or what it can do, here is a quick and short description is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants.  The scheme and the related protocols can be used in cloud service provider and enterprise data center networks.

For more information on VXLAN, you can look at the actual IETF submittal (http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-09) or check out this whitepaper from Cisco.

So let’s begin, shall we? Read More…

VMworld 2014 Session Public Voting

So it has been a minute since my last post and I hate that this is my newest one…OK…so maybe I don’t hate it!  Anyway, the session voting is open for the public for VMworld 2014.  So in an effort to continue my last three years, here are the sessions that I have submitted, along with people like Joerg Lew (vcoportal.de) and Mike Preston (mwpreston.net):

vmworld-jbSo be sure to go vote for the above sessions so you can be one of the people I thank for making it possible for yet another year.  You can vote by going to http://www.vmworld.com/voting.jspa and casting your vote by clicking on the “Thumbs Up”.  If you don’t have an account on the VMworld site then sign up for one…it’s free! :)

I look forward to seeing some of you there!!!

ESXi 5.5, Cisco B440 M2 with 1TB+, and Cisco VIC 1280 Bug

The other day we noticed some odd behavior from some blades in a somewhat large environment.  The environment is a mix of B200 M3 and B440 M2 blades.  The oddity was random and intermittent disconnections from storage and/or full unresponsiveness in vCenter.  Something that caught my eye was the fact that it was specific to the B440 blades in the environment.  In all actuality, it was spread between multiple sites as well which lead us to believe that it was related to ESXi or the B440 blades.  We ruled out anything with storage and networking because the effects would be more widespread if that were the case.

Me being the VMware guy, I proceeded to look at it from my side of the fence.  Jumping into the logs I found a numerous amount of odd errors on the B440 blades in the vmkernel.log.  Here is a snippet of those errors:

Read More…

vCNS Manager Users and vCenter Group Authentication

Figured I would post this since it didn’t seem that this was documented anywhere.  This is in regards to utilizing a vCenter Group for authentication into the vCNS Manager UI.  Most of the time, with AD credentials, we tend to use the shortname.  For instance, VSENTIAL\james or VSENTIAL\vCNS Admins, is what we would assume would be proper for use.  When adding a vCenter User to the vCNS Manager Users it works with the shortname.  Alas, when using the same method for vCenter Group it doesn’t allow anyone to login who is part of that group.  Come to find out you need to use the FQDN in the group string.  For example, vsential.lab\vCNS Admins.

Just figured I would document this since it isn’t stated in the vCNS 5.5 documentation or anywhere else I could find.  Hope this saves someone from frustration and wasting time!  Enjoy!

1 2 3 25  Scroll to top