aseaz404
Enthusiast
Enthusiast

vRA 7.3 On-Demand NAT Network not receiving DNS info

Jump to solution

First off the versions…

vRA 7.3.0.536 Build 5610496

NSX 6.4.0 Build 7564187

Issue:  When the blueprint is deployed, the VM receives all the configured IP info from DHCP, except DNS.

Setup:  I created a blueprint with a vSphere Windows 10 VM and added an On-Demand NAT Network.  The VM IP settings are configured to receive the information via DHCP.  The On-Demand NAT Network has a parent network profile, external network profile, NAT type (1 to many), subnet mask and gateway assigned in the General tab.  In the DNS/WINS tab I have primary and secondary DNS server along with a DNS suffix, no WINS.  The DHCP tab has the start and end of the range and the IP Ranges tab is empty.  The parent network profile has the same General, DHCP and DNS info.

Troubleshooting:  After I’ve deployed the blueprint and I look into the properties of the Edge VM that was created for NAT (vSphere Web Client, Networking and Security, NSX Edges, name of Edge, Manage) I can see that in the DHCP section the entry with IP range has “Auto configure DNS” turned on and of course the DNS info from the parent network profile (and On-Demand NAT Network) is blank.  If I manually make the change and publish then all works fine.  So it seems that during the deployment vRA does not pass on the DNS settings but instead turns auto configure on.

I’ve tested with other VMs (different OS) and the behavior is consistent.  The Edge VM deployed by vRA does not receive the DNS settings but auto configure is on.

If someone can point me in the right direction it would appreciated.

0 Kudos
1 Solution

Accepted Solutions
aseaz404
Enthusiast
Enthusiast

This is a brief update.  After opening a support case almost a month ago and having the tech support folks have me walk through the same information multiple times, they came back with "this is a limitation of the product" a couple of hours ago.  It seems odd that vRA is not capable of configuring the DNS properties within the DHCP service of a deployed Edge router, particularly when it thinks it did so (if you look within vRA at your Items it thinks it passed on all the DNS settings to the DHCP service running on the Edge router, image attached).  Anyway, as I might have mentioned before, the work around is to hardcode the DNS information within the VM you'll be using in the blueprint.  Of course that could mean having to create multiple VMs, each with different DNS settings, so a little counter to the VMware efficiency mantra and not very elegant.

View solution in original post

0 Kudos
5 Replies
aseaz404
Enthusiast
Enthusiast

It looks like the post has been read a few times so I thought I’d add a few questions to poll the collective wisdom.  All, of course, in an effort to determine my next steps.  I see the possibilities as:

1. The behavior described is expected; focus on finding a work around.

2. You didn’t configure one of the components correctly, go and review the settings for your NSX implementation, vRA network profile, blueprint On-Demand NAT and VM.

3. You’re not understanding how this is supposed to work, go spend more quality time with the documentation and other online resources.

4. It looks like you set things up correctly and something is off with vRA/NSX, look into opening a case with support.

Thank you in advance for your input.

0 Kudos
aseaz404
Enthusiast
Enthusiast

Brief update…

Out of curiosity, I configured DNS on the NSX Edge Gateway, simply to see what effect it would have on the Edge VMs that are spun up by vRA for the On-Demand NAT Network.  Perhaps it would copy the settings, thus if "auto config DNS" was on it could relay the DNS info.  That would still not address the issue as I may need different DNS info for each blueprint VM getting IP info via DHCP, but it was worth a shot.  So I can report that it made no difference.  Basically, the Edge VM deployed in support of the On-Demand NAT Network does not retrieve settings from the upstream NSX Edge Gateway, nor does it take DNS settings from the parent network profile or the blueprint.

0 Kudos
evil242
Enthusiast
Enthusiast

Are you saying that your VMs are not receiving proper DHCP configuration including primary and secondary DNS resolve conf IPs?   Or are you having an issue with establishing DNS entries for each new VM that is provisioned through vRA?

If it is the former make sure your DHCP server has the correct information to serve out for the DHCP range, and/or make sure you have the correct virtualmachine.network custom property established on the blue print.

The later will require some scripting/plugin with vRO to run, configure, and update the VM.

0 Kudos
aseaz404
Enthusiast
Enthusiast

The DHCP service is passing on all the settings except primary/secondary DNS server info and DNS suffix.  When you review the Edge VM that was provisioned by vRA for the On-Demand NAT Network, its DHCP settings do not include the DNS info and the "auto configure DNS" box is checked (blanking the DNS entries).

Adding the virtualmachine.network custom properties does not make a difference to the DHCP service setting running on the provisioned Edge VM for the On-Demand NAT Network.

0 Kudos
aseaz404
Enthusiast
Enthusiast

This is a brief update.  After opening a support case almost a month ago and having the tech support folks have me walk through the same information multiple times, they came back with "this is a limitation of the product" a couple of hours ago.  It seems odd that vRA is not capable of configuring the DNS properties within the DHCP service of a deployed Edge router, particularly when it thinks it did so (if you look within vRA at your Items it thinks it passed on all the DNS settings to the DHCP service running on the Edge router, image attached).  Anyway, as I might have mentioned before, the work around is to hardcode the DNS information within the VM you'll be using in the blueprint.  Of course that could mean having to create multiple VMs, each with different DNS settings, so a little counter to the VMware efficiency mantra and not very elegant.

View solution in original post

0 Kudos