WEBVTT

0:00:02.600000 --> 0:00:06.700000
 Now I'd like to talk about
 Azure Network routing.

0:00:06.700000 --> 0:00:12.180000
 In this video, we're going to take a
 look at the Azure System routes that

0:00:12.180000 --> 0:00:17.000000
 are predefined for you, so that you may
 not need to do any custom routing.

0:00:17.000000 --> 0:00:21.700000
 Then we're going to take a look at the
 Azure route tables, what you can

0:00:21.700000 --> 0:00:23.900000
 do with route tables.

0:00:23.900000 --> 0:00:27.180000
 Finally, I'm going to demonstrate
 Azure routing.

0:00:27.180000 --> 0:00:31.260000
 We're going to take a look at implementing
 a custom route table and see

0:00:31.260000 --> 0:00:34.080000
 what exactly that's
 going to do for us.

0:00:34.080000 --> 0:00:40.120000
 Let's go ahead and let's get started
 by looking at the different built

0:00:40.120000 --> 0:00:42.220000
-in Azure System routes.

0:00:42.220000 --> 0:00:46.240000
 The first built-in route is
 the virtual network route.

0:00:46.240000 --> 0:00:51.180000
 What that does is it routes traffic
 between subnets within the virtual

0:00:51.180000 --> 0:00:53.220000
 network that they belong to.

0:00:53.220000 --> 0:00:58.100000
 In other words, unless you do something
 to circumvent this, all of your

0:00:58.100000 --> 0:01:01.920000
 virtual network traffic, even if it's
 segmented into different subnets,

0:01:01.920000 --> 0:01:04.220000
 is going to route properly.

0:01:04.220000 --> 0:01:10.120000
 The next routing that we have
 is the Internet System route.

0:01:10.120000 --> 0:01:16.720000
 Any request that you are sending to
 a public IP address is going to be

0:01:16.720000 --> 0:01:22.100000
 routed out to the Internet Edge
 servers within the Azure System.

0:01:22.100000 --> 0:01:26.620000
 All of your public routing and public
 requests routing by default, is

0:01:26.620000 --> 0:01:28.760000
 going to be properly routed.

0:01:28.760000 --> 0:01:32.940000
 Now keep in mind that doesn't impact
 incoming, unless you have things

0:01:32.940000 --> 0:01:34.780000
 like a public IP address.

0:01:34.780000 --> 0:01:38.560000
 Just because I've got Internet routing,
 that's not opening up any kind

0:01:38.560000 --> 0:01:45.940000
 of whole. Next, I've got peering and
 virtual network gateway routing.

0:01:45.940000 --> 0:01:50.140000
 Any direct peering relationship,
 and this is not transitive.

0:01:50.140000 --> 0:01:54.860000
 I can't go from A to B to C, but I can
 go from A to B and I can go from

0:01:54.860000 --> 0:01:59.420000
 C to B, if I've got the peering
 relationship set up.

0:01:59.420000 --> 0:02:04.780000
 But any peering relationship and also
 a VPN gateway relationship, are

0:02:04.780000 --> 0:02:07.380000
 going to be automatically routed.

0:02:07.380000 --> 0:02:13.460000
 Now I should mention that I said specifically
 a VPN gateway connection.

0:02:13.460000 --> 0:02:18.480000
 You could also have an express route
 connection to an on-prem environment,

0:02:18.480000 --> 0:02:21.960000
 but the automatic routing in the express
 route is going to be handled

0:02:21.960000 --> 0:02:28.380000
 through BGP. So it's not quite as automatic
 and built in a process, although

0:02:28.380000 --> 0:02:30.640000
 it is automated.

0:02:30.640000 --> 0:02:36.140000
 So those are the primary routes and
 there's also service endpoints.

0:02:36.140000 --> 0:02:40.500000
 Service endpoints are new and we now
 have public service endpoints, as

0:02:40.500000 --> 0:02:43.440000
 well as what are called private
 service endpoints.

0:02:43.440000 --> 0:02:49.040000
 There are some slight differences between
 them, but what they do is they

0:02:49.040000 --> 0:02:53.440000
 make sure that any request, if you set
 up a service endpoint between your,

0:02:53.440000 --> 0:02:58.040000
 it's actually at the subnet level, between
 your subnet and an Azure service,

