This is part 10 of 20+ blogs I am writing covering the exam prep guide for the VMware Certified Advanced Professional 6 – Network Virtualisation Deployment (3V0-643) VCAP6-NV certification.

At the time of writing there is no VCAP Design exam stream, thus you’re automatically granted the new VMware Certified Implementation Expert 6 – Network Virtualisation (VCIX6-NV) certification by successfully passing the VCAP6-NV Deploy exam.

Previous blogs in this series:

Part 1 – Intro
Part 2 – Objective 1.1
Part 3 – Objective 1.2
Part 4 – Objective 1.3
Part 5 – Objective 2.1
Part 6 – Objective 2.2
Part 7 – Objective 2.3
Part 8 – Objective 3.1
Part 9A – Objective 3.2 IPSec VPNs
Part 9B – Objective 3.2 SSL VPNs
Part 9C – Objective 3.3 L2 VPNs

This blogs covers:

Section 3 – Deploy and Manage VMware NSX Network Services
Objective 3.3 – Configure and Manage Additional VMware NSX Edge Services

Configure DHCP services according to a deployment plan:
- Create/edit a DHCP IP Pool
- Create/edit DHCP Static Binding
- Configure DHCP relay
Configure DNS services
Configure NAT services to provide access to services running on privately addressed virtual machines

These are all standard networking services which if you work in IT infrastructure you should have a pretty good idea already of what functions they provide.

So lets roll through each one. I will provide a really brief overview of the service and how to configure them on the NSX Edge Service Gateway (ESG). These services are only available on the ESG.

Configure DHCP Services according to a Deployment Plan

In the exam VMware are probably going to ask us to deploy and configure these services in a specific way to meet some design criteria. Make sure you understand how they can be configured and test the functionality in your lab to confirm it is working correctly.

One gotcha to watch out for in the exam. You may need to restart the client DHCP Service on the virtual machine in the following circumstances:

You changed the DHCP Pool settings, Default Gateway or the DNS Server settings.
You changed the internal interface IP address on the ESG.

I see this as a perfect exam bonus point!

Create/edit a DHCP IP Pool

If you are familiar with DHCP then the concept of a IP Pool should be of no surprise. A client configured for DHCP requests an IP from a DHCP Server and the server responds with an IP address from the pool.

You can also statically assign an IP to a VM (like a reservation) – I will cover this later in DHCP Static Binding section.

To create a DHCP IP Pool:

Log into the vSphere Web Client.

Click Networking and Security, then NSX Edges.

Double-click the ESG that you will be configuring the DHCP Pool on.

Click Manage, then DHCP, then Pools.

Click the green + sign to Add a DHCP Pool.

Add the relevant details for the environment.

Click Publish Changes to enable the configuration.

Lastly, Enable the DHCP Service by clicking the Enable button. Click Publish Changes.

Editing a pool is very simple, just make sure you click Publish Changes! And don’t forget you may need to restart the client DHCP Service!

Create/edit DHCP Static Binding

Again, very simple. Just think of this like a Microsoft DHCP reservation.

You can either bind on the VM NIC or VM MAC address.

Click Manage, then DHCP, then Bindings.

Click the green + sign to Add a DHCP Binding.

Note: When you select Use MAC Binding, it doesn’t ask you for the VM Name or the ESG interface to apply to, as the MAC will be unique.

I am using VM NIC Binding below and applying to the Web Internal interface on the ESG. I have a VM sitting on the logical switch this connects to, to test the DHCP settings.

Note: When using VM NIC Binding, to select the VM to bind etc, the logical switch must be attached to the ESG and the VM part of the logical switch. You can also select which NIC of the VM to bind.

The IP Address field is the IP to bind to the VM NIC.

Note: The IP you assign a binding it MUST NOT overlap an IP Pool range i.e. it must not be an IP available from any IP Pool.

Click Publish Changes to enable the configuration.

If you edit the bindings, make sure you click Publish Changes.

To test this Static Binding configuration, I am going to power on the virtual machine Web-01a, configure it for DHCP and see what happens.

And sure enough the VM has been statically assigned the correct IP and details.

Configure DHCP relay

