1
00:00:01,440 --> 00:00:03,490
And then here is our command output here.

2
00:00:03,490 --> 00:00:04,970
Now what I want you to see,

3
00:00:04,970 --> 00:00:08,970
and this is really important in terms of troubleshooting Azure networking,

4
00:00:08,970 --> 00:00:14,440
is for this machine, the connection‑specific DNS suffix is this great big blah,

5
00:00:14,440 --> 00:00:17,380
blah, blah, blah, blah .bx.internal.cloudapp.net.

6
00:00:17,380 --> 00:00:23,810
Now the reason why Azure‑provided name resolution works is that all VMs

7
00:00:23,810 --> 00:00:27,620
within a single virtual network have the same suffix.

8
00:00:27,620 --> 00:00:32,470
So therefore, if you're on dc1 in a VNet and there's a dc2,

9
00:00:32,470 --> 00:00:37,140
you can do a ping dc2 and resolve it by its host name.

10
00:00:37,140 --> 00:00:42,140
But if you wanted to use dc2's FQDN, or fully qualified domain name,

11
00:00:42,140 --> 00:00:44,880
you would have to specify ping dc2.

12
00:00:44,880 --> 00:00:48,440
blah, blah, blah bx.internal.cloudapp.net.

13
00:00:48,440 --> 00:00:50,010
That is not very scalable.

14
00:00:50,010 --> 00:00:51,940
It's not easy to use.

15
00:00:51,940 --> 00:00:55,080
It's just met the Azure‑provided name resolution.

16
00:00:55,080 --> 00:00:59,080
It's a convenience for basically single label name resolution.

17
00:00:59,080 --> 00:01:04,480
That does not work across peerings and into other VNets because this blah,

18
00:01:04,480 --> 00:01:09,340
blah, blah is dynamically generated for each VNet,

19
00:01:09,340 --> 00:01:11,140
you see, and they're not shared.

20
00:01:11,140 --> 00:01:12,930
So that's what's going on under the hood.

21
00:01:12,930 --> 00:01:16,240
I also want you to see if I come down here and show you,

22
00:01:16,240 --> 00:01:19,530
notice my DHCP server address is the wire server,

23
00:01:19,530 --> 00:01:23,440
168.63.129.16.

24
00:01:23,440 --> 00:01:30,740
Notice also that right now my DNS server is the wire server, 168.63.129.16.

25
00:01:30,740 --> 00:01:32,750
How would you override these?

26
00:01:32,750 --> 00:01:35,820
Well, you can make overrides at the network interface level.

27
00:01:35,820 --> 00:01:40,090
But normally, you'll want to make an override for the virtual network itself.

28
00:01:40,090 --> 00:01:42,580
So let's go into my az801‑rg‑vnet.

29
00:01:42,580 --> 00:01:46,270
And if we come down under DNS servers,

30
00:01:46,270 --> 00:01:48,340
you'll see that we can flip the switch from

31
00:01:48,340 --> 00:01:52,140
Azure‑provided name resolution to Custom.

32
00:01:52,140 --> 00:01:54,520
Why would you want to use custom DNS?

33
00:01:54,520 --> 00:01:56,090
Well, in a hybrid cloud,

34
00:01:56,090 --> 00:02:00,440
you may want to join this Azure VM to your local Active Directory domain,

35
00:02:00,440 --> 00:02:05,350
in which we're going to want to inject your on‑premises domain controller DNS

36
00:02:05,350 --> 00:02:10,380
server addresses into the configurations of your cloud VMs.

37
00:02:10,380 --> 00:02:19,540
And we don't want to sign into those cloud VMs and then jump into ncpa.cpl.

38
00:02:19,540 --> 00:02:22,580
You know how you do on‑premises and your horse around with the properties?

39
00:02:22,580 --> 00:02:25,230
Don't do this in Azure, no.

40
00:02:25,230 --> 00:02:27,180
No, you're going to lock yourself out of your VM.

41
00:02:27,180 --> 00:02:30,460
Instead, you're going to want to make this change in the Azure Resource

42
00:02:30,460 --> 00:02:36,170
Manager control plane. By making your custom IP assignment here, the VNet

43
00:02:36,170 --> 00:02:40,780
then, the wire server, will then inject those addresses into the network

