WEBVTT

1
00:00.000 --> 00:03.590
Now, there's one other part that we need to talk about, which goes a little bit

2
00:03.590 --> 00:04.000
deeper

3
00:04.000 --> 00:07.160
into how FHRP's work.

4
00:07.160 --> 00:12.880
And that is how we handle the Layer 2 Failover aspect of FHRP's.

5
00:12.880 --> 00:15.600
The Layer 3 Failover feels fairly straightforward.

6
00:15.600 --> 00:18.000
I have two devices.

7
00:18.000 --> 00:20.120
They are sharing this virtual IP address.

8
00:20.120 --> 00:23.320
Let's say it's that.254 that we're sharing.

9
00:23.320 --> 00:25.080
.252 on the left.

10
00:25.080 --> 00:27.680
.253 on the right.

11
00:27.680 --> 00:32.780
And we know that our endpoints down here are going to have that default gateway
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:27.680 --> 00:32.780
And we know that our endpoints down here are going to have that default gateway

12
00:32.780 --> 00:34.640
of .254.

13
00:34.640 --> 00:36.440
We want to point them to the virtual IP address.

14
00:36.440 --> 00:38.720
So that's the Layer 3 aspect of it.

15
00:38.720 --> 00:42.450
And again, we know that if this device goes down, then this device takes over

16
00:42.450 --> 00:43.520
or vice-versa,

17
00:43.520 --> 00:47.300
whichever one is active, it doesn't matter, which one we decide should be

18
00:47.300 --> 00:48.080
active, but

19
00:48.080 --> 00:50.160
we do have control over that.

20
00:50.160 --> 00:54.120
So we say that the one on the left is the active node.

21
00:54.120 --> 00:59.360
And if it fails, then the node on the right will answer to the .254.

22
00:59.360 --> 01:02.920
But now we need to think about this Layer 2 Failover concept.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:59.360 --> 01:02.920
But now we need to think about this Layer 2 Failover concept.

23
01:02.920 --> 01:04.440
So think about this.

24
01:04.440 --> 01:08.360
We have an upstream switch from this device.

25
01:08.360 --> 01:11.200
And then we've got a little bit of a Layer 2 network here.

26
01:11.200 --> 01:13.480
So we've got a switch coming over here.

27
01:13.480 --> 01:15.000
That comes up to the router on the left.

28
01:15.000 --> 01:16.840
We've got a switch over here.

29
01:16.840 --> 01:18.840
Going to the router on the right.

30
01:18.840 --> 01:22.720
And on steady state operation, everything is working just fine.

31
01:22.720 --> 01:26.360
But then what happens when we do have a failover?

32
01:26.360 --> 01:31.640
So now let's say we have this failover and we're now trying to run off of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:26.360 --> 01:31.640
So now let's say we have this failover and we're now trying to run off of the

33
01:31.640 --> 01:32.440
router on

34
01:32.440 --> 01:33.520
the right.

35
01:33.520 --> 01:38.990
In this scenario, this entire network is going to go down unless we address

36
01:38.990 --> 01:40.680
Layer 2 Failover.

37
01:40.680 --> 01:45.700
Because if we think about it, remember, this virtual IP address is also going

38
01:45.700 --> 01:46.240
to have

39
01:46.240 --> 01:48.520
a virtual MAC address.

40
01:48.520 --> 01:52.120
Where does the network think the virtual MAC address lives?

41
01:52.120 --> 01:57.180
If we look at the cam table for this switch, we're going to point out this

42
01:57.180 --> 01:58.560
interface to say,

43
01:58.560 --> 02:02.480
hey, that virtual MAC address lives out this way.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:58.560 --> 02:02.480
hey, that virtual MAC address lives out this way.

44
02:02.480 --> 02:06.240
And for that matter, even this switch on the right is going to for now.

45
02:06.240 --> 02:10.150
If we've got a host over here trying to get to its gateway, we might send a

46
02:10.150 --> 02:10.760
packet to

47
02:10.760 --> 02:11.760
this switch.

48
02:11.760 --> 02:13.560
And it's going to follow these arrows.

49
02:13.560 --> 02:17.160
It's going to go down here to this switch and bounce up here to the switch on

50
02:17.160 --> 02:18.720
the left.

51
02:18.720 --> 02:23.590
Because the virtual MAC addresses, the virtual MAC address, has been inserted

52
02:23.590 --> 02:24.280
into the cam

53
02:24.280 --> 02:27.560
tables of all of these Layer 2 switches.

54
02:27.560 --> 02:33.960
So we need to update the cam tables as part of this design.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:27.560 --> 02:33.960
So we need to update the cam tables as part of this design.

55
02:33.960 --> 02:37.980
Because otherwise we're going to failover and this device over here is actually

