WEBVTT 1 00:00.000 --> 00:04.960 So over the next few skills, 2 00:04.960 --> 00:09.040 we're going to be looking at Cloud On-Ramp for AWS, 3 00:09.040 --> 00:13.640 for Azure, and for Google Cloud completely separately. 4 00:13.640 --> 00:16.760 That way we can see how each one functions on its own. 5 00:16.760 --> 00:19.720 So I thought what we would do is we would start by looking at 6 00:19.720 --> 00:24.410 a completely functional environment which is connected to all three at the same 7 00:24.410 --> 00:25.000 time. 8 00:25.000 --> 00:27.720 So that's what I have set up in running right now. 9 00:27.720 --> 00:32.240 We'll also take this opportunity to look at some more detailed verification WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:27.720 --> 00:32.240 We'll also take this opportunity to look at some more detailed verification 10 00:32.240 --> 00:33.000 steps 11 00:33.000 --> 00:36.480 that we can use to make sure that all of this is functional. 12 00:36.480 --> 00:38.840 As we go through the upcoming skills, 13 00:38.840 --> 00:43.240 we're not going to look at the detailed verification in each skill. 14 00:43.240 --> 00:47.240 We'll take a look at it here and then you can apply these methods 15 00:47.240 --> 00:51.080 as you're going through each different Cloud provider individually. 16 00:51.080 --> 00:54.680 So let's go ahead and jump in to a working environment 17 00:54.680 --> 00:58.840 connected to all three major Cloud providers. 18 00:58.840 --> 01:04.880 So starting off here on the Monitor Overview page, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:58.840 --> 01:04.880 So starting off here on the Monitor Overview page, 19 01:04.880 --> 01:09.000 the first thing we want to take a look at of course is that we currently have 20 01:09.000 --> 01:11.800 our one validator, our one controller, 21 01:11.800 --> 01:14.360 and our one manager up and running, 22 01:14.360 --> 01:17.640 and we have our eight WAN edges. 23 01:17.640 --> 01:22.760 That's two that are on-prem and two each for AWS, 24 01:22.760 --> 01:26.600 Microsoft Azure, and of course, Google Cloud. 25 01:26.600 --> 01:29.160 If we look down here a little further, 26 01:29.160 --> 01:31.640 we can see the current site health. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 01:29.160 --> 01:31.640 we can see the current site health. 27 01:31.640 --> 01:36.990 And you might notice that we actually have one site here under poor performing 28 01:36.990 --> 01:37.720 sites, 29 01:37.720 --> 01:39.720 which is site 100. 30 01:39.720 --> 01:44.520 Now, the irony of that is site 100 is headquarters, 31 01:44.520 --> 01:49.560 which is actually devices that are running here at my location. 32 01:49.560 --> 01:54.520 It's actually running poorer than the devices out in the Cloud. 33 01:54.520 --> 01:58.040 And of course, if we really think about it, that makes sense. 34 01:58.040 --> 02:04.280 I don't have nearly the resources that AWS, Azure, and GCP have, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 01:58.040 --> 02:04.280 I don't have nearly the resources that AWS, Azure, and GCP have, 35 02:04.280 --> 02:08.760 which is also what we'll see here on the tunnel health side. 36 02:08.760 --> 02:14.600 Notice that half my tunnels are good and the other half are poor. 37 02:14.600 --> 02:18.760 Well, if we look at a little more detail here on these good tunnels, 38 02:18.760 --> 02:23.960 notice that they're between like Azure and AWS and so on. 39 02:23.960 --> 02:28.040 And if I switch this over to look at the poor tunnels, 40 02:28.040 --> 02:32.880 these are all the tunnels that are either going to or coming from my on-prem WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 02:28.040 --> 02:32.880 these are all the tunnels that are either going to or coming from my on-prem 41 02:32.880 --> 02:34.040 routers. 42 02:34.040 --> 02:37.880 And this, of course, is because the connection here at my location 43 02:37.880 --> 02:43.640 is nowhere near the connections that are available at the Cloud providers, 44 02:43.640 --> 02:46.520 particularly between the other Cloud providers. 45 02:46.520 --> 02:50.620 And we'll see this more when we look at the tunnels in more detail in just a 46 02:50.620 --> 02:51.400 moment. 47 02:51.400 --> 02:55.160 But first, let's go up and take a look at the monitor devices. 48 02:55.160 --> 03:00.680 So if we click up here on devices, what we're going to see here is all of our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:55.160 --> 03:00.680 So if we click up here on devices, what we're going to see here is all of our 49 03:00.680 --> 03:01.320 devices. 50 03:01.320 --> 03:04.920 We have two routers deployed in AWS. 51 03:04.920 --> 03:07.400 We have our two on-prem routers. 52 03:07.400 --> 03:10.040 Then of course, we have our three controllers. 53 03:10.040 --> 03:15.480 And if we scroll down a little bit here, we see the two routers in Azure 54 03:15.480 --> 03:18.040 and the two routers in GCP. 55 03:18.040 --> 03:22.120 Now, notice that all of these are up, reachable, and so on. 56 03:22.120 --> 03:27.080 We do have a amber health warning on the two in AWS. 57 03:27.080 --> 03:29.880 This is simply because if we scroll over a little, 58 03:29.880 --> 03:35.560 we see that the memory utilization on those two routers is over 80%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 58 03:29.880 --> 03:35.560 we see that the memory utilization on those two routers is over 80%. 59 03:35.560 --> 03:39.160 That's the threshold to go to amber. 60 03:39.160 --> 03:43.960 And this is simply because I chose the smallest supported routers 61 03:43.960 --> 03:48.200 that Cisco will deploy using Cloud On-Ramp into AWS. 62 03:48.200 --> 03:52.620 Of course, in a production environment, I wouldn't have used the smaller of the 63 03:52.620 --> 03:53.240 routers, 64 03:53.240 --> 03:56.280 but they are getting close on their memory utilization. 65 03:56.280 --> 04:00.600 So now let's scroll back up and now we'll go to tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 03:56.280 --> 04:00.600 So now let's scroll back up and now we'll go to tunnels. 66 04:00.600 --> 04:04.120 Now, if we scroll down here so we can see more of these on the screen, 67 04:04.120 --> 04:09.080 notice that the health of all of these is a red X. 68 04:09.080 --> 04:13.240 Well, if we click on the health up here, the little I for information, 69 04:13.960 --> 04:19.690 we'll see that the health on these are poor because the quality of experience 70 04:19.690 --> 04:21.400 is less than five. 71 04:21.400 --> 04:27.510 If we look at the QOE column, we can see that all of these are in fact below 72 04:27.510 --> 04:28.200 five, 73 04:28.200 --> 04:33.080 and we can see why if we look over here, look at this average latency. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 04:28.200 --> 04:33.080 and we can see why if we look over here, look at this average latency. 74 04:33.080 --> 04:39.740 It's up around 400 milliseconds and the average jitter is right around 100 75 04:39.740 --> 04:41.160 milliseconds. 76 04:41.880 --> 04:47.240 Now, truth be told here, my internet connection at this location is not that 77 04:47.240 --> 04:47.560 bad. 78 04:47.560 --> 04:49.480 I have a good internet connection. 79 04:49.480 --> 04:54.840 I'm really not sure why this latency and jitter is so high. 80 04:54.840 --> 04:57.640 I've done a little bit of troubleshooting to try to figure it out, 81 04:57.640 --> 05:00.520 not a lot because everything is functional. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 04:57.640 --> 05:00.520 not a lot because everything is functional. 82 05:00.520 --> 05:03.800 It just doesn't look nice that our health isn't very good. 83 05:03.800 --> 05:07.480 But of course, it doesn't really matter for this example. 84 05:07.480 --> 05:10.520 Of course, if you have business quality internet, 85 05:10.520 --> 05:12.760 you probably won't have this problem. 86 05:12.760 --> 05:14.760 This is just my home internet connection. 87 05:14.760 --> 05:18.680 So again, even though all of their health is poor, 88 05:18.680 --> 05:23.000 they are still functional, up and working, which is really all we need. 89 05:23.000 --> 05:27.960 So next, let's scroll up and let's take a look at multicloud. 90 05:27.960 --> 05:32.600 So here are the big things we want to look at on the multicloud page. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 05:27.960 --> 05:32.600 So here are the big things we want to look at on the multicloud page. 91 05:32.600 --> 05:38.520 First for AWS, we see that we have our cloud gateway is currently up. 92 05:38.520 --> 05:41.320 We have our two cloud edges that are currently up. 93 05:41.320 --> 05:44.520 And we have three connected sites. 94 05:44.520 --> 05:51.160 That involves four tunnels, one connected tag, one connected host VPC, 95 05:51.160 --> 05:56.120 which is where our server is living, and one connected VPC connection. 96 05:56.120 --> 05:59.960 For Google platform, notice that this is very similar. 97 05:59.960 --> 06:05.080 What changes a bit here though, is that it uses fewer tunnels, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 97 05:59.960 --> 06:05.080 What changes a bit here though, is that it uses fewer tunnels, 98 06:05.080 --> 06:10.280 because it actually uses parallel cloud edges rather than sort of a mesh. 99 06:10.280 --> 06:13.400 So that means we have half as many tunnels, 100 06:13.400 --> 06:18.280 but we still have the connected tags and the connected host VPCs 101 06:18.280 --> 06:20.280 and connected VPC connections. 102 06:20.280 --> 06:25.640 Microsoft Azure, of course, also lists this just a little bit different. 103 06:25.640 --> 06:27.800 Of course, our cloud gateways is the same. 104 06:27.800 --> 06:29.480 Our cloud edge is the same. 105 06:29.480 --> 06:32.040 The connected sites is also the same. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 06:29.480 --> 06:32.040 The connected sites is also the same. 106 06:32.520 --> 06:37.160 But then it talks about your connected tags, your connected host VNats, 107 06:37.160 --> 06:39.880 and your connected VPN connections. 108 06:39.880 --> 06:43.080 So it's a little bit different here, how it words it. 109 06:43.080 --> 06:46.840 We of course just call them VNats instead of VPCs, 110 06:46.840 --> 06:49.400 and it doesn't list the number of tunnels here. 111 06:49.400 --> 06:54.120 But overall, we have three green lines under each one, 112 06:54.120 --> 06:58.120 indicating that everything is currently up, working, and healthy. 113 06:58.120 --> 07:01.320 You can also sort of get a look at what's going on as well, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 06:58.120 --> 07:01.320 You can also sort of get a look at what's going on as well, 114 07:01.880 --> 07:05.000 not under monitor, but also under configuration. 115 07:05.000 --> 07:08.280 So if we come back over here to configuration, 116 07:08.280 --> 07:11.080 and we go to cloud on ramp for multi cloud, 117 07:11.080 --> 07:15.400 we'll collapse our side menu also to give us a little more space here 118 07:15.400 --> 07:16.440 to see what's going on. 119 07:16.440 --> 07:21.880 But we see here sort of a summary under this network snapshot section, 120 07:21.880 --> 07:25.640 where it's giving us the same sort of information we just saw, of course. 121 07:25.640 --> 07:27.960 But we can see it on this page as well, 122 07:27.960 --> 07:31.560 that we have connections for AWS, for Azure, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 07:27.960 --> 07:31.560 that we have connections for AWS, for Azure, 123 07:31.880 --> 07:33.960 and also for Google Cloud. 124 07:33.960 --> 07:39.070 Down here at the bottom, it also gives us a nice summary of the different 125 07:39.070 --> 07:39.800 clouds, 126 07:39.800 --> 07:43.160 the regions, what account it's connected with, 127 07:43.160 --> 07:45.240 the different cloud gateway names, 128 07:45.240 --> 07:51.960 their current health devices, and the tunnel to cloud when core networks. 129 07:51.960 --> 07:58.390 We also see how many VPNs, tags, and host private networks are available on 130 07:58.390 --> 07:59.480 each one. 131 07:59.480 --> 08:05.560 I simply have one network behind each of these in each cloud environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 07:59.480 --> 08:05.560 I simply have one network behind each of these in each cloud environment. 132 08:05.560 --> 08:09.880 We'll be verifying that part from the command line in the next video. 133 08:09.880 --> 08:16.680 So in this video, our goal was to come in here to the graphical interface, 134 08:16.680 --> 08:20.520 specifically SD-WAN manager or V-Manage, 135 08:20.520 --> 08:25.880 and use this tool to verify that all of our connections to the various cloud 136 08:25.880 --> 08:27.000 providers 137 08:27.000 --> 08:31.480 are up and functional. And even though our tunnels aren't exactly showing the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 08:27.000 --> 08:31.480 are up and functional. And even though our tunnels aren't exactly showing the 138 08:31.480 --> 08:32.440 most healthy, 139 08:32.440 --> 08:37.480 in fact, we have poor health, they are in fact up and they are in fact working, 140 08:37.480 --> 08:41.240 which at least for a lab environment is all we really need. 141 08:41.240 --> 08:45.250 Now, of course, for production, we might want to have a little bit of a better 142 08:45.250 --> 08:46.440 internet connection 143 08:46.440 --> 08:48.600 for this to function a little bit better. 144 08:48.600 --> 08:53.720 Next, let's jump into the command line and do some verification there 145 08:53.720 --> 08:57.480 to make sure that everything's working from the command line perspective.