WEBVTT

0:00:02.580000 --> 0:00:08.600000
 Hi, in this video, I'm going to take
 a look at Azure Network Connectivity.

0:00:08.600000 --> 0:00:12.140000
 We're going to cover two
 fundamental concepts.

0:00:12.140000 --> 0:00:16.780000
 We're going to look at the different options
 for Azure Network Connectivity,

0:00:16.780000 --> 0:00:21.620000
 and then we're going to go through some
 of the standard topologies that

0:00:21.620000 --> 0:00:26.760000
 you will typically set up using
 these connectivity options.

0:00:26.760000 --> 0:00:32.740000
 So let's go ahead and let's jump right
 in, and let's talk about the options

0:00:32.740000 --> 0:00:37.820000
 that we have for connectivity in
 an Azure Networking environment.

0:00:37.820000 --> 0:00:43.200000
 We're going to start out by going through
 and just putting in some basic

0:00:43.200000 --> 0:00:46.600000
 components here.

0:00:46.600000 --> 0:00:58.760000
 All right. What we have is we have
 an on-premises, network, and I have

0:00:58.760000 --> 0:01:03.340000
 a couple of virtual networks, which
 I'm going to very cleverly name VNet

0:01:03.340000 --> 0:01:14.880000
 A, and you are probably going to guess
 this, VNet B, VNet, there we go,

0:01:14.880000 --> 0:01:21.080000
 D, and sitting out here by themselves,
 we've got a little workstation.

0:01:21.080000 --> 0:01:22.340000
 We'll just say WS.

0:01:22.340000 --> 0:01:25.580000
 All right. We're going to talk about
 the different connectivity options

0:01:25.580000 --> 0:01:27.200000
 between all of these.

0:01:27.200000 --> 0:01:29.980000
 I'm going to start out with what is
 probably the most typical, which is

0:01:29.980000 --> 0:01:34.340000
 connectivity between on-premises
 and a virtual network.

0:01:34.340000 --> 0:01:37.120000
 You have a couple of
 options for this.

0:01:37.120000 --> 0:01:41.200000
 One is a VPN gateway.

0:01:41.200000 --> 0:01:51.880000
 With a VPN gateway, I have a VPN gateway
 set up on my network, and I have

0:01:51.880000 --> 0:01:56.220000
 some kind of appliance on
 the on-premises side.

0:01:56.220000 --> 0:02:02.720000
 There are quite a number of different networking
 appliances that are certified

0:02:02.720000 --> 0:02:05.520000
 to work with an Azure VPN gateway.


0:02:05.520000 --> 0:02:09.340000
 There's a very good chance if you've
 got a networking appliance, a VPN

0:02:09.340000 --> 0:02:13.520000
 appliance on your on-premises, it is
 probably capable of working with

0:02:13.520000 --> 0:02:20.760000
 a VPN gateway. What you do is you set
 up connectivity so that I set a

0:02:20.760000 --> 0:02:24.760000
 tunnel, an encrypted tunnel,
 across the public internet.

0:02:24.760000 --> 0:02:29.960000
 It is going over the public internet,
 but it is using a shared key, IPsec

0:02:29.960000 --> 0:02:37.860000
 encryption key. Internet.

0:02:37.860000 --> 0:02:45.140000
 There we go. That is
 VPN, public internet.

0:02:45.140000 --> 0:02:53.680000
 An alternate option is to use
 something called ExpressRoute.

0:02:53.680000 --> 0:03:04.300000
 ExpressRoute is a private network where
 you set up a circuit over a private

0:03:04.300000 --> 0:03:10.140000
 provider between your on-premises environment
 and an ExpressRoute gateway

0:03:10.140000 --> 0:03:16.380000
 where actually you set up a circuit between
 the on-premises and your subscription,

0:03:16.380000 --> 0:03:20.220000
 and then in the virtual networks that
 you want to use it, you set up an

0:03:20.220000 --> 0:03:23.160000
 ExpressRoute gateway.

0:03:23.160000 --> 0:03:32.140000
 The advantages of ExpressRoute
 are really twofold.

0:03:32.140000 --> 0:03:36.600000
 The first is that you are going over
 a private network never going out

0:03:36.600000 --> 0:03:41.100000
 over the public internet, so you've got
 a higher level of security there.

0:03:41.100000 --> 0:03:46.040000
 You also have higher
 performance options.

0:03:46.040000 --> 0:03:50.200000
 When you set up an ExpressRoute gateway
 or when you set up a VPN gateway,

0:03:50.200000 --> 0:03:52.560000
 you're going to set up a tier.

0:03:52.560000 --> 0:03:53.900000
 You're going to select a tier.