0:02:58.040000 --> 0:03:00.520000
 let's say Azure SQL database.

0:03:00.520000 --> 0:03:04.740000
 The Azure SQL database has a public endpoint,
 it has a public IP address,

0:03:04.740000 --> 0:03:07.660000
 it has a public address,
 a DNS address.

0:03:07.660000 --> 0:03:11.840000
 But if you've got a service endpoint
 set up, that's going to guarantee

0:03:11.840000 --> 0:03:16.800000
 that your requests that are coming
 from within Azure are going to stay

0:03:16.800000 --> 0:03:21.600000
 within Azure. They're never going out
 in any circumstances over the public

0:03:21.600000 --> 0:03:24.940000
 internet. And they're also
 going to be optimized.

0:03:24.940000 --> 0:03:28.820000
 And again, that's true for both what are
 now called public service endpoints,

0:03:28.820000 --> 0:03:30.420000
 as well as private
 service endpoints.

0:03:30.420000 --> 0:03:32.600000
 And there can be a little
 bit confusion on that.

0:03:32.600000 --> 0:03:35.060000
 It was something I honestly had to read
 through a couple of times myself

0:03:35.060000 --> 0:03:38.900000
 to make sure that I could say that statement
 with certainty, because the

0:03:38.900000 --> 0:03:41.000000
 private is fairly new.

0:03:41.000000 --> 0:03:41.960000
 Definitely take a look.

0:03:41.960000 --> 0:03:45.720000
 I think service endpoints are massively
 important when you talk about

0:03:45.720000 --> 0:03:49.360000
 actually designing your networking topology,
 particularly if you're going

0:03:49.360000 --> 0:03:54.640000
 to have a blend of infrastructure
 and platform services.

0:03:54.640000 --> 0:03:57.880000
 The last system route is none.

0:03:57.880000 --> 0:04:02.440000
 So if it doesn't fall under one of those
 routes, it's not being routed,

0:04:02.440000 --> 0:04:07.060000
 simple as that. Well, how
 do you impact the routing?

0:04:07.060000 --> 0:04:08.540000
 How do you customize the routing?

0:04:08.540000 --> 0:04:11.260000
 You customize the routing
 by using route tables.

0:04:11.260000 --> 0:04:16.260000
 And route tables are
 applied to subnets.

0:04:16.260000 --> 0:04:21.440000
 Every subnet can have one route
 table associated with it.

0:04:21.440000 --> 0:04:26.220000
 Each route table can be associated
 with multiple subnets.

0:04:26.220000 --> 0:04:29.340000
 So you kind of have a one to
 many type relationship there.

0:04:29.340000 --> 0:04:36.220000
 And a route table is really defined as
 a holding place, a holding container

0:04:36.220000 --> 0:04:38.100000
 for routing rules.

0:04:38.100000 --> 0:04:39.700000
 So routing rules are
 what's important.

0:04:39.700000 --> 0:04:43.420000
 And so I create a routing table or
 a route table so I can add routing

0:04:43.420000 --> 0:04:45.840000
 rules. What are routing rules?

0:04:45.840000 --> 0:04:48.700000
 Routing rules are a combination
 of information.

0:04:48.700000 --> 0:04:52.800000
 The key bits of information, really there's
 two key pieces of information.

0:04:52.800000 --> 0:04:54.880000
 One is the network prefix.

0:04:54.880000 --> 0:04:59.880000
 That's going to be the network prefix
 that this rule applies to, simple

0:04:59.880000 --> 0:05:04.500000
 as that. Then you say, okay, any request
 that goes to that prefix, it's

0:05:04.500000 --> 0:05:07.100000
 going to that prefix,
 where does it go?

0:05:07.100000 --> 0:05:11.620000
 And you have five
 different options.

0:05:11.620000 --> 0:05:13.200000
 You have virtual appliance.

0:05:13.200000 --> 0:05:16.460000
 So if you have a network virtual appliance
 that you're using as a firewall

0:05:16.460000 --> 0:05:20.760000
 or your own router, then you would set
 that as the next hop and you would

0:05:20.760000 --> 0:05:24.680000
 have to also specify what the
 next hop IP address is.

0:05:24.680000 --> 0:05:28.580000
 You can also specify route to go through
 a virtual network gateway.

