WEBVTT

1
00:00.000 --> 00:10.960
So the next thing that we want to configure is our IGP between AWS R1 and AWS R

2
00:10.960 --> 00:12.040
2.

3
00:12.040 --> 00:16.200
Now right now we're using OSPF as our IGP.

4
00:16.200 --> 00:23.320
Technically Cisco says that OSPF is not supported in the AWS VPC.

5
00:23.320 --> 00:27.730
So I'm not exactly sure what response you would get if you tried to contact

6
00:27.730 --> 00:29.080
Cisco support

7
00:29.080 --> 00:30.680
after setting this up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

7
00:29.080 --> 00:30.680
after setting this up.

8
00:30.680 --> 00:36.060
However, we're about to find out that we actually can run OSPF and several

9
00:36.060 --> 00:37.880
other IGP's.

10
00:37.880 --> 00:42.680
It's just that the VPC doesn't support multicast.

11
00:42.680 --> 00:45.840
So we're not exactly going to be able to run it in what would be considered the

12
00:45.840 --> 00:46.480
traditional

13
00:46.480 --> 00:47.480
way.

14
00:47.480 --> 00:50.780
And that is using multicast to find neighbors.

15
00:50.780 --> 00:53.680
We're going to have to run this over unicast.

16
00:53.680 --> 00:59.720
However, we've done that with OSPF for decades for various reasons.

17
00:59.720 --> 01:03.790
So let's go ahead and jump in and see how we need to configure our routing in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:59.720 --> 01:03.790
So let's go ahead and jump in and see how we need to configure our routing in

18
01:03.790 --> 01:04.960
the AWS

19
01:04.960 --> 01:11.040
VPC between our two catalyst eight thousand V's.

20
01:11.040 --> 01:14.520
So we'll begin here on AWS R1.

21
01:14.520 --> 01:18.360
Let's do a show IP OSPF interface brief.

22
01:18.360 --> 01:23.640
And what we're looking for here specifically is the gigabit to interface.

23
01:23.640 --> 01:30.440
Remember that that's the land side or in this case the subnet 10 side of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
01:23.640 --> 01:30.440
Remember that that's the land side or in this case the subnet 10 side of the

24
01:30.440 --> 01:31.720
AWS routers.

25
01:31.720 --> 01:35.880
This is where we would be looking to have that OSPF neighborship.

26
01:35.880 --> 01:41.900
However, notice that router one here has elected itself as the DR, but under

27
01:41.900 --> 01:43.000
neighbors,

28
01:43.000 --> 01:45.440
it has zero.

29
01:45.440 --> 01:51.470
If we do a show IP OSPF neighbor, again, it only has that neighborship across

30
01:51.470 --> 01:52.360
the tunnel.

31
01:52.360 --> 01:54.800
No local neighborship.

32
01:54.800 --> 01:59.050
And therefore, if we do a show IP route OSPF, we see that the only way it knows

33
01:59.050 --> 01:59.560
to get

34
01:59.560 --> 02:07.920
to anything is across tunnel one, including ironically, AWS to lose back.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:59.560 --> 02:07.920
to anything is across tunnel one, including ironically, AWS to lose back.

35
02:07.920 --> 02:11.890
So it would go all the way back to headquarters to get to the router that's

36
02:11.890 --> 02:12.600
sitting right

37
02:12.600 --> 02:17.960
next to it in AWS because it doesn't know any different.

38
02:17.960 --> 02:22.240
We have the exact same problem on AWS R2.

39
02:22.240 --> 02:25.000
We do a show IP OSPF interface brief.

40
02:25.000 --> 02:29.640
We do in fact have OSPF enabled on the gigabit to interface.

41
02:29.640 --> 02:33.700
But since these two devices aren't talking to each other, well, it's also
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
02:29.640 --> 02:33.700
But since these two devices aren't talking to each other, well, it's also

42
02:33.700 --> 02:34.600
elected itself

43
02:34.600 --> 02:38.120
as the DR and it has no neighbors.

44
02:38.120 --> 02:43.040
If we do our show IP OSPF neighbor, again, just the neighborship across the

45
02:43.040 --> 02:43.880
tunnel.

46
02:43.880 --> 02:49.520
And on the show IP route OSPF, once again, just the routes across the tunnel,

47
02:49.520 --> 02:50.160
including

48
02:50.160 --> 02:53.880
AWS R1's loopback.

49
02:53.880 --> 02:56.800
So this, of course, is what we want to fix.

50
02:56.800 --> 03:01.260
In order to fix this, we need to get a neighborship up across gigabit to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:56.800 --> 03:01.260
In order to fix this, we need to get a neighborship up across gigabit to

51
03:01.260 --> 03:04.160
between AWS R1 and AWS

52
03:04.160 --> 03:05.160
R2.

53
03:05.160 --> 03:09.440
However, the VPC does not support multicast.

