WEBVTT

1
00:00.000 --> 00:05.800
So now it's finally the moment of truth.

2
00:05.800 --> 00:11.740
We need to jump in, test our configuration, make sure that our failover and

3
00:11.740 --> 00:12.840
failback both

4
00:12.840 --> 00:13.840
work.

5
00:13.840 --> 00:18.160
Now, as we go through this, one thing we will observe.

6
00:18.160 --> 00:22.120
The failover is going to happen fairly quickly.

7
00:22.120 --> 00:25.960
The failback is actually going to take a couple minutes.

8
00:25.960 --> 00:26.960
And you know what?

9
00:26.960 --> 00:28.760
That's okay.

10
00:28.760 --> 00:32.780
Because the failover has to happen quickly because it means that traffic is not
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:28.760 --> 00:32.780
Because the failover has to happen quickly because it means that traffic is not

11
00:32.780 --> 00:33.320
getting

12
00:33.320 --> 00:35.000
through our network.

13
00:35.000 --> 00:39.830
The failback just means that we want to stop using our backup tunnel and go

14
00:39.830 --> 00:40.480
back to our

15
00:40.480 --> 00:42.160
primary tunnel.

16
00:42.160 --> 00:46.470
There's no real rush on that because there's nothing wrong with using the

17
00:46.470 --> 00:47.320
secondary or

18
00:47.320 --> 00:49.000
backup tunnel.

19
00:49.000 --> 00:53.920
So the fact that the failback is going to take just a few moments, that's okay.

20
00:53.920 --> 01:00.800
So let's go ahead and jump in and make sure this is working as we've designed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:53.920 --> 01:00.800
So let's go ahead and jump in and make sure this is working as we've designed.

21
01:00.800 --> 01:07.190
So let's begin verification here on SRV1 and verify what's currently happening

22
01:07.190 --> 01:07.480
in the

23
01:07.480 --> 01:08.480
environment.

24
01:08.480 --> 01:14.640
We'll start by making sure that it can actually ping Workstation 1.

25
01:14.640 --> 01:17.040
We see here that it can.

26
01:17.040 --> 01:19.360
Let's also trace route to it.

27
01:19.360 --> 01:23.110
The most important things we want to see here is that it's actually going to

28
01:23.110 --> 01:24.880
router 1 first

29
01:24.880 --> 01:29.040
and then going across the tunnel to on-prem router 1.

30
01:29.040 --> 01:35.000
So that verifies the path going from AWS out to the headquarters.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:29.040 --> 01:35.000
So that verifies the path going from AWS out to the headquarters.

31
01:35.000 --> 01:37.360
But what about the other way?

32
01:37.360 --> 01:39.760
Let's go over to Workstation 1.

33
01:39.760 --> 01:42.160
Let's trace route the other direction.

34
01:42.160 --> 01:46.120
This will be going to 10.20.10.100.

35
01:46.120 --> 01:48.960
And what we see is going the other direction.

36
01:48.960 --> 01:56.360
It's also going to router 1 first and then going across tunnel 1 to AWS R1.

37
01:56.360 --> 02:00.880
So as of right now, it's using our primary tunnel.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:56.360 --> 02:00.880
So as of right now, it's using our primary tunnel.

38
02:00.880 --> 02:05.480
We can also verify HSRP on the on-prem routers.

39
02:05.480 --> 02:07.440
Let's go to on-prem router 1.

40
02:07.440 --> 02:09.720
We'll just do a showstand.

41
02:09.720 --> 02:15.300
We see that router 1 is currently active and looking at router 2, router 2 is

42
02:15.300 --> 02:16.120
currently

43
02:16.120 --> 02:17.840
standby.

44
02:17.840 --> 02:22.960
And finally, let's look at the route table in AWS.

45
02:22.960 --> 02:27.980
So looking here at the route table, we see that the default route is pointing

46
02:27.980 --> 02:28.400
to the

47
02:28.400 --> 02:37.720
E&I ending in 8694, which is my router 1's gigabit 2 interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:28.400 --> 02:37.720
E&I ending in 8694, which is my router 1's gigabit 2 interface.

48
02:37.720 --> 02:43.280
So this is the value that we'll be looking to change when we do our failover.

49
02:43.280 --> 02:45.360
So let's test that failover.

50
02:45.360 --> 02:50.760
But while we do, let's have a ping running on both of our devices.

51
02:50.760 --> 02:54.900
So on the server, we'll just start our ping and we'll do the same thing on our

52
02:54.900 --> 02:55.920
workstation.

53
02:55.920 --> 03:01.080
So now that those are running, let's just shut down router 1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:55.920 --> 03:01.080
So now that those are running, let's just shut down router 1.

54
03:01.080 --> 03:07.110
So here in AWS, we'll go to our instances, we'll select router 1 and under the

55
03:07.110 --> 03:07.800
instant

56
03:07.800 --> 03:11.120
state, we will stop the instance.