0:03:53.900000 --> 0:03:56.160000
 That's going to give you a certain
 level of performance.

0:03:56.160000 --> 0:04:00.180000
 The performance options for ExpressRoute
 gateways are significantly higher

0:04:00.180000 --> 0:04:03.440000
 than the performance options
 for a VPN gateway.

0:04:03.440000 --> 0:04:09.680000
 But those are really as far as what's
 in Azure, those are your options

0:04:09.680000 --> 0:04:13.560000
 for connecting to on-premises, either
 through a VPN gateway that has an

0:04:13.560000 --> 0:04:16.980000
 appliance on the other side
 or via ExpressRoute.

0:04:16.980000 --> 0:04:21.900000
 Now, what I want to do is talk about connectivity
 between virtual networks.

0:04:21.900000 --> 0:04:26.720000
 There's really two basic options for connectivity
 between virtual networks.

0:04:26.720000 --> 0:04:30.500000
 Remember, by default, you have
 separate virtual networks.

0:04:30.500000 --> 0:04:32.860000
 There is no communication
 between them.

0:04:32.860000 --> 0:04:36.780000
 You have to open up a pathway
 for communication.

0:04:36.780000 --> 0:04:42.060000
 One way to do that is what we call
 VNet to VNet connectivity.

0:04:42.060000 --> 0:04:44.240000
 Oh, sorry, one more thing.

0:04:44.240000 --> 0:04:46.800000
 You'll see the term site to site.

0:04:46.800000 --> 0:04:53.300000
 Usually it's TO, but I just think it
 looks cool to have the two in there.

0:04:53.300000 --> 0:04:59.060000
 A site to site connection is a VPN connection
 with your on-premises network.

0:04:59.060000 --> 0:05:06.680000
 If I'm going to use VPN gateways for
 connectivity within Azure, then what

0:05:06.680000 --> 0:05:12.380000
 I have is considered
 a VNet to VNet.

0:05:12.380000 --> 0:05:23.600000
 With a VNet to VNet, really your connectivity
 is effectively the same

0:05:23.600000 --> 0:05:26.640000
 concept as you have
 with on-premises.

0:05:26.640000 --> 0:05:28.340000
 You're setting up
 your VPN gateways.

0:05:28.340000 --> 0:05:32.440000
 You're setting performance capacity
 tiers, selecting those on both ends.

0:05:32.440000 --> 0:05:36.060000
 You're paying for that performance
 capacity, and you are communicating

0:05:36.060000 --> 0:05:42.040000
 over an encrypted tunnel based
 on IPsec shared key.

0:05:42.040000 --> 0:05:52.580000
 That's fine. An alternative to
 that is what we call peering.

0:05:52.580000 --> 0:05:55.920000
 With a peering relationship,
 you're not using a gateway.

0:05:55.920000 --> 0:05:58.580000
 You're just connecting the
 two virtual networks.

0:05:58.580000 --> 0:06:03.160000
 And if, for example, the two virtual
 networks are in the same region,

0:06:03.160000 --> 0:06:07.660000
 your connectivity between them is going
 to be the same as though the virtual

0:06:07.660000 --> 0:06:10.860000
 machines on both sides are in
 the same virtual network.

0:06:10.860000 --> 0:06:14.980000
 In other words, the peering relationship
 itself is not going to add any

0:06:14.980000 --> 0:06:18.060000
 performance overhead
 to your topology.

0:06:18.060000 --> 0:06:22.960000
 However, it will, and you need to
 be aware of this, add a cost.

0:06:22.960000 --> 0:06:25.700000
 You are paying for consumption.

0:06:25.700000 --> 0:06:29.420000
 In other words, you're paying for the
 amount of traffic that is traversing

0:06:29.420000 --> 0:06:31.460000
 that peering relationship.

0:06:31.460000 --> 0:06:36.300000
 And, fun fact, you get charged for
 both ingress and egress, which is a

0:06:36.300000 --> 0:06:41.040000
 little bit odd because typically when
 you think about, you know, working

0:06:41.040000 --> 0:06:45.780000
 with anything Azure, you're typically
 only charged for egress.

0:06:45.780000 --> 0:06:48.920000
 But be aware, it's
 not a huge charge.

0:06:48.920000 --> 0:06:51.820000
 But do be aware that you are being
 charged in both directions.

0:06:51.820000 --> 0:06:54.060000
 Okay, double whatever
 the cost is there.

0:06:54.060000 --> 0:06:56.760000
 Peering works locally.

0:06:56.760000 --> 0:06:59.000000
 Peering also works globally.

0:06:59.000000 --> 0:07:05.580000
 I can peer between any region in the,
 well, in the globe, all right, on