44
00:02:40,780 --> 00:02:43,750
interface cards of all of those virtual machines.

45
00:02:43,750 --> 00:02:45,230
That make sense? All right,

46
00:02:45,230 --> 00:02:48,220
so let's head on over to Network Watcher and finish up.

47
00:02:48,220 --> 00:02:53,200
If we go to Network Watcher, we want to make sure that we've got the service

48
00:02:53,200 --> 00:02:58,470
enabled in our region. We can manually add the extension to additional regions.

49
00:02:58,470 --> 00:03:02,870
I use East US. What are some of the things we can do here? We don't have the

50
00:03:02,870 --> 00:03:07,410
time or the necessity to go through all of them. Topology is cool because you

51
00:03:07,410 --> 00:03:09,590
can look up. Within a subscription,

52
00:03:09,590 --> 00:03:13,670
you've got your resource group and then your VNets, and then you can get a

53
00:03:13,670 --> 00:03:17,100
really nice vector representation of your virtual network.

54
00:03:17,100 --> 00:03:21,200
So here we can see I've got a workload subnet called default where

55
00:03:21,200 --> 00:03:25,010
I've got my monitorvm. There's its network interface,

56
00:03:25,010 --> 00:03:27,280
there's the network security group, and there's the

57
00:03:27,280 --> 00:03:31,120
public IP address. And moreover, these are clickable links.

58
00:03:31,120 --> 00:03:34,050
Say, so you can jump right to the resource simply by

59
00:03:34,050 --> 00:03:36,440
clicking it in the Topology view.

60
00:03:36,440 --> 00:03:39,960
Under Network diagnostic tools, we can do things like look at

61
00:03:39,960 --> 00:03:43,240
the effective security rules for an Azure VM.

62
00:03:43,240 --> 00:03:47,300
Once again, I'll take a look at monitorvm, and it will enumerate

63
00:03:47,300 --> 00:03:51,310
based on the selected network interface any associated network

64
00:03:51,310 --> 00:03:54,340
security groups, and you can review those rules.

65
00:03:54,340 --> 00:03:58,550
I find that a lot of network security group troubleshooting comes in with

66
00:03:58,550 --> 00:04:01,750
network security groups, so definitely we've got that.

67
00:04:01,750 --> 00:04:06,540
So we could click in to go to that network security group and go from there.

68
00:04:06,540 --> 00:04:10,840
Another thing we could do is NSG diagnostic, same idea.

69
00:04:10,840 --> 00:04:16,750
We can bring up a virtual machine, and we can dial up a traffic stream,

70
00:04:16,750 --> 00:04:22,830
let's say TCP, Outbound. And we could go out on the public address, which is

71
00:04:22,830 --> 00:04:26,820
the public IP that's on that VM, or we could use a private.

72
00:04:26,820 --> 00:04:28,040
It doesn't matter.

73
00:04:28,040 --> 00:04:34,170
And for Destination, again, it can be any public or private IPv4 or IPv6

74
00:04:34,170 --> 00:04:39,870
address. Maybe we can use one of the Google DNS servers. I'll make it TCP

75
00:04:39,870 --> 00:04:43,280
53. And this is going to answer the question,

76
00:04:43,280 --> 00:04:47,650
do we have a network security group rule, either outbound or inbound

77
00:04:47,650 --> 00:04:52,300
that's hanging up this traffic flow, you see? It can be a great deal of

78
00:04:52,300 --> 00:04:56,540
help for sure, so let me scroll out so you can see what's going on. It

79
00:04:56,540 --> 00:05:01,160
looks like, in this case, that traffic stream would be allowed because

80
00:05:01,160 --> 00:05:03,890
this NSG evidently has a rule.

81
00:05:03,890 --> 00:05:04,810
I know it does.

82
00:05:04,810 --> 00:05:09,720
One of the built‑in rules actually allows all internet‑bound traffic by default,

83
00:05:09,720 --> 00:05:13,240
but again, it's a validation. Same with Next hop.

84
00:05:13,240 --> 00:05:18,330
Next hop is particularly useful when you're dealing with user‑defined routes.

85
00:05:18,330 --> 00:05:22,900
So let me again go out to 8888 and click Next hop. What is the very

86
00:05:22,900 --> 00:05:27,150
next router interface that this VM is going to hit on its journey to

