WEBVTT

1
00:00.000 --> 00:08.030
So for our final step, let's jump in and make sure that everything is working

2
00:08.030 --> 00:09.000
as designed.

3
00:09.000 --> 00:15.560
Of course, the main end goal is to have on-prem workstation one being able to

4
00:15.560 --> 00:22.000
communicate to AWS workstation one that we deployed earlier in this skill.

5
00:22.000 --> 00:29.000
So let's jump in. We'll start on the command line on AWS R1.

6
00:29.000 --> 00:32.000
So let's start by verifying our control connections.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

6
00:29.000 --> 00:32.000
So let's start by verifying our control connections.

7
00:32.000 --> 00:36.000
We'll just do a show SD-WAN control connections. We'll hit enter.

8
00:36.000 --> 00:40.280
As we've seen before, this is a very wide command. It's not going to fit here

9
00:40.280 --> 00:41.000
very well.

10
00:41.000 --> 00:44.000
So let's zoom out here just a little bit.

11
00:44.000 --> 00:48.000
So again, that unfortunately makes it very, very difficult to read.

12
00:48.000 --> 00:52.000
However, again, on a local system, you should be able to read this.

13
00:52.000 --> 00:59.070
Again, it's showing us that we have a DTL connection with vSmart, VBond, and V

14
00:59.070 --> 01:00.000
Manage.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

15
01:00.000 --> 01:03.000
So all of our control connections are up.

16
01:03.000 --> 01:08.000
We can also verify our SD-WAN OMP peers.

17
01:08.000 --> 01:12.000
That one's not quite as wide. We can zoom back in a little bit on that one.

18
01:12.000 --> 01:15.000
So here we can read this a little easier.

19
01:15.000 --> 01:19.800
And what we see is that we only have one OMP peer and that is to the vSmart

20
01:19.800 --> 01:21.000
controller.

21
01:21.000 --> 01:25.670
That's exactly how it should be because the vSmart controller is effectively

22
01:25.670 --> 01:28.000
acting like a BGP route reflector.

23
01:28.000 --> 01:32.560
It, of course, collects all the information and then disseminates that back out
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
01:28.000 --> 01:32.560
It, of course, collects all the information and then disseminates that back out

24
01:32.560 --> 01:34.000
to the other devices.

25
01:34.000 --> 01:38.000
So we should only have an OMP peer to our smart controllers.

26
01:38.000 --> 01:42.000
And of course, in my environment, I only have one controller.

27
01:42.000 --> 01:45.000
You can also do a show SD-WAN OMP route.

28
01:45.000 --> 01:49.000
It starts by showing you a legend so we can translate the table below.

29
01:49.000 --> 01:51.000
And then we see the table below.

30
01:51.000 --> 01:53.000
Once again, it's a little wide.

31
01:53.000 --> 01:58.000
Again, if we zoom all the way out, we can see the routes that we're getting.

32
01:58.000 --> 02:04.400
Of course, the most important one here is the 10.10.10.0/24 being learned from
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:58.000 --> 02:04.400
Of course, the most important one here is the 10.10.10.0/24 being learned from

33
02:04.400 --> 02:07.000
both of our on-prem routers.

34
02:07.000 --> 02:10.000
So that is the on-prem network.

35
02:10.000 --> 02:15.000
We can also verify that it's created the VRF if we do a show VRF.

36
02:15.000 --> 02:22.040
We see here that we have VRF 10 for VPN 10 and that interface gigabit 2 is in

37
02:22.040 --> 02:25.000
fact in that VRF as it should be.

38
02:25.000 --> 02:31.380
And if we do a show IP route for VRF 10, we see here that we have this M den
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
02:25.000 --> 02:31.380
And if we do a show IP route for VRF 10, we see here that we have this M den

39
02:31.380 --> 02:39.000
oted route for 10.10.10.0/24 indicating that it was learned through OMP.

40
02:39.000 --> 02:43.000
So that means that we are in fact learning the route from the other side.

41
02:43.000 --> 02:48.000
So if all of our routing is good, then we can go ahead and test our ping.

42
02:48.000 --> 02:52.310
So let's go over to our workstation one console, which is the on-prem work

43
02:52.310 --> 02:53.000
station.

44
02:53.000 --> 03:01.000
So let's see if we can ping our 10.20.10.100, which is the workstation in AWS.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
02:53.000 --> 03:01.000
So let's see if we can ping our 10.20.10.100, which is the workstation in AWS.

45
03:01.000 --> 03:05.270
What we're going to see here is this is not going to work because if we

46
03:05.270 --> 03:11.000
actually connected to that workstation in AWS, which we can do,

47
03:11.000 --> 03:14.000
this is AWS workstation one.

48
03:14.000 --> 03:21.440
If we do a route minus N, we'll see that its default gateway is pointing to 10.

49
03:21.440 --> 03:28.000
20.10.1 when it needs to be pointing to 10.20.10.254.

50
03:28.000 --> 03:34.000
In order to fix this, we're going to have to update our routing in AWS.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
03:28.000 --> 03:34.000
In order to fix this, we're going to have to update our routing in AWS.

51
03:34.000 --> 03:40.510
Now, the unfortunate thing is we can either update AWS or we can update right