0:07:05.580000 --> 0:07:07.360000
 the globe. It's international.

0:07:07.360000 --> 0:07:11.160000
 One thing to be aware of, there are
 higher charges, ingress and egress

0:07:11.160000 --> 0:07:15.660000
 charges, when you go outside
 of the same region.

0:07:15.660000 --> 0:07:19.860000
 And there's different zone categories
 and you can see what the cost is

0:07:19.860000 --> 0:07:21.300000
 there. So just be aware of that.

0:07:21.300000 --> 0:07:24.240000
 Generally speaking though, even though
 there's that cost, there's of course

0:07:24.240000 --> 0:07:27.480000
 a cost with VNet to VNet and you're
 paying for capacity there, which you

0:07:27.480000 --> 0:07:29.200000
 might not always use.

0:07:29.200000 --> 0:07:34.320000
 Generally speaking, the choice is usually
 to go with peering if it's something

0:07:34.320000 --> 0:07:38.360000
 greenfield. You may have a reason to
 go VNet to VNet, but if it's brand

0:07:38.360000 --> 0:07:41.580000
 new or greenfield, you're probably
 going to want to select peering.

0:07:41.580000 --> 0:07:47.560000
 You might even want to migrate to peering
 from a VNet to VNet if you see

0:07:47.560000 --> 0:07:51.120000
 cause for that. The last type of connectivity
 that we're going to talk

0:07:51.120000 --> 0:07:56.960000
 about is individual connectivity or
 what we will call P2S, peer-to-site

0:07:56.960000 --> 0:08:00.840000
 virtual connectivity,
 VPN connectivity.

0:08:00.840000 --> 0:08:06.820000
 With this, I've got a workstation.


0:08:06.820000 --> 0:08:10.860000
 I configure my VPN gateway
 to support the workstation.

0:08:10.860000 --> 0:08:20.560000
 And again, what this gives us is what
 we call point-to-site or P2S.

0:08:20.560000 --> 0:08:24.820000
 Okay. Now, the configuration of this
 is done primarily through the VPN

0:08:24.820000 --> 0:08:29.980000
 gateway. You set this up in the VPN
 gateway and you then configure your

0:08:29.980000 --> 0:08:31.120000
 workstation to communicate.

0:08:31.120000 --> 0:08:36.800000
 There are several different ways that
 your workstation can authenticate,

0:08:36.800000 --> 0:08:40.820000
 and that's really where the tricky
 part of this comes in.

0:08:40.820000 --> 0:08:48.080000
 You've got essentially two main
 approaches to authentication.

0:08:48.080000 --> 0:08:52.340000
 You have certificate
-based certificate.

0:08:52.340000 --> 0:08:54.320000
 Almost forgot how to spell that.

0:08:54.320000 --> 0:09:00.140000
 Certificate-based authentication and you
 also have radius-based authentication.

0:09:00.140000 --> 0:09:05.280000
 For your workstation point
-to-site communication.

0:09:05.280000 --> 0:09:11.880000
 And this is supported across Windows
 machines, across Mac OS machines.

0:09:11.880000 --> 0:09:12.620000
 Almost forgot that.

0:09:12.620000 --> 0:09:13.840000
 I'm such a Windows person.

0:09:13.840000 --> 0:09:18.520000
 As well as many Linux distros
 should work for that.

0:09:18.520000 --> 0:09:22.800000
 So you have all of these different
 network connectivity options.

0:09:22.800000 --> 0:09:29.500000
 Now, let's take a look at some of the
 common topologies that we have within

0:09:29.500000 --> 0:09:31.020000
 Azure networking.

0:09:31.020000 --> 0:09:35.080000
 The most basic topology that you have
 is what I would consider just a

0:09:35.080000 --> 0:09:40.760000
 basic hybrid. And that is where I've got
 connectivity between my on-premises

0:09:40.760000 --> 0:09:45.080000
 environment and my
 virtual network.

0:09:45.080000 --> 0:09:48.640000
 That is what we call hybrid
 networking connection.

0:09:48.640000 --> 0:09:53.000000
 Doesn't matter if it's going
 through VPN or express route.

0:09:53.000000 --> 0:10:00.620000
 The next we have communication
 between two virtual networks.

0:10:00.620000 --> 0:10:04.440000
 Which is just VNet
 to VNet or peering.

0:10:04.440000 --> 0:10:11.840000
 Then you have the more complex and
 absolutely more interesting what we

0:10:11.840000 --> 0:10:13.080000
 call hub and spoke.

0:10:13.080000 --> 0:10:20.500000
 With a hub and spoke architecture,
 what you typically have is either a

