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

2
00:00:03,304 --> 00:00:08,230

3
00:00:08,230 --> 00:00:10,610
So now that we have
everything up and running

4
00:00:10,610 --> 00:00:13,130
and we have our receiver
ready to receive

5
00:00:13,130 --> 00:00:16,790
the multicast traffic, it's
time to jump in and start up

6
00:00:16,790 --> 00:00:17,720
the source.

7
00:00:17,720 --> 00:00:20,750
We're, of course, going to be
using router 10 for the source,

8
00:00:20,750 --> 00:00:22,980
but we'll see that
on the diagram.

9
00:00:22,980 --> 00:00:25,970
So what we want to do is
start up the source, make

10
00:00:25,970 --> 00:00:29,000
sure the traffic is actually
getting to the receiver,

11
00:00:29,000 --> 00:00:32,119
and then, of course, we're
going to jump in and examine

12
00:00:32,119 --> 00:00:36,240
the S comma G tree that gets
formed within our environment.

13
00:00:36,240 --> 00:00:39,270
So let's start off with
that topology diagram,

14
00:00:39,270 --> 00:00:41,510
so we know what to
expect, and then

15
00:00:41,510 --> 00:00:46,340
we'll jump into the command line
and get this up and running.

16
00:00:46,340 --> 00:00:49,390
So once again, we are
still on Multicast Topology

17
00:00:49,390 --> 00:00:52,330
1 in the same
environment we have been.

18
00:00:52,330 --> 00:00:55,720
This time, however, we're going
to be configuring the source up

19
00:00:55,720 --> 00:00:57,590
here on router 10.

20
00:00:57,590 --> 00:01:02,080
We're going to do this by simply
configuring router 10 to do

21
00:01:02,080 --> 00:01:06,910
a ping of this address that
will cause it to generate

22
00:01:06,910 --> 00:01:08,950
the multicast traffic.

23
00:01:08,950 --> 00:01:14,470
When that traffic reaches router
6 being the first hop router,

24
00:01:14,470 --> 00:01:18,400
the first hop router is
going to send a PIM register

25
00:01:18,400 --> 00:01:24,790
message, which is unicast
down here to the RP router 4.

26
00:01:24,790 --> 00:01:29,980
Then router 4 will
decapsulate that and send it

27
00:01:29,980 --> 00:01:34,960
down the star comma G tree to
router 3, and then the router

28
00:01:34,960 --> 00:01:39,850
7, who will, of course,
forward this over to router 8.

29
00:01:39,850 --> 00:01:43,780
This is what's expected to
happen for the very first ping.

30
00:01:43,780 --> 00:01:48,080
But right after that, it's
going to do an SPT switchover.

31
00:01:48,080 --> 00:01:52,730
So what we're ultimately going
to be looking for is the RP

32
00:01:52,730 --> 00:01:55,760
should no longer be in
the forwarding path.

33
00:01:55,760 --> 00:01:57,680
The ultimate path
we're looking for

34
00:01:57,680 --> 00:02:01,070
is router 6 should
forward this to router 1.

35
00:02:01,070 --> 00:02:04,610
Router 1 should
forward it to router 3.

36
00:02:04,610 --> 00:02:09,860
So all of this is multicast
over the shortest path.

37
00:02:09,860 --> 00:02:12,180
This is what we're
going to be looking for.

38
00:02:12,180 --> 00:02:14,270
So let's go ahead and jump in.

39
00:02:14,270 --> 00:02:18,470
We'll start up a
Wireshark capture.

40
00:02:18,470 --> 00:02:22,640
Over here on router 8,
specifically on this gigabit 1

41
00:02:22,640 --> 00:02:23,790
interface.

42
00:02:23,790 --> 00:02:26,060
And we're going to do
that because that's really

43
00:02:26,060 --> 00:02:30,080
the best way to see if our
multicast traffic is actually

44
00:02:30,080 --> 00:02:32,150
making it to router 8.

45
00:02:32,150 --> 00:02:35,780
The router acting as
a client or receiver