52
03:40.510 --> 03:44.000
here just by doing a manual static route here on Linux.

53
03:44.000 --> 03:49.170
Well, we don't really want to change every single workstation or server or

54
03:49.170 --> 03:50.000
client.

55
03:50.000 --> 03:53.000
So it's best to make the change in AWS.

56
03:53.000 --> 03:57.070
The only downside is it is going to cut off our direct access here to AWS work

57
03:57.070 --> 03:58.000
station one.

58
03:58.000 --> 04:02.130
So if it doesn't work, we would have to switch it back in AWS to be able to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
03:58.000 --> 04:02.130
So if it doesn't work, we would have to switch it back in AWS to be able to

59
04:02.130 --> 04:04.000
access this console again.

60
04:04.000 --> 04:06.000
But let's jump over to AWS.

61
04:06.000 --> 04:10.000
Here in AWS, we'll come over here to VPC.

62
04:10.000 --> 04:12.000
We'll go to route tables.

63
04:12.000 --> 04:18.000
And specifically for the subnet 10 route table, we'll simply click on it.

64
04:18.000 --> 04:20.000
We'll edit the routes.

65
04:20.000 --> 04:24.150
So what we want to do is for our default route, we want to change this from

66
04:24.150 --> 04:27.000
Internet gateway to a network interface.

67
04:27.000 --> 04:32.000
And then on our drop down, we want to choose the inside interface or gigabit to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
04:27.000 --> 04:32.000
And then on our drop down, we want to choose the inside interface or gigabit to

68
04:32.000 --> 04:35.000
of AWS R1.

69
04:35.000 --> 04:37.000
Well, let's save changes.

70
04:37.000 --> 04:39.000
It says it's been successful.

71
04:39.000 --> 04:43.000
So now let's go back over to our command line and verify this.

72
04:43.000 --> 04:48.380
Now, our first indicator that it's probably worked is I've already been cut off

73
04:48.380 --> 04:50.000
of our jump box here.

74
04:50.000 --> 04:53.000
In fact, we can see here it just timed out.

75
04:53.000 --> 04:56.000
So let's jump over to our workstation console.

76
04:56.000 --> 04:59.000
And we see that our ping is still not working.

77
04:59.000 --> 05:03.180
And this is one of the things we have to look at when it comes to troubles
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:59.000 --> 05:03.180
And this is one of the things we have to look at when it comes to troubles

78
05:03.180 --> 05:04.000
hooting.

79
05:04.000 --> 05:09.000
There's a very, very fundamental piece that we've missed in our deployment.

80
05:09.000 --> 05:14.000
This is critical in order for the 8000 V to work.

81
05:14.000 --> 05:20.410
AWS will not let a device function as an IP forwarder because of a built in

82
05:20.410 --> 05:21.000
security feature,

83
05:21.000 --> 05:26.000
which monitors source and destination addresses on interfaces.

84
05:26.000 --> 05:29.000
So let's go back over to AWS.

85
05:29.000 --> 05:32.000
Here we need to go back to EC2.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
05:29.000 --> 05:32.000
Here we need to go back to EC2.

86
05:32.000 --> 05:35.000
We need to go to our network interfaces.

87
05:35.000 --> 05:38.000
And it won't let you do two at the same time.

88
05:38.000 --> 05:42.780
Unfortunately, we have to do one at a time, but let's start with our gigabit

89
05:42.780 --> 05:44.000
one.

90
05:44.000 --> 05:49.000
Under actions, we need to go in to change source destination check.

91
05:49.000 --> 05:52.000
And we need to turn this off.

92
05:52.000 --> 05:57.480
The device can't act as an IP forwarder with these enabled because they'll only

93
05:57.480 --> 06:00.000
accept packets destined for that interface,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
06:00.000 --> 06:02.000
or at least for that subnet.

95
06:02.000 --> 06:07.000
So we need to turn this off for both of the interfaces.

96
06:07.000 --> 06:11.000
Once that's done, let's jump back over to our command line.

97
06:11.000 --> 06:22.870
So as we can see, this is working as designed. So we now have VPN 10 up between

98
06:22.870 --> 06:24.000
on-prem and site 20, which is AWS.

99
06:24.000 --> 06:31.000
So in this video, we simply verified our control connections from AWS R1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
06:24.000 --> 06:31.000
So in this video, we simply verified our control connections from AWS R1.

100
06:31.000 --> 06:34.000
We verified the routing. We verified our VRF.

101
06:34.000 --> 06:39.120
And then we verified that we have end-to-end reachability from on-prem work

102
06:39.120 --> 06:46.000
station one all the way out to AWS workstation one through VPN 10.

103
06:46.000 --> 06:51.750
So that concludes everything that we need to accomplish in this skill, except

104
06:51.750 --> 06:53.000
for the challenge.

105
06:53.000 --> 06:56.000
So go ahead and attack that challenge.

106
06:56.000 --> 07:01.560
You're simply going to be deploying a second router into AWS and making sure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
06:56.000 --> 07:01.560
You're simply going to be deploying a second router into AWS and making sure

107
07:01.560 --> 07:05.000
that the routing is working as we want it to.

108
07:05.000 --> 07:10.000
So good luck, and I'll see you in the solution video on the other side.