0:05:28.580000 --> 0:05:36.440000
 Let's say, for example, that even though
 the public IP addresses are automatically

0:05:36.440000 --> 0:05:39.480000
 routed through the system route, you
 want to use something called forced

0:05:39.480000 --> 0:05:45.460000
 tunneling because you have on-premises
 your own appliance that you use

0:05:45.460000 --> 0:05:52.760000
 as a combined security appliance and it
 does your routing, does your firewalling

0:05:52.760000 --> 0:05:55.540000
 and you want all traffic that's going
 out to the public internet to go

0:05:55.540000 --> 0:05:56.440000
 through that device.

0:05:56.440000 --> 0:06:02.080000
 So even though there's a system route,
 again, as an example, for internet

0:06:02.080000 --> 0:06:08.060000
-based requests, you could route those
 through your VPN gateway to an on

0:06:08.060000 --> 0:06:12.320000
-premises box. There's
 also virtual network.

0:06:12.320000 --> 0:06:16.100000
 So if there's something that you do
 want to include within the virtual

0:06:16.100000 --> 0:06:19.040000
 network, to route within the virtual
 network, you can do that.

0:06:19.040000 --> 0:06:22.180000
 Usually you'll do that in combination
 with other rules, where maybe you've

0:06:22.180000 --> 0:06:28.120000
 got a rule that has a none and that's
 blocking all traffic, but some traffic

0:06:28.120000 --> 0:06:29.400000
 you want to allow.

0:06:29.400000 --> 0:06:31.300000
 So you're basically setting
 up a whitelist environment.

0:06:31.300000 --> 0:06:32.620000
 You could do that.

0:06:32.620000 --> 0:06:37.260000
 You could also route to the internet,
 which again, I would typically only

0:06:37.260000 --> 0:06:42.080000
 have to create an internet route for
 a specific set of addresses if I'm

0:06:42.080000 --> 0:06:46.620000
 routing the internet traffic
 some other way by default.

0:06:46.620000 --> 0:06:48.860000
 Now, what if you have
 overlapping routes?

0:06:48.860000 --> 0:06:50.660000
 And I just gave you examples
 of those, right?

0:06:50.660000 --> 0:06:54.320000
 So I've got a system route
 for the internet.

0:06:54.320000 --> 0:06:59.020000
 Why would I want to then send that
 through a virtual network gateway?

0:06:59.020000 --> 0:06:59.980000
 Well, we gave you a reason.

0:06:59.980000 --> 0:07:01.320000
 Well, how does it work?

0:07:01.320000 --> 0:07:04.080000
 The way it works is
 by route selection.

0:07:04.080000 --> 0:07:06.120000
 There's two criteria
 for route selection.

0:07:06.120000 --> 0:07:08.160000
 The first is prefix length.

0:07:08.160000 --> 0:07:10.360000
 And the longest prefix works.

0:07:10.360000 --> 0:07:17.740000
 So if I've got a rule that has a 24-bit
 prefix based on its CIDR representation,

0:07:17.740000 --> 0:07:23.980000
 that is going to take precedence over
 one that has a shorter prefix, right?

0:07:23.980000 --> 0:07:27.380000
 So 10.0.0 beats 10.0.

0:07:27.380000 --> 0:07:29.060000
 That's important.

0:07:29.060000 --> 0:07:33.580000
 Also, order of precedence
 user defined, i.e.

0:07:33.580000 --> 0:07:37.140000
 route table rules, are going to be
 the highest precedence followed by

0:07:37.140000 --> 0:07:39.720000
 BGP rules that are propagated.

0:07:39.720000 --> 0:07:43.340000
 And then finally, those system rules
 that I've already discussed.

0:07:43.340000 --> 0:07:47.400000
 And that's how route selection
 and route tables work.

0:07:47.400000 --> 0:07:52.320000
 Now, for the fun bit, and that
 is a bit of a demonstration.

0:07:52.320000 --> 0:07:54.640000
 I'm going to set up demonstration
 with Azure routing.

0:07:54.640000 --> 0:07:58.800000
 Before I go into the demonstration,
 I want to show you the topology that

0:07:58.800000 --> 0:08:04.700000
 I have set up. Now, I have this topology
 for a range of demonstrations.

0:08:04.700000 --> 0:08:07.860000
 It works pretty well for a lot of different
 things I want to show you.