46
00:02:35,780 --> 00:02:40,460
won't actually respond to the
ping in this particular version

47
00:02:40,460 --> 00:02:41,430
of code.

48
00:02:41,430 --> 00:02:44,700
Some routers will,
router 8 will not.

49
00:02:44,700 --> 00:02:47,090
So we're just going to capture
the traffic on the wire

50
00:02:47,090 --> 00:02:49,220
and make sure the
multicast is actually

51
00:02:49,220 --> 00:02:51,230
making it to that interface.

52
00:02:51,230 --> 00:02:52,920
That's our main concern.

53
00:02:52,920 --> 00:02:56,045
So let's go ahead and jump in
and get those things going.

54
00:02:56,045 --> 00:02:58,670

55
00:02:58,670 --> 00:03:03,310
So let's begin by doing
our ping of 224.1.1.1.

56
00:03:03,310 --> 00:03:06,680
And we'll set a repeat count
just so it doesn't stop.

57
00:03:06,680 --> 00:03:09,730
And we'll go ahead and start
that ping now again, we're

58
00:03:09,730 --> 00:03:13,810
not expecting to see any results
from this we're just expecting

59
00:03:13,810 --> 00:03:15,800
it to generate traffic.

60
00:03:15,800 --> 00:03:17,950
So now let's take
a look at what's

61
00:03:17,950 --> 00:03:20,050
going on in the
environment, and we

62
00:03:20,050 --> 00:03:22,030
can start by
looking at Wireshark

63
00:03:22,030 --> 00:03:27,140
to make sure that router 8 is
actually receiving the traffic.

64
00:03:27,140 --> 00:03:30,100
So all we're looking for
here in the Wireshark output

65
00:03:30,100 --> 00:03:35,410
this time is we're filtering
by ICMP to catch the ping,

66
00:03:35,410 --> 00:03:38,230
and we see here that we
are, in fact, getting

67
00:03:38,230 --> 00:03:42,790
a large number of pings
coming from router 10, which

68
00:03:42,790 --> 00:03:45,820
is the 50.2.60.1.10.

69
00:03:45,820 --> 00:03:49,360
It's simply sourcing it
from its egress interface,

70
00:03:49,360 --> 00:03:54,940
going to the
destination 224.1.1.1.

71
00:03:54,940 --> 00:04:00,100
We can also hop over and take a
look at router 7, where I also

72
00:04:00,100 --> 00:04:03,040
had a debug running for IP PIM.

73
00:04:03,040 --> 00:04:04,960
So let's go take
a look at router 7

74
00:04:04,960 --> 00:04:10,810
and see what happens when that
first ping arrived at router 7.

75
00:04:10,810 --> 00:04:13,540
What we see here
from the debug is

76
00:04:13,540 --> 00:04:17,019
as soon as the first ping
arrived here on router 7,

77
00:04:17,019 --> 00:04:23,650
we see it inserting an S comma
G join into the queue going

78
00:04:23,650 --> 00:04:25,210
to neighbor 3.

79
00:04:25,210 --> 00:04:28,660
It then, of course, builds
the join prune packet,

80
00:04:28,660 --> 00:04:35,230
adds the version 2 S comma G
join into the routing table,

81
00:04:35,230 --> 00:04:40,180
and sends that join over
gigabit 2 TO router 3.

82
00:04:40,180 --> 00:04:44,980
So this looks like it built
the S comma G tree properly

83
00:04:44,980 --> 00:04:47,170
for the SPT switchover.

84
00:04:47,170 --> 00:04:52,030
We can verify this, of
course, with a show IP mroute.

85
00:04:52,030 --> 00:04:54,100
So we see that it
does, in fact, have

86
00:04:54,100 --> 00:04:57,100
the S comma G
entry for router 10

87
00:04:57,100 --> 00:05:01,300
being the source for 244.1.1.1.

88
00:05:01,300 --> 00:05:05,500
Under the flags, we
see a J and a T. J