57
03:11.120 --> 03:14.200
Now let's switch back over to our devices.

58
03:14.200 --> 03:17.160
We see here workstation 1 is still pinging.

59
03:17.160 --> 03:19.440
Let's take a look at server 1.

60
03:19.440 --> 03:22.600
We see server 1 is still pinging as well.

61
03:22.600 --> 03:26.600
But the question is, has it actually failed over?

62
03:26.600 --> 03:32.190
Let's go to on-prem router 1, do our showstand again, and we see that router 1
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:26.600 --> 03:32.190
Let's go to on-prem router 1, do our showstand again, and we see that router 1

63
03:32.190 --> 03:33.080
has failed

64
03:33.080 --> 03:34.080
over.

65
03:34.080 --> 03:35.880
It's now standby.

66
03:35.880 --> 03:39.360
That means of course the router 2 should be active.

67
03:39.360 --> 03:45.560
This is of course because the tracked object has failed on on-prem router 1.

68
03:45.560 --> 03:49.520
The question of course, has it updated our routing table?

69
03:49.520 --> 03:52.320
So let's go back over to AWS.

70
03:52.320 --> 03:57.280
And after doing a refresh here in AWS, what do we see?

71
03:57.280 --> 04:05.240
Now the target for the default route is the ENI that ends in FC60.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:57.280 --> 04:05.240
Now the target for the default route is the ENI that ends in FC60.

72
04:05.240 --> 04:11.120
In my environment, that's router 2's gigabit 2 interface.

73
04:11.120 --> 04:13.360
So what did we just see here?

74
04:13.360 --> 04:18.650
This actually failed over so quickly, we didn't even see a ping with a long

75
04:18.650 --> 04:19.440
response

76
04:19.440 --> 04:22.200
time on our devices.

77
04:22.200 --> 04:27.200
Now as I said, this will take a few minutes to actually fail back.

78
04:27.200 --> 04:31.560
We just want to ultimately make sure that it does in fact fail back.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
04:27.200 --> 04:31.560
We just want to ultimately make sure that it does in fact fail back.

79
04:31.560 --> 04:34.960
So let's go ahead and bring router 1 back online.

80
04:34.960 --> 04:39.640
We now know our fail over works, but is it going to fail back?

81
04:39.640 --> 04:42.080
So let's go back to instances.

82
04:42.080 --> 04:45.280
We see that AWS R1 is currently stopped.

83
04:45.280 --> 04:50.120
So we'll go to our instance state and we'll say start instance.

84
04:50.120 --> 04:55.800
Now of course, part of the delay is going to be AWS R1 starting back up.

85
04:55.800 --> 04:58.640
We see the instance state is still pending.

86
04:58.640 --> 05:00.920
It just switched to running.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:58.640 --> 05:00.920
It just switched to running.

87
05:00.920 --> 05:04.920
So now let's go ahead, give it a few moments, and then we'll check to make sure

88
05:04.920 --> 05:04.920
that we

89
05:04.920 --> 05:07.400
can make sure that it failed back.

90
05:07.400 --> 05:12.920
So again, this fail back will take anywhere from about three to five minutes.

91
05:12.920 --> 05:17.100
So I skipped ahead here a bit and after a refresh, we can see that our

92
05:17.100 --> 05:18.320
destination for

93
05:18.320 --> 05:26.500
the default route is now back to the E&I ending in 8694, which again is my

94
05:26.500 --> 05:28.120
router 1 gigabit

95
05:28.120 --> 05:29.920
2 interface.

96
05:29.920 --> 05:33.480
This will of course vary in your environment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
05:29.920 --> 05:33.480
This will of course vary in your environment.

97
05:33.480 --> 05:38.680
Let's go back over to our routers now on-prem router one specifically.

98
05:38.680 --> 05:42.510
If we do our show stand, we see this is back to active, which of course means

99
05:42.510 --> 05:43.240
that router

100
05:43.240 --> 05:45.640
two should be standby.

101
05:45.640 --> 05:47.480
Of course it is.

102
05:47.480 --> 05:51.200
And let's verify our path one more time.

103
05:51.200 --> 05:55.880
So over to server one, we'll do our trace again.

104
05:55.880 --> 06:00.290
We see that now this is going back to router one again as it should be and work
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
05:55.880 --> 06:00.290
We see that now this is going back to router one again as it should be and work

105
06:00.290 --> 06:02.640
station one.

106
06:02.640 --> 06:06.120
So back to going through router one.

107
06:06.120 --> 06:11.240
So now not only do we have all of our redundancy up and working, but it's also

108
06:11.240 --> 06:12.360
been verified

109
06:12.360 --> 06:16.960
and tested for both the failover and the failback.

110
06:16.960 --> 06:19.720
And that was the goal of this skill.

111
06:19.720 --> 06:24.930
So that being complete, that leaves us with nothing to do except for the

112
06:24.930 --> 06:26.080
challenge.

113
06:26.080 --> 06:26.440
Good luck.