1
00:00:00,000 --> 00:00:03,458
[AUDIO LOGO]

2
00:00:03,458 --> 00:00:07,410

3
00:00:07,410 --> 00:00:11,140
Congratulations on
completing another skill.

4
00:00:11,140 --> 00:00:15,880
Now, it's time for a review
in the form of a quiz.

5
00:00:15,880 --> 00:00:18,090
As we go through
these questions,

6
00:00:18,090 --> 00:00:22,620
be sure to pause the video after
each question to give yourself

7
00:00:22,620 --> 00:00:25,410
the opportunity to answer
the question yourself

8
00:00:25,410 --> 00:00:27,810
before we then go
over the answer.

9
00:00:27,810 --> 00:00:33,190
That said, let's jump in
with our first question.

10
00:00:33,190 --> 00:00:36,450
What is the reverse
path forwarding check?

11
00:00:36,450 --> 00:00:42,310

12
00:00:42,310 --> 00:00:44,970
So let's start just by going
down through our answers

13
00:00:44,970 --> 00:00:47,260
and seeing which
ones sound good.

14
00:00:47,260 --> 00:00:49,950
So number one says
that we're going

15
00:00:49,950 --> 00:00:55,350
to check the multicast table
to make sure that the source is

16
00:00:55,350 --> 00:00:57,340
still available.

17
00:00:57,340 --> 00:00:59,280
That doesn't really
sound correct--

18
00:00:59,280 --> 00:01:01,380
the multicast table
would really have

19
00:01:01,380 --> 00:01:04,450
no way of knowing if the
source is still available.

20
00:01:04,450 --> 00:01:06,450
So let's look at answer two--

21
00:01:06,450 --> 00:01:12,270
forwarding traffic along the
unicast path to the source.

22
00:01:12,270 --> 00:01:15,210
Well, we are sort of going
to look at the unicast path

23
00:01:15,210 --> 00:01:19,300
to the source, but we're not
going to be forwarding traffic.

24
00:01:19,300 --> 00:01:23,346
So let's go ahead
and move on to three.

25
00:01:23,346 --> 00:01:27,300
Using the unicast
routing table to verify

26
00:01:27,300 --> 00:01:29,520
the path to the source.

27
00:01:29,520 --> 00:01:33,310
Well, we are going to use
the unicast routing table.

28
00:01:33,310 --> 00:01:34,560
That's correct.

29
00:01:34,560 --> 00:01:38,520
And we are sort of doing
this as a verification

30
00:01:38,520 --> 00:01:42,820
to make sure that we're
using the correct path if we

31
00:01:42,820 --> 00:01:44,800
were going to try
to send traffic back

32
00:01:44,800 --> 00:01:46,430
towards the source.

33
00:01:46,430 --> 00:01:48,530
So that actually
sounds pretty good,

34
00:01:48,530 --> 00:01:50,980
but let's check answer four.

35
00:01:50,980 --> 00:01:55,390
Checking the path to the
receiver to ensure it's

36
00:01:55,390 --> 00:01:56,470
reachable.

37
00:01:56,470 --> 00:01:59,180
Well, this is reverse
path forwarding,

38
00:01:59,180 --> 00:02:02,320
so it's not going to have
anything to do with the path

39
00:02:02,320 --> 00:02:03,680
to the receiver.

40
00:02:03,680 --> 00:02:07,250
So four is clearly
going to be incorrect.

41
00:02:07,250 --> 00:02:09,610
So going back over
our answers, I

42
00:02:09,610 --> 00:02:13,420
would say that three is
our best sounding answer.

43
00:02:13,420 --> 00:02:16,910
That would make one and
two incorrect as well.

44
00:02:16,910 --> 00:02:20,350
So I would say that our correct
answer for this question

45
00:02:20,350 --> 00:02:21,990
is number three--

46
00:02:21,990 --> 00:02:24,730
using the unicast
routing table to verify

47
00:02:24,730 --> 00:02:28,020
the path to the source.

48
00:02:28,020 --> 00:02:31,100
Next, we have a
fill-in-the-blank question--

49
00:02:31,100 --> 00:02:35,015
what is a PIM sparse
mode register message?

50
00:02:35,015 --> 00:02:40,620

51
00:02:40,620 --> 00:02:42,680
So again, as a
fill in the blank,

52
00:02:42,680 --> 00:02:45,710
as long as we have something
similar to this answer,

53
00:02:45,710 --> 00:02:47,840
we would consider it correct.

54
00:02:47,840 --> 00:02:54,620
The original multicast frame
is encapsulated into unicast

55
00:02:54,620 --> 00:03:00,710
and sent or forwarded to the
Rendezvous Point or the RP.

56
00:03:00,710 --> 00:03:03,710
That's all a PIM
register message is.

57
00:03:03,710 --> 00:03:07,970
It's the original multicast
frame sent through unicast

58
00:03:07,970 --> 00:03:11,330
to the RP who then,
remember, makes

59
00:03:11,330 --> 00:03:16,460
an S, G entry so that we can
then build a proper multicast

60
00:03:16,460 --> 00:03:19,910
tree towards the source.

61
00:03:19,910 --> 00:03:23,520
Final question, we have
another fill in the blank--

62
00:03:23,520 --> 00:03:27,680
what is the general
principle of PIM dense mode?

63
00:03:27,680 --> 00:03:33,470

64
00:03:33,470 --> 00:03:38,410
So we could say that the
general principle is to flood.

65
00:03:38,410 --> 00:03:41,590
So when multicast
traffic is received,

66
00:03:41,590 --> 00:03:46,000
we're going to flood it out
all PIM-enabled interfaces,

67
00:03:46,000 --> 00:03:50,170
except, of course, the
interface that it arrived on.

68
00:03:50,170 --> 00:03:52,270
We wouldn't want to send
it back out the same way

69
00:03:52,270 --> 00:03:53,600
it came, of course.

70
00:03:53,600 --> 00:03:58,180
But other than that, we default
to flooding the traffic out all

71
00:03:58,180 --> 00:04:02,000
of our PIM-enabled interfaces.

72
00:04:02,000 --> 00:04:04,220
So that concludes this quiz.

73
00:04:04,220 --> 00:04:06,880
If you feel that you are
missing any of the information

74
00:04:06,880 --> 00:04:08,920
to answer these
questions, I would

75
00:04:08,920 --> 00:04:12,040
encourage you to go back and
review the sources referenced

76
00:04:12,040 --> 00:04:13,610
on each question.

77
00:04:13,610 --> 00:04:17,380
Otherwise, congratulations
on completing discovering

78
00:04:17,380 --> 00:04:18,880
multicast routing.

79
00:04:18,880 --> 00:04:21,220
I hope this has been
informative for you,

80
00:04:21,220 --> 00:04:24,420
and I'd like to thank
you for viewing.

81
00:04:24,420 --> 00:04:28,000