54
03:09.440 --> 03:12.400
So we're going to have to do this unicast.

55
03:12.400 --> 03:16.570
Let's go ahead and configure unicast for the interfaces and then configure our

56
03:16.570 --> 03:17.160
neighbor

57
03:17.160 --> 03:19.240
statements in OSPF.

58
03:19.240 --> 03:23.280
So we can start on router two since we're already here.

59
03:23.280 --> 03:28.850
We simply go into configuration mode into interface gigabit two and we're going

60
03:28.850 --> 03:29.120
to

61
03:29.120 --> 03:35.280
change the IP OSPF network type to be non-broadcast.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
03:29.120 --> 03:35.280
change the IP OSPF network type to be non-broadcast.

62
03:35.280 --> 03:41.120
Now non-broadcast changes the default hello timers and they're a bit slow.

63
03:41.120 --> 03:46.200
So we'll go ahead and set these back to the defaults for a broadcast network.

64
03:46.200 --> 03:50.400
So we'll just say IPO SPF hello interval and we'll set it back to 10.

65
03:50.400 --> 03:52.960
We could of course set these timers faster.

66
03:52.960 --> 03:57.260
We probably would in production so that the neighborships respond faster to

67
03:57.260 --> 03:58.080
failures,

68
03:58.080 --> 04:00.880
but being a lab, this would be fine.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:58.080 --> 04:00.880
but being a lab, this would be fine.

69
04:00.880 --> 04:05.940
The other thing we need to do is go into our router OSPF process and then

70
04:05.940 --> 04:07.960
specify a neighbor.

71
04:07.960 --> 04:11.880
So we're simply going to specify the unicast address of the neighbor.

72
04:11.880 --> 04:16.080
So it's 10 dot 20 dot 10 dot 254.

73
04:16.080 --> 04:19.560
That would be router one with that configured.

74
04:19.560 --> 04:21.840
Let's go back over to router one.

75
04:21.840 --> 04:23.960
This being an almost identical configuration.

76
04:23.960 --> 04:25.640
We'll just paste it in.

77
04:25.640 --> 04:29.880
Of course, the neighbor statement is going to be for router two.

78
04:29.880 --> 04:33.600
Now that that's done, let's do a show IP OSPF neighbor.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
04:29.880 --> 04:33.600
Now that that's done, let's do a show IP OSPF neighbor.

79
04:33.600 --> 04:36.400
This is still an attempt and druther.

80
04:36.400 --> 04:41.200
This is simply because the old previous connection it was attempting is still

81
04:41.200 --> 04:42.160
timing out.

82
04:42.160 --> 04:46.000
We'll give this just a few moments and then it should come up.

83
04:46.000 --> 04:47.480
So we gave it just a few moments.

84
04:47.480 --> 04:49.000
Let's check again.

85
04:49.000 --> 04:51.440
And we can see now the state is full.

86
04:51.440 --> 04:54.040
It's up across the gigabit to interface.

87
04:54.040 --> 05:00.750
So now if we do our show IP route OSPF now some of our routes are going across
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:54.040 --> 05:00.750
So now if we do our show IP route OSPF now some of our routes are going across

88
05:00.750 --> 05:01.480
the tunnel

89
05:01.480 --> 05:02.480
as they should.

90
05:02.480 --> 05:06.730
We're going to be the routes from headquarters and we're learning about some

91
05:06.730 --> 05:07.680
routes locally

92
05:07.680 --> 05:11.880
through gigabit to from AWS R2.

93
05:11.880 --> 05:14.960
So now this is working successfully.

94
05:14.960 --> 05:19.850
So remember the importance of this is that if there was a failure of either

95
05:19.850 --> 05:20.640
tunnel one

96
05:20.640 --> 05:26.620
or tunnel two, router one now knows that it could go through router two and

97
05:26.620 --> 05:27.880
vice versa.

98
05:27.880 --> 05:30.560
Router two could go through router one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
05:27.880 --> 05:30.560
Router two could go through router one.

99
05:30.560 --> 05:35.400
So now we have redundancy for our tunnels and the routers themselves.

100
05:35.400 --> 05:40.800
However, we still don't have redundancy for the end devices.

101
05:40.800 --> 05:46.350
So possibly our servers running in AWS and our clients running at headquarters

102
05:46.350 --> 05:46.920
that aren't

103
05:46.920 --> 05:49.840
actually running an IGP.

104
05:49.840 --> 05:53.280
So we still need to provide first hop redundancy.

105
05:53.280 --> 05:57.720
Next, let's take a look at doing that the traditional way and we'll see that

106
05:57.720 --> 05:58.480
that works

107
05:58.480 --> 06:03.240
in headquarters but not quite so well in the AWS environment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:58.480 --> 06:03.240
in headquarters but not quite so well in the AWS environment.

108
06:03.240 --> 06:11.800
[BLANK_AUDIO]