0:08:07.860000 --> 0:08:13.060000
 This is going to be the first
 time we've seen it.

0:08:13.060000 --> 0:08:14.260000
 There's a lot of different
 things going on.

0:08:14.260000 --> 0:08:16.440000
 Here is the demonstration
 architecture.

0:08:16.440000 --> 0:08:23.020000
 Now, I have already set up between two virtual
 networks, a peering relationship.

0:08:23.020000 --> 0:08:25.800000
 So we already have that
 peering relationship.

0:08:25.800000 --> 0:08:28.540000
 But what I have is I have
 two virtual networks.

0:08:28.540000 --> 0:08:34.340000
 I've got the U web server vnet
 and the W wind server vnet.

0:08:34.340000 --> 0:08:38.720000
 On the wind server vnet, I just have two
 pretty much stock windows servers.

0:08:38.720000 --> 0:08:46.140000
 On the web server, those are, by the
 way, windows server 2016 data center.

0:08:46.140000 --> 0:08:49.160000
 In the web server, a little
 more interesting.

0:08:49.160000 --> 0:08:53.280000
 I've got two Ubuntu servers set up
 as very primitive web servers.

0:08:53.280000 --> 0:08:57.380000
 I have a network virtual appliance
 routing virtual appliance.

0:08:57.380000 --> 0:08:58.320000
 I've got set up.

0:08:58.320000 --> 0:09:01.480000
 It's a PF sense router that
 I've got configured.

0:09:01.480000 --> 0:09:02.880000
 And then not used here.

0:09:02.880000 --> 0:09:04.700000
 I've got a monitor server.

0:09:04.700000 --> 0:09:10.020000
 Now, right now, I've got the
 peering connection set up.

0:09:10.020000 --> 0:09:15.700000
 So if I were on one of these virtual
 machines and I wanted to get to one

0:09:15.700000 --> 0:09:20.620000
 of the web servers, I could really just,
 as long as I know that IP address,

0:09:20.620000 --> 0:09:22.360000
 I can just go right
 to that IP address.

0:09:22.360000 --> 0:09:23.760000
 And it's going to go right there.

0:09:23.760000 --> 0:09:28.400000
 But what I want to do is I want to set
 up a routing rule so that any request

0:09:28.400000 --> 0:09:35.780000
 over to the web server vnet is going
 to go through the router first and

0:09:35.780000 --> 0:09:38.460000
 then to the web server.

0:09:38.460000 --> 0:09:40.760000
 And this is a trivial example.

0:09:40.760000 --> 0:09:44.160000
 And you can say, OK, well, there's
 really no need to do that here.

0:09:44.160000 --> 0:09:47.380000
 Obviously, that's true, but it does,
 frankly, give me an easy way to show

0:09:47.380000 --> 0:09:56.320000
 you routing. So without further ado,
 let's pop into that demonstration.

0:09:56.320000 --> 0:10:01.000000
 I want to take a look at the
 actual topology diagram here.

0:10:01.000000 --> 0:10:04.180000
 And we're going to go off of that.


0:10:04.180000 --> 0:10:08.060000
 Here's my topology in general.

0:10:08.060000 --> 0:10:13.540000
 And I can see my web server vnet that
 has web server one, web server zero,

0:10:13.540000 --> 0:10:16.820000
 and the router as well
 as the monitor.

0:10:16.820000 --> 0:10:19.960000
 And then I've got my two
 window servers over here.

0:10:19.960000 --> 0:10:26.040000
 What I'm going to do is add a route
 table to the default subnet of the

0:10:26.040000 --> 0:10:31.100000
 wind server that is going to route
 all traffic going to the web server

0:10:31.100000 --> 0:10:33.960000
 vnet through the router.

0:10:33.960000 --> 0:10:35.860000
 Well, to do that, I need
 to do a few things.

0:10:35.860000 --> 0:10:38.080000
 First of all, let's
 take a look at this.

0:10:38.080000 --> 0:10:39.800000
 So that's the 10.0.

0:10:39.800000 --> 0:10:47.580000
 OK, my web server vnet
 is 10.0.0 slash 16.

0:10:47.580000 --> 0:10:54.820000
 And my router, also important,
 is 10.0.0.10.

0:10:54.820000 --> 0:10:58.920000
 It should be noted that in this topology,
 my router only has a single