89
00:05:05,500 --> 00:05:08,530
means that it's locally joined
because it has a local client

90
00:05:08,530 --> 00:05:10,000
that's joined that group.

91
00:05:10,000 --> 00:05:15,710
The T indicates that this
has done the SPT switchover.

92
00:05:15,710 --> 00:05:18,620
This is the shortest path tree.

93
00:05:18,620 --> 00:05:22,280
We also see that it's correctly
listing the incoming interface

94
00:05:22,280 --> 00:05:27,560
as gigabit 2 with the correct
RPF neighbor of router 3

95
00:05:27,560 --> 00:05:30,200
to get back to the
source of router 10,

96
00:05:30,200 --> 00:05:35,240
and our oil is correct
pointing out gigabit 3.

97
00:05:35,240 --> 00:05:38,540
Let's also take a look
at this on router 3.

98
00:05:38,540 --> 00:05:41,270
So, if we do our
show PIM topology,

99
00:05:41,270 --> 00:05:44,090
we see that it also
has the S comma

100
00:05:44,090 --> 00:05:49,220
G. It is running in sparse
mode, and it is also

101
00:05:49,220 --> 00:05:51,260
the shortest path tree.

102
00:05:51,260 --> 00:05:52,940
We see that it's joined.

103
00:05:52,940 --> 00:05:56,960
It has the RPF
information for router 1.

104
00:05:56,960 --> 00:06:01,250
Notice it's not going
to router 4 the RP.

105
00:06:01,250 --> 00:06:04,640
It shouldn't be because this
is the shortest path tree.

106
00:06:04,640 --> 00:06:07,430
It's instead going to router 1.

107
00:06:07,430 --> 00:06:11,740
Notice the star comma
G for this same group

108
00:06:11,740 --> 00:06:14,560
has a completely
different RPF check.

109
00:06:14,560 --> 00:06:16,600
It's going to router 4.

110
00:06:16,600 --> 00:06:20,560
So this is showing the
difference between the shared

111
00:06:20,560 --> 00:06:22,420
tree, which, of
course, is always

112
00:06:22,420 --> 00:06:24,230
going to the rendezvous point.

113
00:06:24,230 --> 00:06:27,610
And the shortest path
tree, which is now

114
00:06:27,610 --> 00:06:29,710
going up towards router 1.

115
00:06:29,710 --> 00:06:32,680
That being the case,
the rendezvous point

116
00:06:32,680 --> 00:06:35,170
should not even be involved
in this forwarding.

117
00:06:35,170 --> 00:06:37,555
Let's take a look at what
this looks like on router 4.

118
00:06:37,555 --> 00:06:40,860

119
00:06:40,860 --> 00:06:44,340
Now, of course, the star
comma G entry here on router 4

120
00:06:44,340 --> 00:06:46,660
looks the same as it did before.

121
00:06:46,660 --> 00:06:51,750
However, notice that it's
created two entries for the S

122
00:06:51,750 --> 00:06:55,080
comma G. The first
one you might notice

123
00:06:55,080 --> 00:06:59,130
looks an awful lot
like the star comma G

124
00:06:59,130 --> 00:07:03,700
in that the RPF is the
decapsulation tunnel.

125
00:07:03,700 --> 00:07:06,540
This is the S comma G
entry that was created

126
00:07:06,540 --> 00:07:09,600
when that encapsulated
register message first

127
00:07:09,600 --> 00:07:11,580
got here to the RP.

128
00:07:11,580 --> 00:07:16,270
But also note that
this is pruned.

129
00:07:16,270 --> 00:07:20,030
And if we take a look at its
normal S comma G entry here,

130
00:07:20,030 --> 00:07:22,150
we can see that
the RPF interface

131
00:07:22,150 --> 00:07:25,750
is router 5, which would
be correct for traffic

132
00:07:25,750 --> 00:07:27,400
coming from router 10.

133
00:07:27,400 --> 00:07:30,910
However, notice
that no interfaces

134
00:07:30,910 --> 00:07:34,160
are on the outbound list.

