Question

itraor on Wed, 19 Jul 2017 09:34:47


I launched a Windows VM inside a VNET, expected it to inherit DNS settings from the VNET. That not what happened. Instead the VM is using a DHCP server that is also its DNS server, running on non-routable IP 168.63.129.16. I've been double-checking the documentation, scouring the forum, I can't find any relevant/useful tip, nothing indicating to me that I've configured something wrong.

Here is, below my (slighly redacted) VM network properties.

Name: Ethernet 3
Description: Microsoft Hyper-V Network Adapter #3
Physical address (MAC): 00:0d:3a:29:f1:98
Status: Operational
Maximum transmission unit: 1500
Link speed (Receive/Transmit): 40/40 (Gbps)
DHCP enabled: Yes
DHCP servers: 168.63.129.16
DHCP lease obtained: ‎Wednesday, ‎July ‎19, ‎2017 7:48:42 AM
DHCP lease expires: ‎Wednesday, ‎July ‎19, ‎2017 7:48:41 AM
IPv4 address: 10.0.0.4/24
IPv6 address: fe80::258b:141e:8929:8a93%4/64
Default gateway: 10.0.0.1
DNS servers: 168.63.129.16
DNS domain name: some-cryptic-name-here.ax.internal.cloudapp.net
DNS connection suffix: some-cryptic-name-here.ax.internal.cloudapp.net
DNS search suffix list:
Network name: Network
Network category: Private
Connectivity (IPv4/IPv6): Connected to Internet / Connected to unknown network

Name: clearly-generated-host-name.some-cryptic-name-here.ax.internal.cloudapp.net
Description: Microsoft ISATAP Adapter
Physical address (MAC): 00:00:00:00:00:00:00:e0
Status: Not operational
Maximum transmission unit: 1280
IPv6 address: fe80::5efe:10.0.0.4%11/128
DNS servers: 168.63.129.16
DNS connection suffix: some-cryptic-name-here.ax.internal.cloudapp.net
Connectivity (IPv4/IPv6): Disconnected


Name: Teredo Tunneling Pseudo-Interface
Description: Teredo Tunneling Pseudo-Interface
Physical address (MAC): 00:00:00:00:00:00:00:e0
Status: Operational
Maximum transmission unit: 1280
IPv6 address: 2001:0:9d38:90d7:4a:13f7:97d7:6586/64, fe80::4a:13f7:97d7:6586%2/64
Default gateway: ::
Connectivity (IPv4/IPv6): Disconnected

Any pointer on this?

                                                                                                                                           

Sponsored



Replies

Gareth Bradshaw (MSFT) on Wed, 19 Jul 2017 11:37:33


How is the virtual network setup? Have you specified DNS servers for the vitual network and confirmed that the virtual network settings have saved correctly? Also the DHCP leases are long in Azure to the VM needs to restart (or refresh DHCP lease) to get the new settings.

itraor on Wed, 19 Jul 2017 12:11:21


I investigated the issue, checking all the resources in the subscription and found a problem, possibly the issue.

As I prepared to launch the VM, I specified that it be part of the existing VNET. It seems that Azure, somehow went and read the existing VNET settings, but then created a totally new VNET, deriving a default subnet info from the existing VENT. After launch succeeded, everything looks good, no errors, I see a new VM coming up with an IP address in the range that I expected. I can RDP into it, all look good. But I find that the connectivity isn't as expected, start digging from there.

However, I now have somehow two distinct VNETs with the same default subnet IP range, instead of one. I have no idea how this could be, what exactly happened. But this seems to be what I see right now.

itraor on Wed, 19 Jul 2017 12:13:23


Crossed wires. I just posted a finding. But indeed, during the launch I made sure to specify the existing VNET, I wasn't prompted for DNS at any stage. I am trying to figure out what else I could have missed.

itraor on Wed, 19 Jul 2017 13:00:38


Second reply CC @Gareth Bradshaw:

Another thing I noticed. Some time back I had launched a windows VM the same way, and that one ended up with all the correct settings. Networking worked as expected, everything resolved correctly. The one difference between the two VMs is in the templates:

  • The earlier VM I launched was a Windows Server 2016 Data Centre version 1607 (build 14393.1358), this last one is a Windows VM with Visual Studio pre-installed. Everything went ok.
  • This VM I recently launched is also Windows Server 2016 Data Centre version 1607 (different build 14393.1480) + Visual Studio Community pre-installed

I don't suppose this difference matters, but you never know.

Gareth Bradshaw (MSFT) on Thu, 20 Jul 2017 15:35:47


The Windows/Linux version on the VM shouldn't matter provided the DHCP client is doing what it should - which is the case for all our images.

Because Azure is a multi-tenant virtualised environment, each subscription can have many virtual networks (vnets) with the same IP range - that's ok they are separate vnets.  Can you confirm that the vm is in the vnet you need it in and that the DNS server IPs are configured on that vnet - there is no sharing of settings between vnets.

itraor on Wed, 26 Jul 2017 11:47:07


Hi  @Gareth Bradshaw,

I can confirm they were separate Vnets, but the surprising thing is that I did not explicitly asked to create a new one. Instead, as I launched the VM, I made sure to specify the existing VNET.

In parallel to this activity, we have been working with the CSP to transfer ownership of the assets to the company. We will consolidate the assets, and re-run the scripts again.

Nirushi J on Fri, 28 Jul 2017 09:29:04


Sure, re-run the script and let us know.

-------------------------------------------------------------------------------------------------------

Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members

itraor on Sat, 29 Jul 2017 08:38:46


Since I am uncertain as to what really happened, maybe some sort of a bug, my idea is to get the new environment ready then try to reproduce the issue in a more controlled scripted manner. At that point I can mark the correct answer. The reason for having this doubt is that I had prior success launching a VM inside an existing VNET and everything went fine.