0:10:58.920000 --> 0:11:06.880000
 NIC. And that NIC is in the default subnet
 of my web server virtual network.

0:11:06.880000 --> 0:11:10.580000
 You'll typically, if you have a NVA
 router, network virtual appliance

0:11:10.580000 --> 0:11:13.600000
 router, it's probably going to have
 multiple NICs, but this is just for

0:11:13.600000 --> 0:11:15.160000
 simplicity of demonstration.

0:11:15.160000 --> 0:11:16.860000
 I left it this way.

0:11:16.860000 --> 0:11:18.700000
 All right, I need to
 configure two things.

0:11:18.700000 --> 0:11:25.880000
 I need to configure my route table for
 my subnet, and I need to make sure

0:11:25.880000 --> 0:11:28.260000
 that my router is in fact routing.


0:11:28.260000 --> 0:11:34.460000
 Let's go to my subnet, and I can see with
 my subnet, if I go to this subnet,

0:11:34.460000 --> 0:11:39.880000
 that I do not currently have a route
 table, and I cannot add it here.

0:11:39.880000 --> 0:11:44.640000
 So what I need to do is create
 a new route table.

0:11:44.640000 --> 0:11:49.300000
 So I'm going to go ahead
 and create my W.

0:11:49.300000 --> 0:11:53.700000
 And server RT for route table.

0:11:53.700000 --> 0:11:55.800000
 Oh, that's the name.

0:11:55.800000 --> 0:11:59.880000
 There we go, route table.

0:11:59.880000 --> 0:12:05.260000
 Create that, and I
 already typed it.

0:12:05.260000 --> 0:12:08.080000
 We're there. We're going to put this
 in task one, which is where I put

0:12:08.080000 --> 0:12:09.420000
 everything else.

0:12:09.420000 --> 0:12:14.880000
 And it's going to allow virtual network
 gateway route propagation.

0:12:14.880000 --> 0:12:17.880000
 So if I've got routes coming in through
 a virtual network gateway, we'll

0:12:17.880000 --> 0:12:21.560000
 automatically allow
 those to propagate.

0:12:21.560000 --> 0:12:27.540000
 And once that's done provisioning,
 we will continue to configure it.

0:12:27.540000 --> 0:12:34.840000
 All right, it looks like that
 has finished provisioning.

0:12:34.840000 --> 0:12:38.260000
 So let's go and pop over to that.

0:12:38.260000 --> 0:12:42.900000
 I've got my route table here.

0:12:42.900000 --> 0:12:45.580000
 And what I'm going to do, I can actually
 do all the configuration from

0:12:45.580000 --> 0:12:46.280000
 the route table.

0:12:46.280000 --> 0:12:46.800000
 It's pretty cool.

0:12:46.800000 --> 0:12:49.940000
 I can set the routes and associate
 it with a subnet.

0:12:49.940000 --> 0:12:53.680000
 So I'm going to go to the route,
 and I am going to create a route.

0:12:53.680000 --> 0:12:58.720000
 And this is going to just
 be called web route.

0:12:58.720000 --> 0:13:06.920000
 And the address prefix that I'm going
 to go to is 10.0.0.0 slash 24.

0:13:06.920000 --> 0:13:10.600000
 Anything going to 10.0.0.0.

0:13:10.600000 --> 0:13:15.400000
 And I want that to go to
 a virtual appliance.

0:13:15.400000 --> 0:13:19.680000
 And I want that address
 to be 10.0.0.10.

0:13:19.680000 --> 0:13:24.400000
 So that is my router appliance.

0:13:24.400000 --> 0:13:27.100000
 And that is adding the rule.

0:13:27.100000 --> 0:13:32.840000
 And while that rule is being added, I
 can associate this route table with

0:13:32.840000 --> 0:13:36.960000
 a subnet. I'm going to
 go ahead and associate.

0:13:36.960000 --> 0:13:42.340000
 I'm going to pick the
 W wind server vnet.

0:13:42.340000 --> 0:13:47.240000
 And associate it with
 the default subnet.

0:13:47.240000 --> 0:13:53.320000
 And that should be
 all I need to do.

0:13:53.320000 --> 0:13:57.820000
 And so I can see, okay, this is associated
 with the 10.1.0.0 slash 24,