0:10:20.500000 --> 0:10:22.200000
 VPN or express route.

0:10:22.200000 --> 0:10:27.720000
 I'm just going to put in VPN connectivity
 between on-premises and the

0:10:27.720000 --> 0:10:32.740000
 virtual network that
 acts as your hub.

0:10:32.740000 --> 0:10:36.920000
 So I've got a virtual network
 acting as a hub.

0:10:36.920000 --> 0:10:39.660000
 And then I have all of these
 virtual networks around it.

0:10:39.660000 --> 0:10:42.420000
 They're not actually physically around
 it like that, but logically around

0:10:42.420000 --> 0:10:47.600000
 it. And these we consider to be
 our spoke virtual networks.

0:10:47.600000 --> 0:10:51.400000
 Now, what's pretty cool about this,
 I'm not going to do the third one.

0:10:51.400000 --> 0:10:53.180000
 Because you get the idea.

0:10:53.180000 --> 0:10:57.040000
 What's pretty cool about this is I'll
 typically set this up with a peering

0:10:57.040000 --> 0:11:02.740000
 relationship across
 all three of these.

0:11:02.740000 --> 0:11:09.120000
 And that for some reason
 I will put on all three.

0:11:09.120000 --> 0:11:16.220000
 Now the neat thing about this is that
 traffic is supported automatically.

0:11:16.220000 --> 0:11:20.860000
 When I set this up by default, traffic
 is going to be supported between

0:11:20.860000 --> 0:11:26.760000
 each of the peers and the virtual hub,
 which you would pretty much expect.

0:11:26.760000 --> 0:11:31.180000
 So this spoke can connect
 to the virtual hub.

0:11:31.180000 --> 0:11:37.560000
 Also, if I set up gateway forwarding
 for the peering connection, I can

0:11:37.560000 --> 0:11:41.540000
 also have that automatically route
 over to the on-premises.

0:11:41.540000 --> 0:11:48.840000
 What I cannot do with this architecture
 by default is I cannot connect

0:11:48.840000 --> 0:11:51.000000
 directly between two
 virtual networks.

0:11:51.000000 --> 0:11:53.820000
 That is not available.

0:11:53.820000 --> 0:11:56.560000
 That's called transitive routing.

0:11:56.560000 --> 0:12:02.040000
 And it is not a capability that you have
 with the built-in functionality.

0:12:02.040000 --> 0:12:07.280000
 If you absolutely need that, if I need
 some spoke virtual networks to

0:12:07.280000 --> 0:12:09.260000
 communicate, I have
 a couple of options.

0:12:09.260000 --> 0:12:13.760000
 One, I could go ahead and just set up
 another peering relationship between

0:12:13.760000 --> 0:12:21.800000
 them. Or I could also implement,
 oh, there we go.

0:12:21.800000 --> 0:12:22.660000
 Hang on a second.

0:12:22.660000 --> 0:12:24.360000
 Let's get that right.

0:12:24.360000 --> 0:12:28.720000
 There we go. I can also implement
 a router solution.

0:12:28.720000 --> 0:12:33.120000
 The routing is done automatically
 over peer networking.

0:12:33.120000 --> 0:12:36.500000
 It's done automatically
 over VPN networking.

0:12:36.500000 --> 0:12:42.420000
 And I can set up my peering to support,
 as I said, gateway forwarding.

0:12:42.420000 --> 0:12:46.720000
 Now another little caveat to that,
 to that automatic routing, is that

0:12:46.720000 --> 0:12:51.920000
 if you're using express route, express
 route doesn't use gateway forwarding.

0:12:51.920000 --> 0:12:53.860000
 Instead, it uses BGP.

0:12:53.860000 --> 0:12:59.420000
 So you would have to configure BGP,
 which you can do fairly easily, but

0:12:59.420000 --> 0:13:02.980000
 well outside the scope
 of this course.

0:13:02.980000 --> 0:13:06.160000
 Those are your network
 technologies.

0:13:06.160000 --> 0:13:08.800000
 And those are just kind of the
 standard that you think about.

0:13:08.800000 --> 0:13:15.420000
 Again, you have your site to site,
 right, which is on-prem to virtual

0:13:15.420000 --> 0:13:19.620000
 network. You have VNet to VNet or peering,
 which is between two virtual

0:13:19.620000 --> 0:13:23.960000
 networks. And you have a hub and spoke,
 which is really a combination

0:13:23.960000 --> 0:13:26.580000
 of the two. You're not limited
 to that, of course.

0:13:26.580000 --> 0:13:29.680000
 If you understand the basic connection
 options, you can really define

0:13:29.680000 --> 0:13:32.700000
 whatever topology is going
 to meet your need.