I’ve been really lucky over the last few weeks getting to do some deep dive workshops on NSX-T and will be blogging a lot about the good the bad and the ugly over the next few weeks (really good timing for “Blogtober” right?!)
First things first the documentation, for the moment at least, is a little bit on the light side. VMware are obviously working on the documentation as I am starting to see some more become available in the public domain but it certainly wasn’t as well documented as other GA products.
This leads onto my first topic, as I think it’s quit a big one!
I’m going to post about the new routing and switching technologies/methodologies used in NSX-T as they are VERY different from NSX-V in the next few days but for now let’s assume there is a need to move away from the well known and loved Distributed Switch (start looking up the Opaque Switch). Put simply you can’t run a vSphere Distributed Switch on a KVM host, the price for delivering a Hypervisor agnostic SDN solution means we need to introduce a new type of virtual switch.
No big deal right?
First apologies for all the NSX quick short sharp posts recently as I was working through the blueprint for the VCAP-NV exam. I have been working with NSX everyday for the last year or so and decided it was time to get the VCAP-NV out of the way, unfortunately I decided to put myself under a load of time pressure as I booked the exam for about 3 weeks after I started to study… hence the multiple blog posts every night!
I have already sat and passed the VCAP-DCA so had a reasonable idea what the format of this exam might be like i.e. too many questions and not enough time 🙂 The exam system is based on the familiar VMware Hands on Lab interface which is a huge improvement over the last setup in my opinion. There are a couple of tips that are called out at the start of the exam which are well worth doing (setting the manual to float, changing the screen resolution, maximising the screen real estate as much as possible etc.) as the exam kit, at least in the exam centre I was, is still a single tiny monitor! Not what I am used to! Continue reading
This one stumped me for a bit (I also might have completely misunderstood it)!
In order to configure Activity Monitoring for a Security Policy I think we need to right click on the “Activity Monitoring Data Collection” Security Group and select Apply Policy:
From here we can apply activity monitoring to existing (or create new) Security Policy:
Configuring Network Introspection is identical to the Guest Introspection process in my last blog, difference being we need to create a service manager before hand:
To do this click on Service Definitions then Service managers:
Install Guest Introspection
Installing Guest Introspection installs a new vib and a service virtual machine on each host in the cluster. Guest Introspection is required for NSX Data Security, Activity Monitoring, and several third-party security solutions.
If you want to assign an IP address to the NSX Guest Introspection service virtual machine from an IP pool, create the IP pool before installing NSX Guest Introspection.
1. On the Installation tab, click Service Deployments.
2. Click the New Service Deployment icon.
Troubleshoot DHCP service issues
If you are troubleshooting make sure you have enabled logging and changed the mode to debug or error etc. This sends the logs to the syslog server configured for the ESG.
You must restart the DHCP service on client virtual machines in the following situations:
- You changed or deleted a DHCP pool, default gateway, or DNS server.
- You changed the internal IP address of the NSX Edge instance
You first enable the L2 VPN service on the NSX Edge instance and then configure a server and then a client. I’m going to try and use a Hands on Lab to spin up two ESGs and stretch a L2 network between them both.
You need to use the Trunk interface to setup L2 VPNs, so here are the steps for that:
1. Click on Settings tab. Click on Interfaces Select a vNIC and click on the pencil icon to bring up the Edit NSX Edge Interface wizard.
2. Enter an interface name then set Type: Trunk. Click on the Select link next to the text box for Connected To and attach the interface to a standard or distributed port group:
You normally download the Technical Support Logs from the Edge Services Gateway if experiencing issues.
Should you be running the ESG in HA mode the logs for both are downloaded at the same time. Select the Edge Services Gateway that you wish to download the Technical Support Logs from.
Right-click and select Download Tech Support Logs:
Once they are gathered click Download and then save them:
SSL VPN-Plus Service
You can run some troubleshooting commands from the command line of the Edge Services Gateway (ESG) that is hosting the SSL VPN-Plus service. SSH or open the console of the ESG.
The full command list available:
To check the SSL VPN service status: