WEBVTT 1 00:00.000 --> 00:04.160 All right, we're going to jump into a quiz. It's going to be a question. So not 2 00:04.160 --> 00:07.720 too long here. We just want to spend some time reviewing the virtualization 3 00:07.720 --> 00:13.130 technology that covers virtual networking, as well as VRS, GRE, and IPSec. And 4 00:13.130 --> 00:17.000 then we'll worry about Lisbon VX land coming up. First question here, which 5 00:17.000 --> 00:21.000 type of hypervisors deployed onto bare metal and which type of hypervisors 6 00:21.000 --> 00:26.020 installed onto an existing operating system. So let's take a moment to remember 7 00:26.020 --> 00:28.000 what exactly a hypervisor is. 8 00:28.000 --> 00:32.690 The idea here was that originally, if I had a piece of hardware, that would be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:28.000 --> 00:32.690 The idea here was that originally, if I had a piece of hardware, that would be 9 00:32.690 --> 00:39.200 a server. So CPU, memory, all of the different components of a server, 10 00:39.200 --> 00:43.000 basically the same stuff that makes up a PC, we would install an operating 11 00:43.000 --> 00:46.930 system. And for all the reasons we discussed, we typically in an enterprise 12 00:46.930 --> 00:51.310 environment in a data center would install a single application per operating 13 00:51.310 --> 00:52.000 system. 14 00:52.000 --> 00:58.010 And this wasn't super efficient. It wasn't an efficient use of our resources. 15 00:58.010 --> 01:03.400 And so the concept of virtualization came along and virtualization on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 15 00:58.010 --> 01:03.400 And so the concept of virtualization came along and virtualization on the 16 01:03.400 --> 01:07.550 server level allowed us to deploy one piece of hardware. So we're still 17 01:07.550 --> 01:12.270 deploying a server, maybe with more CPU and RAM, but it's all the same stuff in 18 01:12.270 --> 01:14.000 the server. 19 01:14.000 --> 01:19.710 And then the idea here is that we would build on top of this, not an operating 20 01:19.710 --> 01:24.590 system, but a hypervisor. And this hypervisor will allow us to install 21 01:24.590 --> 01:29.200 individual virtual machines, which are their own instance of an operating 22 01:29.200 --> 01:34.000 system, which allows us still to maintain that one to one relationship between WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 01:29.200 --> 01:34.000 system, which allows us still to maintain that one to one relationship between 23 01:34.000 --> 01:36.000 application and operating system. 24 01:36.000 --> 01:41.150 But it's no, it breaks the idea that I need a one to one to the hardware. I no 25 01:41.150 --> 01:46.590 longer need that. Instead, I can place many virtual machines potentially a 26 01:46.590 --> 01:53.000 handful potentially dozens of virtual machines onto a single piece of hardware. 27 01:53.000 --> 01:57.350 And a single piece of hardware is now known as a virtual host, while these 28 01:57.350 --> 02:01.760 virtual machines can be known as guests, although like we said, we don't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:57.350 --> 02:01.760 virtual machines can be known as guests, although like we said, we don't 29 02:01.760 --> 02:06.260 usually call them guests, some people do, but we usually refer to these as 30 02:06.260 --> 02:12.000 virtual machines or VMS, and the host itself that is absolutely a term we use 31 02:12.000 --> 02:15.730 that helps us to differentiate between what is a server because is this the 32 02:15.730 --> 02:19.590 server now is this the server, we don't need to worry about that we try not to 33 02:19.590 --> 02:23.000 use the word server because that just makes things confusing. 34 02:23.000 --> 02:28.410 So when we see a hypervisor deployed like this, this is known as a type one, 35 02:28.410 --> 02:33.530 and this is absolutely what we expect to see in our enterprise corporate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 02:28.410 --> 02:33.530 and this is absolutely what we expect to see in our enterprise corporate 36 02:33.530 --> 02:35.000 environments. 37 02:35.000 --> 02:39.930 So if I'm going into a data center, I am expecting to find that my virtual 38 02:39.930 --> 02:45.220 hosts consist of type one hypervisors. These would be hypervisors like VMware v 39 02:45.220 --> 02:52.000 Sphere and Microsoft hyper V, the two probably biggest branded hypervisors that 40 02:52.000 --> 02:52.000 are out there. 41 02:52.000 --> 02:56.910 But there are also plenty others that would qualify as well. Meanwhile, we do 42 02:56.910 --> 03:05.000 have a residential or maybe a lab, not residual, residential option. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 02:56.910 --> 03:05.000 have a residential or maybe a lab, not residual, residential option. 43 03:05.000 --> 03:09.840 And again, we might see this in enterprise labs, that kind of thing, but we 44 03:09.840 --> 03:12.000 have the concept of a type two. 45 03:12.000 --> 03:17.730 Type two is not really intended for enterprise deployments. The idea here is 46 03:17.730 --> 03:22.500 that I could have now going back to the concept of installing an operating 47 03:22.500 --> 03:26.000 system directly onto a piece of hardware. So this could be my laptop. 48 03:26.000 --> 03:30.480 This could be my desktop, or it could be a lab server. We've got lots of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 03:26.000 --> 03:30.480 This could be my desktop, or it could be a lab server. We've got lots of 49 03:30.480 --> 03:34.720 options here. But in the end, usually we're talking about deploying these onto 50 03:34.720 --> 03:36.000 our home devices. 51 03:36.000 --> 03:42.260 So I've got my desktop PC here, and I've got my Windows operating system. And 52 03:42.260 --> 03:47.500 now I can install the type one hypervisor or type two rather type two hyper 53 03:47.500 --> 03:53.000 visor as an application running on my operating system. 54 03:53.000 --> 03:57.980 And now I can deploy all of my virtual machines. And so the hypervisor still 55 03:57.980 --> 04:03.170 has to build internal networking to the operating system, but we don't usually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 03:57.980 --> 04:03.170 has to build internal networking to the operating system, but we don't usually 56 04:03.170 --> 04:06.000 deal with too many of those details. 57 04:06.000 --> 04:11.410 It's really designed to be very simple to deploy. And this allows me to deploy 58 04:11.410 --> 04:18.610 usually virtual appliances that again are especially useful for lab and testing 59 04:18.610 --> 04:19.000 . 60 04:19.000 --> 04:22.560 So that's the difference in type one and type two. Let's make sure we 61 04:22.560 --> 04:26.660 understand the whole concept of virtualization, where it comes from, what a 62 04:26.660 --> 04:30.830 hypervisor is, and then once again, understanding the differences between a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 04:26.660 --> 04:30.830 hypervisor is, and then once again, understanding the differences between a 63 04:30.830 --> 04:33.000 type one and a type two. 64 04:33.000 --> 04:37.580 Question two, what switching mechanism is used by virtual switches in order to 65 04:37.580 --> 04:40.000 avoid running spanning tree protocol. 66 04:40.000 --> 04:45.350 So this is kind of a big deal. We have a virtual host, and we've just said that 67 04:45.350 --> 04:50.920 we're going to deploy individual virtual machines, each of which has its own IP 68 04:50.920 --> 04:52.000 address. 69 04:52.000 --> 05:00.000 And we are going to network out to, in theory, a physical switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 04:52.000 --> 05:00.000 And we are going to network out to, in theory, a physical switch. 70 05:00.000 --> 05:04.080 So by connecting to the physical switch, that's great. But if I send my network 71 05:04.080 --> 05:08.000 traffic up, like we said, we're not able to send that traffic back down. 72 05:08.000 --> 05:11.780 And that's just the basic rules of ethernet. I never forward a frame out the 73 05:11.780 --> 05:15.690 same interface that I receive it. So how are these virtual machines supposed to 74 05:15.690 --> 05:17.000 communicate with one another? 75 05:17.000 --> 05:23.650 Well, that is going to require the virtual switch. The virtual switch is truly 76 05:23.650 --> 05:28.150 a software package, but it's also a software package that is running very 77 05:28.150 --> 05:29.000 similar codes. 78 05:29.000 --> 05:33.830 So it's very similar code to what's running in a physical switch. The idea here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 05:29.000 --> 05:33.830 So it's very similar code to what's running in a physical switch. The idea here 79 05:33.830 --> 05:38.310 is that these virtual machines, that's, by the way, are also software, are 80 05:38.310 --> 05:43.650 going to be sending their packets to this other software package, this virtual 81 05:43.650 --> 05:46.000 switch, and it will decide what to do with them. 82 05:46.000 --> 05:49.490 That allows these virtual machines to communicate with one another. So now I 83 05:49.490 --> 05:54.980 can perform this East West traffic flow, and it stays, interestingly, within 84 05:54.980 --> 05:56.000 the host. 85 05:56.000 --> 05:59.810 I just send my packet into the software process that's running the virtual 86 05:59.810 --> 06:03.860 switch, and then it spits it back out to the virtual machine that I'm trying to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 05:59.810 --> 06:03.860 switch, and then it spits it back out to the virtual machine that I'm trying to 87 06:03.860 --> 06:08.240 communicate with, which does mean that visibility from a network engineering 88 06:08.240 --> 06:13.000 perspective isn't always the best, because I usually do like to see those 89 06:13.000 --> 06:13.000 packets. 90 06:13.000 --> 06:17.430 That allows me to see what's happening in my network. I might want to run 91 06:17.430 --> 06:22.550 security, you know, prevent communications in some situations, but I lack that 92 06:22.550 --> 06:27.000 visibility when the traffic stays inside of that virtual switch. 93 06:27.000 --> 06:32.000 Now, the virtual switch is going to effectively receive a physical connection. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 93 06:27.000 --> 06:32.000 Now, the virtual switch is going to effectively receive a physical connection. 94 06:32.000 --> 06:36.030 Usually we want to do a couple of these. And because we're running a couple 95 06:36.030 --> 06:41.000 connections, might say, okay, well, this, you know, let's draw it like this. 96 06:41.000 --> 06:46.780 This could create a network loop. If the virtual switch brings a broadcast 97 06:46.780 --> 06:51.260 packet in and sends it back out, and it's not running spanning tree, that's 98 06:51.260 --> 06:53.000 going to cause a major problem. 99 06:53.000 --> 06:58.160 So we want to prevent this, and we could just bundle these connections together 100 06:58.160 --> 07:02.000 , but we don't necessarily want to have to rely on that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 06:58.160 --> 07:02.000 , but we don't necessarily want to have to rely on that. 101 07:02.000 --> 07:07.440 So instead, we use the concept of pinning. Pinning essentially maps a one-to- 102 07:07.440 --> 07:12.990 one relationship between one of these virtual machines and one of the uplinks. 103 07:12.990 --> 07:19.650 We pin them to a specific uplink, which means that in this environment, when I 104 07:19.650 --> 07:24.490 send even broadcast messages out, it's only going to go out one of those, which 105 07:24.490 --> 07:28.000 does mean by the way that it will loop back around and there's rules to prevent 106 07:28.000 --> 07:32.310 this virtual switch from forwarding that because the switch is going to do its WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 07:28.000 --> 07:32.310 this virtual switch from forwarding that because the switch is going to do its 107 07:32.310 --> 07:36.480 job and for that broadcast traffic back out. But the good news here is that 108 07:36.480 --> 07:40.610 when broadcast traffic is received on both of these, once again, the virtual 109 07:40.610 --> 07:43.000 switch is going to ignore one of those. 110 07:43.000 --> 07:47.360 And so we create a bunch of loop prevention rules around this, but it's the pin 111 07:47.360 --> 07:51.000 ning nature that we're using that's going to prevent loops. 112 07:51.000 --> 07:55.580 And it's important for us to understand how pinning operates and just the fact 113 07:55.580 --> 08:00.160 that it's used heavily in virtual environments, and by the way, in Cisco UCS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 07:55.580 --> 08:00.160 that it's used heavily in virtual environments, and by the way, in Cisco UCS 114 08:00.160 --> 08:04.000 products, which is Cisco server, well, line of servers, I guess. 115 08:04.000 --> 08:10.260 Pinning is very heavily used for the sake of this course and the scope of this 116 08:10.260 --> 08:14.570 exam. We mostly just should understand that pinning is a concept, what exactly 117 08:14.570 --> 08:18.230 it is, and that it is used to prevent loops going down to those virtual 118 08:18.230 --> 08:19.000 switches. 119 08:20.000 --> 08:24.180 Question three, how can two VRFs communicate with one another on a router? So 120 08:24.180 --> 08:29.040 remember what we're talking about here. If we've got a router and I want to 121 08:29.040 --> 08:34.330 carve this up into multiple VRFs virtual routing and forwarding instances, let WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 08:29.040 --> 08:34.330 carve this up into multiple VRFs virtual routing and forwarding instances, let 122 08:34.330 --> 08:36.000 's say A and B here. 123 08:36.000 --> 08:40.780 Well, every single layer three interface, whether it's a sub interface or 124 08:40.780 --> 08:45.890 physical interface, must belong to exactly one of these VRFs. And so we might 125 08:45.890 --> 08:51.000 have four ports or four sub interfaces, whatever it is coming into this router. 126 08:51.000 --> 08:56.060 And we've placed these into the appropriate VRF. So if a packet arrives here, 127 08:56.060 --> 09:00.520 the only eligible option for it to leave this router would be to go out the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 08:56.060 --> 09:00.520 the only eligible option for it to leave this router would be to go out the 128 09:00.520 --> 09:05.320 interface that's in the same VRF, because we have our own dedicated routing 129 09:05.320 --> 09:08.000 table for each one of these VRFs. 130 09:08.000 --> 09:13.130 And this routing table does not see that interface or this interface. It doesn 131 09:13.130 --> 09:18.190 't even see those as options. And so again, it's going to have to stay in its 132 09:18.190 --> 09:22.770 own VRF. So how can these two VRFs communicate with one another? Believe it or 133 09:22.770 --> 09:29.730 not, the answer is A, by looping a cable on the device. If I were to loop this 134 09:29.730 --> 09:33.210 one of these connections over to the other in the other VRF, then I could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 134 09:29.730 --> 09:33.210 one of these connections over to the other in the other VRF, then I could 135 09:33.210 --> 09:37.000 communicate because it would, or the packet would land on VRFA. 136 09:37.000 --> 09:44.040 Get routed out this port, land over here in VRFB, and get routed wherever it's 137 09:44.040 --> 09:47.580 going. Feels a little silly to say this, but you know, we might send this 138 09:47.580 --> 09:52.140 through a firewall or something like that down here. We've got options and 139 09:52.140 --> 09:56.000 reasons why we might do this in an enterprise space. 140 09:56.000 --> 10:01.480 And so just keep in mind that this implementation, as we've pointed out, is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 09:56.000 --> 10:01.480 And so just keep in mind that this implementation, as we've pointed out, is 141 10:01.480 --> 10:07.690 known as VRF Lite. Lite just means that we're not running MPLS. And MPLS is how 142 10:07.690 --> 10:14.000 we are typically deploying VRFs for multi-tenant service provider networks. 143 10:14.000 --> 10:19.060 In the enterprise space, we're not usually running MPLS. Instead, we are simply 144 10:19.060 --> 10:24.060 deploying VRFs with the most common example of a VRF being the management VRF. 145 10:24.060 --> 10:29.000 But there are certainly other spaces we might use them, such as with overlays 146 10:29.000 --> 10:31.000 and underlays as we saw with GRE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 146 10:29.000 --> 10:31.000 and underlays as we saw with GRE. 147 10:31.000 --> 10:36.310 But just keep in mind how exactly VRFs work and that there is a very firm 148 10:36.310 --> 10:41.420 boundary established here as far as what our options are. And it's really 149 10:41.420 --> 10:46.260 thanks to the fact that we're running routing tables, unique individual routing 150 10:46.260 --> 10:49.000 tables in both VRFs. 151 10:49.000 --> 10:53.140 All right, next question here. How many bytes of overhead are added when using 152 10:53.140 --> 10:57.810 GRE to tunnel IPv4 traffic? Diagram the header to show the answer. So how 153 10:57.810 --> 11:07.300 exactly do we handle GRE? So if I bring a layer three packet in here, and we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 153 10:57.810 --> 11:07.300 exactly do we handle GRE? So if I bring a layer three packet in here, and we're 154 11:07.300 --> 11:14.400 going to send it out a tunnel interface that's running GRE, what does the 155 11:14.400 --> 11:16.000 packet look like over here? 156 11:16.000 --> 11:19.400 What we're going to do is we're going to take this packet and we're going to 157 11:19.400 --> 11:24.590 turn it into the new payload. So this whole packet, including the IP header, 158 11:24.590 --> 11:30.730 including the TCP or UDP header, that'd be our layer four, the original payload WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 11:24.590 --> 11:30.730 including the TCP or UDP header, that'd be our layer four, the original payload 159 11:30.730 --> 11:37.000 . This is all getting wrapped up as the new payload 160 11:37.000 --> 11:41.770 for our new packet. And so what we're going to do here is we're going to 161 11:41.770 --> 11:47.820 establish, first of all, a GRE header, and this is four bytes in size. And then 162 11:47.820 --> 11:52.500 we're going to need that outer IP header. So remember, we end up with the 163 11:52.500 --> 11:57.000 concept of an inner header here, which is ignored by the underlay, and then the 164 11:57.000 --> 12:02.000 outer header, which is the only layer three header that the underlay is looking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 164 11:57.000 --> 12:02.000 outer header, which is the only layer three header that the underlay is looking 165 12:02.000 --> 12:06.000 at. This is what tells us how to get to the tunnel destination. 166 12:06.000 --> 12:10.770 This is how we get to the final destination. But again, the underlay might not 167 12:10.770 --> 12:15.480 know where that final destination is. It just needs to know how to get to the 168 12:15.480 --> 12:19.000 tunnel destination. And so that's what goes into this IP header. 169 12:19.000 --> 12:24.210 Well, like we said, the GRE header is four bytes and IP header is 20 bytes. And 170 12:24.210 --> 12:29.460 we say, well, usually we're not too worried about this. It's part of the 1500 171 12:29.460 --> 12:33.780 bytes, except we already have that IP header inside of here. So we have to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 171 12:29.460 --> 12:33.780 bytes, except we already have that IP header inside of here. So we have to 172 12:33.780 --> 12:34.000 account for that. 173 12:34.000 --> 12:39.000 So it is going to be 20 bytes here that we have to add from an MTU perspective. 174 12:39.000 --> 12:46.230 So ideally, as we've said, the underlay should support an MTU of 1524. The 175 12:46.230 --> 12:51.000 tunnel interface will have an MTU of 1476. 176 12:51.000 --> 12:55.820 But again, that doesn't prevent fragmentation. If we really want to prevent 177 12:55.820 --> 13:02.000 fragmentation, we must increase the MTU, and it has to be by those 24 bytes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 177 12:55.820 --> 13:02.000 fragmentation, we must increase the MTU, and it has to be by those 24 bytes. 178 13:03.000 --> 13:07.970 All right, question five, which scenario leads to recursive routing errors on a 179 13:07.970 --> 13:13.780 GRE tunnel? So when we look at these answer choices, it doesn't have anything 180 13:13.780 --> 13:17.000 to do with specific routing protocols. 181 13:17.000 --> 13:21.650 We could make that argument because if we are creating problems, then the 182 13:21.650 --> 13:26.750 administrative distance will end up mattering. And if we do have the better 183 13:26.750 --> 13:30.690 administrative distance running on the overlay, this is where we can cause WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 183 13:26.750 --> 13:30.690 administrative distance running on the overlay, this is where we can cause 184 13:30.690 --> 13:32.000 problems for ourselves. 185 13:32.000 --> 13:37.530 But again, I want to really drive home the underlying core problem with all of 186 13:37.530 --> 13:43.010 this is simply that we are advertising our underlay routes across the overlay. 187 13:43.010 --> 13:45.000 And there's no reason for us to do that. 188 13:45.000 --> 13:50.010 So D here is going to be the answer. If we're advertising our underlay routes 189 13:50.010 --> 13:55.290 into the overlay, that is a problem, because keep in mind how recursive routing 190 13:55.290 --> 13:59.530 happens is that these routers need to know how to send to the tunnel 191 13:59.530 --> 14:00.000 destination. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 191 13:59.530 --> 14:00.000 destination. 192 14:00.000 --> 14:03.990 Well, the tunnel destination is part of the underlay. So these layer three 193 14:03.990 --> 14:08.680 interfaces, let's just draw one device in between here. These layer three 194 14:08.680 --> 14:15.820 interfaces must be known via the underlay. So this, let's say, actually, let's 195 14:15.820 --> 14:17.000 say we're going to the right here. 196 14:17.000 --> 14:24.250 So this is my tunnel destination. When a packet comes in and I encapsulate it 197 14:24.250 --> 14:29.410 for my tunnel, I now have a new destination. It's this destination here. And I 198 14:29.410 --> 14:34.000 need to see that I send the packet out the underlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 198 14:29.410 --> 14:34.000 need to see that I send the packet out the underlay. 199 14:34.000 --> 14:38.420 If I think I'm supposed to send it across the tunnel, that's a big problem. So 200 14:38.420 --> 14:42.780 how would that happen? How do I all of a sudden decide that, hey, my routing 201 14:42.780 --> 14:46.770 table, it says that that network exists out the overlay of this tunnel 202 14:46.770 --> 14:48.000 interface? 203 14:48.000 --> 14:56.140 Well, the only way that happens is if I advertise that subnet out the overlay. 204 14:56.140 --> 14:59.230 There's no reason of the world that that should happen. Now, maybe accidentally 205 14:59.230 --> 15:03.000 happened throughout summarization or default routes or any of those kinds of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 14:59.230 --> 15:03.000 happened throughout summarization or default routes or any of those kinds of 206 15:03.000 --> 15:03.000 things. 207 15:03.000 --> 15:07.410 But if we just make sure that we are properly advertising it across the under 208 15:07.410 --> 15:11.960 lay and that this initial, this router knows to send it out the physical under 209 15:11.960 --> 15:15.000 lay interface, at that point we're good to go. 210 15:15.000 --> 15:19.850 So we can really get into conversations about metrics and costs and OSPF and E 211 15:19.850 --> 15:25.090 IGRP and VRFs. But if we simply just don't advertise our underlay routes into 212 15:25.090 --> 15:28.000 the overlay, then we're going to be fine. 213 15:28.000 --> 15:33.000 And so that's the biggest takeaway from that recursive routing conversation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 213 15:28.000 --> 15:33.000 And so that's the biggest takeaway from that recursive routing conversation. 214 15:33.000 --> 15:39.400 Alright, question number six. IPsec comes with AHESP transport mode and tunnel 215 15:39.400 --> 15:44.000 mode options. Which combination is considered to be the most secure? 216 15:44.000 --> 15:48.850 So we should absolutely know the difference between authentication header and 217 15:48.850 --> 15:52.540 encapsulated security payload. We also should know the difference between 218 15:52.540 --> 15:54.000 transport mode and tunnel mode. 219 15:54.000 --> 15:58.750 And so in general, what we're really looking for is which one of these adds 220 15:58.750 --> 16:03.330 more security. So authentication header, as the name implies, is going to be a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 220 15:58.750 --> 16:03.330 more security. So authentication header, as the name implies, is going to be a 221 16:03.330 --> 16:05.000 little bit more focused on authentication. 222 16:05.000 --> 16:09.360 Although it doesn't just help with authentication. It also helps with message 223 16:09.360 --> 16:13.000 integrity, which is an important part of our security framework. 224 16:13.000 --> 16:17.560 ESP, on the other hand, is going to do all of this. It's going to do 225 16:17.560 --> 16:23.000 authentication. It's going to do integrity. And it's going to do encryption. 226 16:23.000 --> 16:28.620 And so for layering encryption on top, then ESP is absolutely going to be the 227 16:28.620 --> 16:32.790 more secure option. And typically this is what we see used in enterprise spaces WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 227 16:28.620 --> 16:32.790 more secure option. And typically this is what we see used in enterprise spaces 228 16:32.790 --> 16:33.000 . 229 16:33.000 --> 16:38.010 Authentication header was just created as a way to give us an option for 230 16:38.010 --> 16:44.000 scenarios where number one we probably trust the underlay, but also number two, 231 16:44.000 --> 16:47.370 we have some devices that just don't have the resources necessary to encrypt 232 16:47.370 --> 16:51.000 every frame and decrypt every frame, by the way. 233 16:51.000 --> 16:55.300 And so then we also have transport mode and tunnel mode. So when we're looking 234 16:55.300 --> 17:00.980 at IPsec, we're going to look at the fact that we have headers and we have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 234 16:55.300 --> 17:00.980 at IPsec, we're going to look at the fact that we have headers and we have the 235 17:00.980 --> 17:02.000 payload. 236 17:02.000 --> 17:10.070 And so as we encapsulate into IPsec, the question is, do we encrypt the payload 237 17:10.070 --> 17:16.000 only? Because if so, that would be transport mode. 238 17:16.000 --> 17:23.000 Or do we encapsulate both? If we encapsulate both, this would be tunnel mode. 239 17:23.000 --> 17:31.000 Well, encapsulating both and encrypting both the header and the payload. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 239 17:23.000 --> 17:31.000 Well, encapsulating both and encrypting both the header and the payload. 240 17:31.000 --> 17:37.160 That is typically going to be seen as more secure as well. It should be. And so 241 17:37.160 --> 17:40.000 tunnel mode is going to be the more secure option. 242 17:40.000 --> 17:46.000 And so let's make sure we understand the difference in these IPsec options. 243 17:46.000 --> 17:49.430 Alright, question number seven, and it's actually the last question. I think I 244 17:49.430 --> 17:52.520 said that there were eight. I thought there were eight, but there's only seven 245 17:52.520 --> 17:53.000 questions. 246 17:53.000 --> 17:57.630 So here we go. Map the following message types with either I could be one phase 247 17:57.630 --> 18:02.000 one or phase two and also identify how many messages are sent for each. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 247 17:57.630 --> 18:02.000 one or phase two and also identify how many messages are sent for each. 248 18:02.000 --> 18:06.110 So this is a question of just how well do we know I could be one as well as 249 18:06.110 --> 18:11.730 especially the difference in the phases. So the purpose of phase one is 250 18:11.730 --> 18:15.000 essentially to establish a control plane tunnel. 251 18:15.000 --> 18:18.930 This is going to allow us to perform initial communications with the remote 252 18:18.930 --> 18:22.920 router. And we have two main options here. We can do this in main mode or 253 18:22.920 --> 18:24.000 aggressive mode. 254 18:24.000 --> 18:30.380 Main mode is going to require six messages and is considered to be the more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 254 18:24.000 --> 18:30.380 Main mode is going to require six messages and is considered to be the more 255 18:30.380 --> 18:32.000 secure option. 256 18:32.000 --> 18:36.730 Aggressive mode is a whole lot faster. It only uses three messages. But because 257 18:36.730 --> 18:41.000 it only uses three, it's going to rush things a little bit. 258 18:41.000 --> 18:44.670 And so it is viewed as a little bit less secure. There's going to be some 259 18:44.670 --> 18:48.500 identities that are shared in plain text that wouldn't have been shared in 260 18:48.500 --> 18:50.000 plain text otherwise. 261 18:50.000 --> 18:54.560 So this is primarily used for scenarios where we just care about speed and we 262 18:54.560 --> 18:59.000 care about processing and tunnels are getting established and torn down 263 18:59.000 --> 19:00.000 regularly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 263 18:59.000 --> 19:00.000 regularly. 264 19:00.000 --> 19:03.520 But generally speaking, for a more secure option, we'd want to go with main 265 19:03.520 --> 19:04.000 mode. 266 19:04.000 --> 19:09.190 So phase two, phase two is all about creating the data plane tunnel, which is 267 19:09.190 --> 19:13.000 the tunnel that's going to be used for actual traffic. 268 19:13.000 --> 19:17.790 This is what's referred to as the IPsec tunnel. So our IPsec tunnel will be 269 19:17.790 --> 19:22.000 carrying our user traffic securely across the underlay. 270 19:22.000 --> 19:27.400 And as part of phase two, we're just going to use this quick mode option, which 271 19:27.400 --> 19:29.000 is three messages. 272 19:29.000 --> 19:34.000 So there's not multiple options within phase two. It's just used to distinguish WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 272 19:29.000 --> 19:34.000 So there's not multiple options within phase two. It's just used to distinguish 273 19:34.000 --> 19:38.000 these messages from the other messages that are in phase one. 274 19:38.000 --> 19:41.980 So we're either talking about a total of nine messages. If we're using main 275 19:41.980 --> 19:45.000 mode or six messages, if we're using aggressive mode. 276 19:45.000 --> 19:50.670 Now, keep in mind as well, even though our focus on this question is like V one 277 19:50.670 --> 19:55.000 , like V two is going to simplify all of this. 278 19:55.000 --> 19:59.000 So this is a single option for four messages. 279 19:59.000 --> 20:04.300 I could be too is certainly the way we want to build our IPsec tunnels these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 279 19:59.000 --> 20:04.300 I could be too is certainly the way we want to build our IPsec tunnels these 280 20:04.300 --> 20:05.000 days. 281 20:05.000 --> 20:09.110 But Cisco still expects us to understand how I could be one works because there 282 20:09.110 --> 20:12.000 's a whole lot of I could be one out in the real world. 283 20:12.000 --> 20:15.300 So let's make sure we understand how these phases break down with the purpose 284 20:15.300 --> 20:21.000 of each phases and then even how I could be one compares to I could be two.