87
00:05:27,150 --> 00:05:30,310
that destination? And it's going to be, well,

88
00:05:30,310 --> 00:05:33,060
it could be a number of different things, actually. This

89
00:05:33,060 --> 00:05:35,310
one goes directly out onto the internet.

90
00:05:35,310 --> 00:05:40,380
We're using Azure system routes. But it very well could be if we were dialing up

91
00:05:40,380 --> 00:05:45,240
one of my on‑premises private iP addresses and we were using a virtual private

92
00:05:45,240 --> 00:05:49,710
network gateway and a site‑to‑site VPN, in that case, we might have a

93
00:05:49,710 --> 00:05:55,340
user‑defined route table that has the next hop of virtual network gateway. See

94
00:05:55,340 --> 00:06:00,180
what I mean? So if nothing else, it's a great validation that your network

95
00:06:00,180 --> 00:06:02,710
topology is functioning as expected.

96
00:06:02,710 --> 00:06:07,340
And also, if the topology is not functioning as expected,

97
00:06:07,340 --> 00:06:10,400
you can identify the problem and fix it faster.

98
00:06:10,400 --> 00:06:11,750
That's what we're talking about here.

99
00:06:11,750 --> 00:06:11,970
You know,

100
00:06:11,970 --> 00:06:15,980
you can even do a packet capture. This is so cool where if you

101
00:06:15,980 --> 00:06:20,580
really want to get right down to the Ethernet frames on a VM, you

102
00:06:20,580 --> 00:06:22,910
can absolutely schedule that to happen.

103
00:06:22,910 --> 00:06:26,770
So in this case, we can dial up our monitor VM again. You

104
00:06:26,770 --> 00:06:29,780
choose where you want to store the resulting capture file.

105
00:06:29,780 --> 00:06:32,040
You can put it in a storage account,

106
00:06:32,040 --> 00:06:36,040
put it in the file system of the target VM or both.

107
00:06:36,040 --> 00:06:38,920
There's some basic capture filtering here.

108
00:06:38,920 --> 00:06:43,520
It's nothing like you see in Wireshark. You set a duration and so on,

109
00:06:43,520 --> 00:06:48,720
and then it will run and capture Ethernet frames. And then the idea is

110
00:06:48,720 --> 00:06:53,460
you grab that cap file, load it into Wireshark, and you can see at a

111
00:06:53,460 --> 00:06:55,800
frame by frame level what's happening.

112
00:06:55,800 --> 00:07:00,130
That's such a great convenience given that Azure is software‑defined

113
00:07:00,130 --> 00:07:03,460
networking, and we don't have the level of physical access to the

114
00:07:03,460 --> 00:07:06,760
infrastructure that I assume you do on‑premises.

115
00:07:06,760 --> 00:07:10,440
Maybe you don't on‑premises, but I hope you do.

116
00:07:10,440 --> 00:07:11,050
Okay,

117
00:07:11,050 --> 00:07:14,360
very last thing, and then I promise we're done. For

118
00:07:14,360 --> 00:07:18,860
your network security groups, you can enable what are called flow logs.

119
00:07:18,860 --> 00:07:23,560
This is a more robust way to capture diagnostics for your

120
00:07:23,560 --> 00:07:27,230
network security groups. And doing that is required to plug

121
00:07:27,230 --> 00:07:30,240
into something called Traffic Analytics.

122
00:07:30,240 --> 00:07:35,820
This allows you to really visualize with geomaps, and charts, and graphs

123
00:07:35,820 --> 00:07:41,300
your NSG environment around the world. And these NSG tools, you might think

124
00:07:41,300 --> 00:07:44,320
that this is overkill now. Once you get rolling,

125
00:07:44,320 --> 00:07:46,950
you'll find that dollars to donuts,

126
00:07:46,950 --> 00:07:50,700
one of your biggest challenges is wrangling NSG rules.

127
00:07:50,700 --> 00:07:53,870
You really need those network security groups because that's

128
00:07:53,870 --> 00:07:58,120
your main way to protect your Azure virtual machines, their

129
00:07:58,120 --> 00:08:00,810
ingress and egress network traffic.

130
00:08:00,810 --> 00:08:07,000
So the ability to visualize while you're monitoring that network traffic can be awfully useful, indeed.