56
02:37.980 --> 02:38.480
running

57
02:38.480 --> 02:41.080
the .254 IP address.

58
02:41.080 --> 02:44.650
And for that matter, it's running the virtual MAC address, but nobody knows

59
02:44.650 --> 02:46.160
where it is.

60
02:46.160 --> 02:50.510
And so how do we update the Layer 2 network to let everybody know that the

61
02:50.510 --> 02:51.640
virtual MAC address

62
02:51.640 --> 02:57.520
now lives out this interface and it no longer lives out this interface?

63
02:57.520 --> 03:04.350
Well the way we do this is with a mechanism known as a gratuitous, which is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
02:57.520 --> 03:04.350
Well the way we do this is with a mechanism known as a gratuitous, which is

64
03:04.350 --> 03:06.320
often abbreviated

65
03:06.320 --> 03:10.360
as a garp, which I think is a really funny acronym.

66
03:10.360 --> 03:16.040
But the garp is an ARP packet that is sent gratuitously.

67
03:16.040 --> 03:18.320
Now gratuitous is kind of a funny English word.

68
03:18.320 --> 03:24.480
It basically means excessive or in this case it's going to mean unrequested.

69
03:24.480 --> 03:29.690
Because when steady state operation, remember I sent an ARP request and that AR

70
03:29.690 --> 03:30.440
P request
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:29.690 --> 03:30.440
P request

71
03:30.440 --> 03:35.320
was a broadcast, it eventually landed up here on the router when it was alive

72
03:35.320 --> 03:35.880
and it sent

73
03:35.880 --> 03:39.360
that ARP request.

74
03:39.360 --> 03:44.500
And that ARP request is why we know in all these cam tables where that MAC

75
03:44.500 --> 03:46.000
address lives.

76
03:46.000 --> 03:50.000
Because when we do the ARP from this side, we're going to get the ARP response,

77
03:50.000 --> 03:50.320
everybody

78
03:50.320 --> 03:52.840
knows where it lives.

79
03:52.840 --> 03:55.840
So which is perform that flood and learn type of behavior.

80
03:55.840 --> 04:00.400
Well gratuitous ARP says, "Hey, nobody is asking."
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:55.840 --> 04:00.400
Well gratuitous ARP says, "Hey, nobody is asking."

81
04:00.400 --> 04:09.440
Nobody asked for this, but I'm going to send an ARP response.

82
04:09.440 --> 04:13.500
I'm going to make sure that it's broadcast and flooded throughout the

83
04:13.500 --> 04:14.520
environment.

84
04:14.520 --> 04:19.800
So I send that ARP or that garp once I fail over.

85
04:19.800 --> 04:25.200
So I recognize first of all that the active is down, then I decide I am the

86
04:25.200 --> 04:26.080
active and

87
04:26.080 --> 04:30.040
next I send a gratuitous ARP out to this switch.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:26.080 --> 04:30.040
next I send a gratuitous ARP out to this switch.

88
04:30.040 --> 04:34.790
Well the cam table on this first switch is immediately going to recognize that

89
04:34.790 --> 04:35.440
the virtual

90
04:35.440 --> 04:36.840
MAC address is moved.

91
04:36.840 --> 04:40.390
I used to think it was out this interface, now I realize it's out this

92
04:40.390 --> 04:41.240
interface.

93
04:41.240 --> 04:44.660
So fortunately layer two mechanisms allow us to update the cam table

94
04:44.660 --> 04:45.560
immediately.

95
04:45.560 --> 04:50.000
And so now I know that the virtual MAC address is out the correct interface.

96
04:50.000 --> 04:53.140
And because this gets broadcasted throughout the entire environment, I send it

97
04:53.140 --> 04:53.520
down to

98
04:53.520 --> 04:54.680
this switch.

99
04:54.680 --> 04:59.120
Now it knows in its cam table that the virtual MAC address lives out the

100
04:59.120 --> 05:00.680
correct interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
04:59.120 --> 05:00.680
correct interface.

101
05:00.680 --> 05:04.620
So fortunately this is nothing we have to configure, but it is an important

102
05:04.620 --> 05:05.360
mechanism,

103
05:05.360 --> 05:09.740
an important part of the FHRP process that a gratuitous ARP ends up getting

104
05:09.740 --> 05:10.760
sent out

105
05:10.760 --> 05:13.320
in order to update the layer two network.

106
05:13.320 --> 05:18.460
So we don't just rely on layer three being updating or being updated and yet

107
05:18.460 --> 05:19.200
the layer two

108
05:19.200 --> 05:20.080
network is behind.

109
05:20.080 --> 05:30.080
[BLANK_AUDIO]