This is a simple concept to grasp. The ESG when configured for DHCP Relay just forwards on (relays) the DHCP request to another DHCP Server. For example you might already have Microsoft DHCP infrastructure and you want to utilise that, so you configure the ESG as a DHCP Relay to forward it on.

Note: Edge DHCP Relay does not support overlapping IP address space and does not support DHCP Service and DHCP Relay configured on the same ESG interface.

Click Manage, then DHCP, then Relay.

Under DHCP Relay Global Configuration, click Edit.

You can add an external relay server to relay DHCP messages by:

IP Sets
IP Addresses
Domain Names
A combination of above

I am going to add an external relay server via IP Address. This address is my Microsoft DHCP Server.

You now need to add a DHCP Relay Agent. A relay agent is the ESG interface that will relay the DHCP messages to the external DHCP Server.

Under DHCP Relay Agents, click the green + sign to Add a DHCP Relay Agent.

Select the vNIC (ESG interface) and Gateway IP that will be used.

Click Publish Changes to enable the configuration.

Configure DNS services

The Edge Services Gateway (ESG) can be configured to forward on client DNS queries.

For example you might configure your ESG DNS Settings to point to your ISP or Google for DNS resolution.

Click Networking and Security, then NSX Edges.

Double-click the ESG that you will be configuring the DNS Settings on.

Click Manage, then Configuration.

Under DNS Configuration, click Change.

I am entering my ISP public DNS Servers.

Tick the box to Enable DNS Service.

Enter your DNS Server IPs, change the Cache Size if required.

Configure NAT services to provide access to services running on privately addressed virtual machines

NAT; Network Address Translation.

The NSX Edge Services Gateway (ESG) can perform Source NAT or Destination NAT.

NSX Source NAT (SNAT) is generally used for internal to external traffic. The source address is translated to an external address. The external world never sees the internal IP address.

An example where SNAT is used would be internal corporate machines for end-users that connect to the Internet for web browsing etc. They have an internal IP address and the ESG translates that to an external IP address. Most likely the SNAT would be configured to translate the entire subnet that these machines reside on. A small organisation might only have one public IP address, so utilising SNAT allows the ability to share that one public IP with many.

NSX Destination NAT (DNAT) is used for incoming traffic. The traffic is coming from external sources (i.e. Internet). The external destination address is translated to an internal address. NSX also supports Port Translation.

An example of where DNAT would be used is if you have an internal web server. The web server has an internal IP address and is not connected to the Internet. You have configured DNAT to translate an external IP address to the internal address of the web server. Additionally, the external connection may be coming in on port 5150 and it is port translated to port 80 to the internal web server.

Configure Source NAT (SNAT)

OK, an example of why to configure SNAT and then how to configure it.

I have subnet of 500 VDIs that end-users consume for desktop services. I need to allow all these VDIs to access the Internet. The logical switch that these VDIs are connected to is called ‘VDI Network 1’, with a network address space of 172.32.1.0/23. I want to translate the entire subnet with one rule to my single public IP.

Log into the vSphere Web Client.

Click Networking and Security, then NSX Edges.

Double-click the ESG that you will be configuring SNAT on.

Click Manage, then NAT.

Click the green + sign to Add a SNAT Rule.

Choose the logical switch it is applied to (VDI Network 1), the internal source network and CIDR (172.32.1.0/23) and the external translated public IP (211.69.128.45 fake).

Click Publish Changes to enable the configuration.

Configure Destination NAT (DNAT)

Here is an example of why to configure DNAT and how to do it.

Say I have an internal IIS web server that is configured with an internal IP address of 172.16.0.165 on port 80. I have a public IP address of 192.168.1.1. I tell all external users if they want to connect to my awesome web server they need to hit 192.168.1.1 on port 5150 i.e. http:192.168.1.1:5150.

I need to configure a DNAT to allow the external IP, protocol and port to be translated to the internal IP and port. Let’s roll through this.

Log into the vSphere Web Client.

Click Networking and Security, then NSX Edges.

Double-click the ESG that you will be configuring DNAT on.

Click Manage, then NAT.

Click the green + sign to Add a DNAT Rule.

Choose the logical switch it is applied to (External), the original external source IP (192.168.1.1), the protocol (in this case TCP), the original external port (5150), the internal translated IP (172.16.0.165) and the translated internal port (80).