[AUDIO LOGO]
So now that we have everything up and running
and we have our receiver ready to receive
the multicast traffic, it's time to jump in and start up
the source.
We're, of course, going to be using router 10 for the source,
but we'll see that on the diagram.
So what we want to do is start up the source, make
sure the traffic is actually getting to the receiver,
and then, of course, we're going to jump in and examine
the S comma G tree that gets formed within our environment.
So let's start off with that topology diagram,
so we know what to expect, and then
we'll jump into the command line and get this up and running.
So once again, we are still on Multicast Topology
1 in the same environment we have been.
This time, however, we're going to be configuring the source up
here on router 10.
We're going to do this by simply configuring router 10 to do
a ping of this address that will cause it to generate
the multicast traffic.
When that traffic reaches router 6 being the first hop router,
the first hop router is going to send a PIM register
message, which is unicast down here to the RP router 4.
Then router 4 will decapsulate that and send it
down the star comma G tree to router 3, and then the router
7, who will, of course, forward this over to router 8.
This is what's expected to happen for the very first ping.
But right after that, it's going to do an SPT switchover.
So what we're ultimately going to be looking for is the RP
should no longer be in the forwarding path.
The ultimate path we're looking for
is router 6 should forward this to router 1.
Router 1 should forward it to router 3.
So all of this is multicast over the shortest path.
This is what we're going to be looking for.
So let's go ahead and jump in.
We'll start up a Wireshark capture.
Over here on router 8, specifically on this gigabit 1
interface.
And we're going to do that because that's really
the best way to see if our multicast traffic is actually
making it to router 8.
The router acting as a client or receiver
won't actually respond to the ping in this particular version
of code.
Some routers will, router 8 will not.
So we're just going to capture the traffic on the wire
and make sure the multicast is actually
making it to that interface.
That's our main concern.
So let's go ahead and jump in and get those things going.
So let's begin by doing our ping of 224.1.1.1.
And we'll set a repeat count just so it doesn't stop.
And we'll go ahead and start that ping now again, we're
not expecting to see any results from this we're just expecting
it to generate traffic.
So now let's take a look at what's
going on in the environment, and we
can start by looking at Wireshark
to make sure that router 8 is actually receiving the traffic.
So all we're looking for here in the Wireshark output
this time is we're filtering by ICMP to catch the ping,
and we see here that we are, in fact, getting
a large number of pings coming from router 10, which
is the 50.2.60.1.10.
It's simply sourcing it from its egress interface,
going to the destination 224.1.1.1.
We can also hop over and take a look at router 7, where I also
had a debug running for IP PIM.
So let's go take a look at router 7
and see what happens when that first ping arrived at router 7.
What we see here from the debug is
as soon as the first ping arrived here on router 7,
we see it inserting an S comma G join into the queue going
to neighbor 3.
It then, of course, builds the join prune packet,
adds the version 2 S comma G join into the routing table,
and sends that join over gigabit 2 TO router 3.
So this looks like it built the S comma G tree properly
for the SPT switchover.
We can verify this, of course, with a show IP mroute.
So we see that it does, in fact, have
the S comma G entry for router 10
being the source for 244.1.1.1.
Under the flags, we see a J and a T. J
means that it's locally joined because it has a local client
that's joined that group.
The T indicates that this has done the SPT switchover.
This is the shortest path tree.
We also see that it's correctly listing the incoming interface
as gigabit 2 with the correct RPF neighbor of router 3
to get back to the source of router 10,
and our oil is correct pointing out gigabit 3.
Let's also take a look at this on router 3.
So, if we do our show PIM topology,
we see that it also has the S comma
G. It is running in sparse mode, and it is also
the shortest path tree.
We see that it's joined.
It has the RPF information for router 1.
Notice it's not going to router 4 the RP.
It shouldn't be because this is the shortest path tree.
It's instead going to router 1.
Notice the star comma G for this same group
has a completely different RPF check.
It's going to router 4.
So this is showing the difference between the shared
tree, which, of course, is always
going to the rendezvous point.
And the shortest path tree, which is now
going up towards router 1.
That being the case, the rendezvous point
should not even be involved in this forwarding.
Let's take a look at what this looks like on router 4.
Now, of course, the star comma G entry here on router 4
looks the same as it did before.
However, notice that it's created two entries for the S
comma G. The first one you might notice
looks an awful lot like the star comma G
in that the RPF is the decapsulation tunnel.
This is the S comma G entry that was created
when that encapsulated register message first
got here to the RP.
But also note that this is pruned.
And if we take a look at its normal S comma G entry here,
we can see that the RPF interface
is router 5, which would be correct for traffic
coming from router 10.
However, notice that no interfaces
are on the outbound list.
This is because it is pruned.
Nobody has requested traffic for this
because it's not on the shortest path tree.
Now router 1 should be in the tree.
So if we do our show PIM topology,
once again, here we have the S comma G entry now.
It is the SPT tree.
And we see that it has the correct information where
router 6 is the incoming, and it's gigabit 0001 is outgoing
because that's where it received the join from router 3.
Last but not least, let's take a look at router 6.
We do a show IP mroute on router 6.
And on this S comma G entry, notice that this
has two flags as well.
The F indicates that this is the router
responsible for registering this source.
That's telling us that it's been registered with the RP.
Also, the T indicates that, again, this
is the shortest path tree.
We also, of course, see that the appropriate interfaces
are on the ingoing and outgoing interface
list, which is, of course, why the traffic is making it
all the way through our environment.
So we see that the S comma G entry has been formed properly
through our entire environment using the shortest path
between router 10 and router 8.
So, in this video, we fired up our source,
and we got our multicast traffic flowing properly
across the shortest path source tree from router 10,
acting as our source to router 8, acting as our receiver.
So all of this indicates that PIM sparse mode is working
100% as we designed it in our environment,
including the rendezvous point being statically configured,
all of the routers forwarding the traffic as they need to,
and all of the RPF checks being passed so that the traffic gets
forwarded properly.
All of that said, that covers everything
that we need to discuss in this skill.
That leaves us with nothing more than a review
in the form of a quiz, and that's exactly what
we're going to do next.
Till then, I hope this has been informative for you,
and I'd like to thank you for viewing.