And then here is our command output here.
Now what I want you to see,
and this is really important in terms of troubleshooting Azure networking,
is for this machine, the connection‑specific DNS suffix is this great big blah,
blah, blah, blah, blah .bx.internal.cloudapp.net.
Now the reason why Azure‑provided name resolution works is that all VMs
within a single virtual network have the same suffix.
So therefore, if you're on dc1 in a VNet and there's a dc2,
you can do a ping dc2 and resolve it by its host name.
But if you wanted to use dc2's FQDN, or fully qualified domain name,
you would have to specify ping dc2.
blah, blah, blah bx.internal.cloudapp.net.
That is not very scalable.
It's not easy to use.
It's just met the Azure‑provided name resolution.
It's a convenience for basically single label name resolution.
That does not work across peerings and into other VNets because this blah,
blah, blah is dynamically generated for each VNet,
you see, and they're not shared.
So that's what's going on under the hood.
I also want you to see if I come down here and show you,
notice my DHCP server address is the wire server,
168.63.129.16.
Notice also that right now my DNS server is the wire server, 168.63.129.16.
How would you override these?
Well, you can make overrides at the network interface level.
But normally, you'll want to make an override for the virtual network itself.
So let's go into my az801‑rg‑vnet.
And if we come down under DNS servers,
you'll see that we can flip the switch from
Azure‑provided name resolution to Custom.
Why would you want to use custom DNS?
Well, in a hybrid cloud,
you may want to join this Azure VM to your local Active Directory domain,
in which we're going to want to inject your on‑premises domain controller DNS
server addresses into the configurations of your cloud VMs.
And we don't want to sign into those cloud VMs and then jump into ncpa.cpl.
You know how you do on‑premises and your horse around with the properties?
Don't do this in Azure, no.
No, you're going to lock yourself out of your VM.
Instead, you're going to want to make this change in the Azure Resource
Manager control plane. By making your custom IP assignment here, the VNet
then, the wire server, will then inject those addresses into the network
interface cards of all of those virtual machines.
That make sense? All right,
so let's head on over to Network Watcher and finish up.
If we go to Network Watcher, we want to make sure that we've got the service
enabled in our region. We can manually add the extension to additional regions.
I use East US. What are some of the things we can do here? We don't have the
time or the necessity to go through all of them. Topology is cool because you
can look up. Within a subscription,
you've got your resource group and then your VNets, and then you can get a
really nice vector representation of your virtual network.
So here we can see I've got a workload subnet called default where
I've got my monitorvm. There's its network interface,
there's the network security group, and there's the
public IP address. And moreover, these are clickable links.
Say, so you can jump right to the resource simply by
clicking it in the Topology view.
Under Network diagnostic tools, we can do things like look at
the effective security rules for an Azure VM.
Once again, I'll take a look at monitorvm, and it will enumerate
based on the selected network interface any associated network
security groups, and you can review those rules.
I find that a lot of network security group troubleshooting comes in with
network security groups, so definitely we've got that.
So we could click in to go to that network security group and go from there.
Another thing we could do is NSG diagnostic, same idea.
We can bring up a virtual machine, and we can dial up a traffic stream,
let's say TCP, Outbound. And we could go out on the public address, which is
the public IP that's on that VM, or we could use a private.
It doesn't matter.
And for Destination, again, it can be any public or private IPv4 or IPv6
address. Maybe we can use one of the Google DNS servers. I'll make it TCP
53. And this is going to answer the question,
do we have a network security group rule, either outbound or inbound
that's hanging up this traffic flow, you see? It can be a great deal of
help for sure, so let me scroll out so you can see what's going on. It
looks like, in this case, that traffic stream would be allowed because
this NSG evidently has a rule.
I know it does.
One of the built‑in rules actually allows all internet‑bound traffic by default,
but again, it's a validation. Same with Next hop.
Next hop is particularly useful when you're dealing with user‑defined routes.
So let me again go out to 8888 and click Next hop. What is the very
next router interface that this VM is going to hit on its journey to
that destination? And it's going to be, well,
it could be a number of different things, actually. This
one goes directly out onto the internet.
We're using Azure system routes. But it very well could be if we were dialing up
one of my on‑premises private iP addresses and we were using a virtual private
network gateway and a site‑to‑site VPN, in that case, we might have a
user‑defined route table that has the next hop of virtual network gateway. See
what I mean? So if nothing else, it's a great validation that your network
topology is functioning as expected.
And also, if the topology is not functioning as expected,
you can identify the problem and fix it faster.
That's what we're talking about here.
You know,
you can even do a packet capture. This is so cool where if you
really want to get right down to the Ethernet frames on a VM, you
can absolutely schedule that to happen.
So in this case, we can dial up our monitor VM again. You
choose where you want to store the resulting capture file.
You can put it in a storage account,
put it in the file system of the target VM or both.
There's some basic capture filtering here.
It's nothing like you see in Wireshark. You set a duration and so on,
and then it will run and capture Ethernet frames. And then the idea is
you grab that cap file, load it into Wireshark, and you can see at a
frame by frame level what's happening.
That's such a great convenience given that Azure is software‑defined
networking, and we don't have the level of physical access to the
infrastructure that I assume you do on‑premises.
Maybe you don't on‑premises, but I hope you do.
Okay,
very last thing, and then I promise we're done. For
your network security groups, you can enable what are called flow logs.
This is a more robust way to capture diagnostics for your
network security groups. And doing that is required to plug
into something called Traffic Analytics.
This allows you to really visualize with geomaps, and charts, and graphs
your NSG environment around the world. And these NSG tools, you might think
that this is overkill now. Once you get rolling,
you'll find that dollars to donuts,
one of your biggest challenges is wrangling NSG rules.
You really need those network security groups because that's
your main way to protect your Azure virtual machines, their
ingress and egress network traffic.
So the ability to visualize while you're monitoring that network traffic can be awfully useful, indeed.