135
00:07:34,160 --> 00:07:37,300
This is because it is pruned.

136
00:07:37,300 --> 00:07:40,000
Nobody has requested
traffic for this

137
00:07:40,000 --> 00:07:43,210
because it's not on
the shortest path tree.

138
00:07:43,210 --> 00:07:46,220
Now router 1 should
be in the tree.

139
00:07:46,220 --> 00:07:48,940
So if we do our
show PIM topology,

140
00:07:48,940 --> 00:07:52,660
once again, here we have
the S comma G entry now.

141
00:07:52,660 --> 00:07:55,780
It is the SPT tree.

142
00:07:55,780 --> 00:07:59,800
And we see that it has the
correct information where

143
00:07:59,800 --> 00:08:06,910
router 6 is the incoming, and
it's gigabit 0001 is outgoing

144
00:08:06,910 --> 00:08:11,140
because that's where it
received the join from router 3.

145
00:08:11,140 --> 00:08:14,530
Last but not least, let's
take a look at router 6.

146
00:08:14,530 --> 00:08:17,590
We do a show IP
mroute on router 6.

147
00:08:17,590 --> 00:08:21,190
And on this S comma G
entry, notice that this

148
00:08:21,190 --> 00:08:23,200
has two flags as well.

149
00:08:23,200 --> 00:08:26,650
The F indicates that
this is the router

150
00:08:26,650 --> 00:08:29,620
responsible for
registering this source.

151
00:08:29,620 --> 00:08:33,190
That's telling us that it's
been registered with the RP.

152
00:08:33,190 --> 00:08:36,580
Also, the T indicates
that, again, this

153
00:08:36,580 --> 00:08:38,860
is the shortest path tree.

154
00:08:38,860 --> 00:08:42,400
We also, of course, see that
the appropriate interfaces

155
00:08:42,400 --> 00:08:45,280
are on the ingoing
and outgoing interface

156
00:08:45,280 --> 00:08:48,640
list, which is, of course,
why the traffic is making it

157
00:08:48,640 --> 00:08:50,630
all the way through
our environment.

158
00:08:50,630 --> 00:08:54,730
So we see that the S comma G
entry has been formed properly

159
00:08:54,730 --> 00:08:58,520
through our entire environment
using the shortest path

160
00:08:58,520 --> 00:09:03,210
between router 10 and router 8.

161
00:09:03,210 --> 00:09:06,810
So, in this video, we
fired up our source,

162
00:09:06,810 --> 00:09:11,010
and we got our multicast
traffic flowing properly

163
00:09:11,010 --> 00:09:16,350
across the shortest path
source tree from router 10,

164
00:09:16,350 --> 00:09:21,160
acting as our source to router
8, acting as our receiver.

165
00:09:21,160 --> 00:09:25,350
So all of this indicates that
PIM sparse mode is working

166
00:09:25,350 --> 00:09:29,230
100% as we designed
it in our environment,

167
00:09:29,230 --> 00:09:32,400
including the rendezvous point
being statically configured,

168
00:09:32,400 --> 00:09:35,760
all of the routers forwarding
the traffic as they need to,

169
00:09:35,760 --> 00:09:40,170
and all of the RPF checks being
passed so that the traffic gets

170
00:09:40,170 --> 00:09:41,790
forwarded properly.

171
00:09:41,790 --> 00:09:44,970
All of that said,
that covers everything

172
00:09:44,970 --> 00:09:47,610
that we need to
discuss in this skill.

173
00:09:47,610 --> 00:09:51,240
That leaves us with
nothing more than a review

174
00:09:51,240 --> 00:09:53,940
in the form of a quiz,
and that's exactly what

175
00:09:53,940 --> 00:09:55,290
we're going to do next.

176
00:09:55,290 --> 00:09:58,800
Till then, I hope this has
been informative for you,

177
00:09:58,800 --> 00:10:01,940
and I'd like to thank
you for viewing.

178
00:10:01,940 --> 00:10:06,000