When working with a colleague recently on an NSX-T 3.0 environment that utilises VDS 7.0 rather than N-VDS, we came across something which initially stumped me. If you were to try and create 2 Distributed Port Groups with the same name on the same vCenter the following error is displayed, which is expected. So what would happen if we created a NSX-T Segment with the same name as one already created through vCenter? ...
I was onsite implementing NSX-v for a customer, and part of the installation in this environment requires that we allocate the VTEP pnics to the VXLAN transport VLAN. To do this I had to liaise with the Network Operations guy. After laying it out for him that although these VTEP interfaces are going to be used for “VM Data” (his words, not mine) they will only need to be an access port in VLAN xxx, the penny finally dropped for this guy on why they are going the NSX-v route. ...
Have you ever had the problem of working on a unstable network connection and your network drops out. Well this happened to me this morning, but whilst it happened, I was actually connected to my NSX Manager via SSH and in configuration mode. When my network connectivity returned (4G) and I could SSH into the NSX Manager, I was greeted with the following: VTY configuration is locked by other VTY nsxmgr> ena Password: nsxmgr# conf t VTY configuration is locked by other VTY nsxmgr# I asked around internally and it turns out that there is currently no elegant way of disconnecting the session which has crashed. I will be following this up so that hopefully an elegant solution will be included in a future release. ...
One of the main reasons for customers wanting to implement NSX for vSphere is the fact there is a RESTful API which can be leveraged to drive the whole system. In a standard NSX-v installation, by default, the only account that has API only privileges (and no vSphere Web Client privileges) is the NSX Manager “admin” account. It is possible to use vSphere SSO accounts to interact with the NSX API, however this will also allow vSphere Web Client access (although they wont be able to view or access anything once logged on without granting specific vCenter rights). ...
Due to a recent lab rebuild, I needed to manually remove the NSX VIBs that were installed on my ESXi host, and thought I would document the process so I can remember it in the future. Removing the NSX VIBs from a host manually does not remove the configuration stored on the NSX Manager, so care needs to be taken when doing this. Depending on the version of NSX-v installed, the number of NSX VIBs installed will vary. ...
Whilst working on a little side project of mine, I wanted to be able to submit a REST API call against a NSX Manager. At first I was just going to use shell_exec to execute one of my python scripts, but after a bit of investigation, I found that I could use the PHP Client URL Library (cURL) . It took me a little bit of time to get it working just the way I wanted, but now that I have the basics, it should be simple to be able to do most things through a webpage. ...
Changing NSX-v controller passwords is a question which comes up quite a bit with customers. Often because the passwords chosen at deployment time are either too complex to type in on a VM console session, or on the other end of the spectrum, they were set to something easy to type during deployment, and now need to be changed. When deploying NSX-v controllers during the setup phase, the password is set when deploying the first controller. ...
Whilst working with a customer recently, we encountered a situation recently where we were required to run a packet capture on a VCSA (vCenter Server appliance) version 6.0. Being a Linux appliance underneath, the tool to use is tcpdump, but by default tcpdump is not actually installed by default. There are a few steps you need to follow to get it installed. SSH into the VCSA which should get you to the standard appliance shell ...
On various engagements I am involved with, I often need to produce some code to add or delete objects from NSX-v. These objects in general are things like IP Sets, MAC Sets, Security Groups, Security Tags, Services, Service Groups, Security Policies and even deleting the FW rulebase itself. Until recently I was doing this manually as I was dealing with relatively small numbers of objects, however on a previous engagement I was working on a script to import up to 33,000 objects and when testing the script in a dev environment, we needed a way to go through and delete everything we had just imported and set it back to “defaults”. ...
So following on from my previous post (NSX-v: ESG Packet Capture), today we run through how to do a packet capture on one of your NSX Controllers. Why would you want to do this I hear you ask? Well I had a situation recently where I had some unexplained behavior and I needed to make sure that a particular packet was physically arriving at the controller as it had to pass through several VRFs and a FW or two. ...