0:13:57.820000 --> 0:13:59.440000
 which is the wind server.

0:13:59.440000 --> 0:14:06.700000
 And again, I have a routing rule set
 up for 10.0.0.0 slash 24 going to

0:14:06.700000 --> 0:14:12.240000
 10.0.0.10. All right, so
 how would this work?

0:14:12.240000 --> 0:14:14.200000
 Well, it's a couple things.

0:14:14.200000 --> 0:14:18.500000
 First of all, I have pulled up, this
 is one of my windows servers.

0:14:18.500000 --> 0:14:20.440000
 I think this is wind one.

0:14:20.440000 --> 0:14:24.640000
 And on the windows server, I've actually
 navigated over to the interface

0:14:24.640000 --> 0:14:29.460000
 for the PF sense router.

0:14:29.460000 --> 0:14:33.160000
 Or actually, network virtual appliance,
 because it does routing and does

0:14:33.160000 --> 0:14:36.320000
 firewalling as well, and
 VPN and other things.

0:14:36.320000 --> 0:14:39.560000
 But I'm really only using
 this for a router.

0:14:39.560000 --> 0:14:43.660000
 I really didn't do any configuration
 other than the fact that for this

0:14:43.660000 --> 0:14:49.940000
 particular system, because I'm going
 to go to port 80, I had to redirect

0:14:49.940000 --> 0:14:53.380000
 port 80 from the WAN address, which would
 be its public IP, which it doesn't

0:14:53.380000 --> 0:14:56.440000
 have, into just anywhere, right?

0:14:56.440000 --> 0:14:59.420000
 Which is a little bit sloppy,
 but it will work.

0:14:59.420000 --> 0:15:06.600000
 Now, the next thing that I want to
 do is I want to go to one of my two

0:15:06.600000 --> 0:15:15.400000
.5, which is one of my servers.

0:15:15.400000 --> 0:15:18.120000
 We will wait for that to come up.

0:15:18.120000 --> 0:15:23.280000
 All right, and what you see come up
 here, and this is not looking very

0:15:23.280000 --> 0:15:26.620000
 monumental, but it says,
 you web server one.

0:15:26.620000 --> 0:15:29.540000
 That means that I came
 up to that server.

0:15:29.540000 --> 0:15:34.520000
 In fact, if I go to 10.0.0.6, it comes
 up with you web server zero.

0:15:34.520000 --> 0:15:37.460000
 And you see a slight difference, and
 I'll ask you to take my word, that

0:15:37.460000 --> 0:15:40.360000
 that actually is connecting
 to that particular machine.

0:15:40.360000 --> 0:15:45.860000
 Now, the other thing that I can do
 here is, I don't need to flush DNS,

0:15:45.860000 --> 0:15:54.780000
 but let me do a trace
 route to 10.0.0.5.

0:15:54.780000 --> 0:16:01.620000
 And let me actually bump up the font
 so you can read this a little bit.

0:16:01.620000 --> 0:16:05.260000
 24, should be a little
 bit more readable.

0:16:05.260000 --> 0:16:08.640000
 There we go, there's my trace RT.

0:16:08.640000 --> 0:16:10.460000
 OK, and there we go.

0:16:10.460000 --> 0:16:12.800000
 That's the big payoff.

0:16:12.800000 --> 0:16:18.420000
 Notice the first hop goes to 10.0.0.10,
 and then it goes to its destination.

0:16:18.420000 --> 0:16:25.040000
 So I am now routing the traffic that's
 coming from my subnet on the win

0:16:25.040000 --> 0:16:27.300000
 network, if you will.

0:16:27.300000 --> 0:16:31.300000
 And it's routing through a network virtual
 appliance, getting to the other

0:16:31.300000 --> 0:16:36.920000
 network. And again, it's a somewhat trivial
 case, but as far as the configuration

0:16:36.920000 --> 0:16:40.020000
 of the Azure networking,
 that's what you do.

0:16:40.020000 --> 0:16:43.420000
 Really, any of the complexity is going
 to come down, frankly, to what

0:16:43.420000 --> 0:16:46.580000
 you're doing within the network
 virtual appliance.

0:16:46.580000 --> 0:16:50.920000
 Azure makes it, in my opinion, pretty
 straightforward process to integrate

0:16:50.920000 --> 0:16:52.220000
 that custom routing capability.