Now we're finally going to get into the moment you've all been waiting
for. We're going to start focusing on protocol independent multicast sparse
mode and then going into the details of how it works.
Now before I go into this and finish up with the PIMS sparse mode section,
which will take us a few hours to do, let me give you a disclaimer.
PIMS sparse mode is a very complex topic, a very complex protocol.
This class is not designed to cover every nitty gritty little detail and
flag and timer and state machine of PIMS sparse mode.
I am going to get pretty deep, but there are a few things that you'll
find in the RFC that I'm not going to cover because that would literally
take probably three full days just to cover everything about PIMS sparse
mode alone. So I think what we're going to cover here should be enough
to get you past any CCIE written or even lab questions I can think of
on PIMS sparse mode.
Might be one or two things that fall off the shelf that I don't cover,
but hopefully you'll be pretty content with the level of depth that we
do get into. So let's go ahead and go into it.
So first of all, before I start, I want to show you what the topologies
are that I'm going to be using as I do my various lab demonstrations and
stuff. So in the event that you want to try to recreate any of this on
your own, you can do so.
So for those of you who are watching the live feed right now, if in the
upper right corner you click on the file section, you will see that there's
a PDF that looks like this, that has the various topologies in it that
I'm going to be using.
So this is actually the physical layout.
Sorry, it looks kind of messy here, but this is the physical layout that
I'm using. You can see I've got a total of eight routers and then a switch.
So in part of the lab, the switch is just purely a layer two switch, and
then in part of the lab I'm actually turning on the routing and multicast
functionality of the switch and using it like a ninth router.
So this is the physical topology.
Now I've also got my laptop connected here so I can capture wire shark
snipper traces and stuff.
And this is actually the logical topology right here.
So this is what we're going to build up.
So router one is actually serving as my receiver as my laptop basically.
Router five is the source, so that's where I'm going to be doing my multicast
pings and stuff.
And then primarily these four routers here in the middle are the ones
where I'm going to be doing all of my multicast demonstrations and examples
and things. There are a couple of additional topologies.
For example, when we get into the auto RP and BSR section, I'll change
over my lab topology to this.
Same physical routers, just a different logical topology.
Okay, so if you are watching this in the recording, let me go back to
this. You may want to take a snapshot of this, you know, using some sort
of snagget or any other snapshot utility so that you can refer back to
this frequently as I am talking about it.
And for those of you watching live, I'd recommend that you open up that
PDF and keep this in front of you at all times.
Okay, and I've also created a whiteboard of that exact same topology,
which is right here.
So I can draw on this and talk about what's going on as we do it.
So that being the case.
Let's talk about PIM.
So PIM, as I mentioned, stands for protocol independent multicast.
Now I already mentioned the reason why they call it protocol independent
is because just like all other multicast routing protocols, it does RPF
checks on the source address of any multicast that come in.
And protocol independent means PIM doesn't care where it finds a matching
route. It doesn't care if it's a rip route, an OSP or a route, even a
static M route doesn't care as long as it can find something.
So that's what means it's protocol independent.
So there are two primary varieties of it, PIM dense mode, which is not
used a whole lot because a lot of people don't like that idea of flooding
their multicast everywhere just to prune it back.
But that's basically what it does.
And there's the RFC forward if you're ever curious.
And then the one we're going to be focusing in on is PIM sparse mode,
which is RFC 4601.
Now that's not the original RFC.
Actually PIM sparse mode came out a long time ago and it's gone through
several iterations and updates of the RFC.
But I do believe that is the most current RFC as of this recording, which
is November 3rd, 2015.
So what's the objective of both?
What we've been talking about, the objective is to build that multicast
distribution tree connecting the source to the receivers so the multicast
can flow down. That's the whole objective behind it.
Okay, so PIM sparse mode, there's the very original RFC, if you want to
look that up, 2117, currently RFC 4601, and it relies on the pole model.
So this is sort of a review of what we've talked about.
So PIM sparse mode relies on the concept of a rendezvous point.
That's sort of like the dating service that I had in my previous analogy.
So when multicast flows from the rendezvous point down to wherever the
various receivers are, we say that that's flowing down the shared tree
or the core tree, also known as the RP tree.
So that's three terms for the exact same thing.
Shared tree, core tree, RP tree.
Basically, it means the same thing as wherever receiver is, that path
from the receiver up to the RP, that is the shared tree.
And that's where the multicast first starts flowing.
And then as it says, once the multicast source is discovered, once the
routers learn what the source address is, they can switch over to the
shortest path tree.
Now sometimes the source path tree might actually be that exact same tree
through the rendezvous point.
It might be through the rendezvous point and up.
Other times it might be something different.
That's all based on the routing protocol.
You know, what does your routing table say?
It is the best way to get to that source.
All right, so let's talk about some versions of PIM.
So the original version of PIM was PIM version 1.
Version 2 has been the de facto standard for a long time.
Where are some similarities?
Well, if you actually did a stiffer trace, the body of the PIM packets
is identical in version 1 and version 2.
You know, the types of messages they carry.
The functionality is the same.
You know, when they send the triggers for certain things is the same.
A couple of main differences though.
So PIM version 1 actually utilized IGMP as the transport protocol.
So right behind the IP header, you'd have an IGMP header and then you'd
have PIM in the body of that packet.
But when PIM version 2 came out, that actually became its own separate
IP protocol. And you'll see it in sniffer traces as IP protocol number
103. So it's no longer relying on IGMP.
The other main difference is that the feature of the PIM bootstrap router,
which we'll get to at the end of these recordings, is only available in
PIM version 2. That's a way of dynamically electing and discovering the
rendezvous point.
In most of my labs here that I'm going to do, I'm going to statically
configure a rendezvous point.
But auto RP and PIM BSR are two different ways where you can dynamically
discover an RP, which a lot of people do.
A couple of additional things.
If you have a router that actually has the capability of doing version
1 or version 2, because the body of the PIM packets is the same, and because
the functionality is the same, you can actually have that router doing
both. But you can't have both on the same interface.
So for example, you have a router who on fast ethernet 1 is doing PIM
version 1, and on fast ethernet 2 is doing PIM version 2, and it will
be able to communicate back and forth.
Most Cisco routers now though, only run PIM version 2, and they won't
even let you change to PIM version 1.
For example, let me give you an example.
Here, in my lab, I'm using a really old Cisco 2500 series router as my
terminal server, as my access server.
And see here, what kind of software is this running?
So this guy's running 1233A software.
And you can see if I go into an interface, let's see here, do show IP
interface brief, interface ethernet 0, and I type IP PIM question mark.
You can see there's a version, right?
IP PIM version, and then I can select, it will default to version 2, but
I can select it back to version 1.
But in most newer devices, for example, if I go to one of my other routers
here, IP PIM, you'll notice that the version is not even option.
You can't even change it back to version 1.
So just a little note there, depending on the software you're running.
And this guy here, in case you're wondering, is running 15.33 software.
So I'm not sure where the cutoff was between where they completely stripped
out PIM V1 functionality, but somewhere between 12.3 and 15.3 is when
they got rid of it.
All right, so PIM has some comparison, some analogies I can make to IGP
routing protocols.
For example, most IGP routing protocols dynamically discover neighbors,
the ascending out multicast packets and sending out periodic hellos.
PIM does that as well.
PIM sends out hello packets, and this is the reserved address of 224.0113.
And yes, if you're ever taking any Cisco test, chances are they'll probably
expect you to have that address memorized.
So those are PIM hello packets.
Unlike OSPF and EIGRP, which send out their hellos pretty frequently,
like every 5 or 10 seconds, PIM hello packets go out every 30 seconds.
So they're not as frequent as IGP routing protocols.
And like an IGP routing protocol, if a hello packet just suddenly stops,
if you don't receive it, you'll declare that neighbor dead.
And similarly, most protocols that rely on some sort of a keep alive or
hello mechanism, usually they all file the same rule.
After three lost keep alive or three hellos are lost, you're done.
Your neighbor is dead.
PIM is the same.
And the information learned via PIM has an expiration time.
That's also similar.
So for example, this is similar to OSPF, right?
So with OSPF, if I learn of an LSA within my area that's describing some
links, that LSA is only good for one hour.
That's the age time of that LSA.
And if the owner of that LSA who originated it does not refresh it before
60 minutes, before an hour, I'm going to age it out.
PIM is sort of like that.
When PIM dynamically discovers multicast routes or dynamically learns
of receivers who've wanted to join, it's not going to keep that information
forever. That stuff will age out after a while.
As a matter of fact, the default time is about three minutes.
Technically, it's 210 seconds, but a lot of people say three minutes.
So PIM has a lot of mechanisms to keep the state refreshed so that won't
happen. Now, where are some differences?
A lot of differences.
Number one, interior gateway protocols only care about destinations, right?
OSPF, EIGRP, RIP.
All they care about is where subnets live, where the destination of the
pack is going to go to.
PIM hears about sources and destinations.
PIM is keeping track of both.
So something else.
So PIM relies on a host, which is your receiver or a source, to trigger
any PIM information exchange.
And this is a little bit different, right?
Your normal IGP routing protocols, what triggers information exchange
is if you bring an interface up and interface goes down, you add a static
route, but it doesn't really rely on hosts or servers in order to exchange
routes or learn of routes.
PIM does. PIM is not going to do anything until a new receiver comes online
or a new source comes online.
Otherwise, PIM will just be sort of idle.
PIM populates its own unique table called the M-route table.
This is short for the multicast routing table.
So we've got our unitcast routing table and our multicast routing table.
One thing also that's very important about this, I mentioned a little
bit earlier, but I will state it again.
So with some routing protocols, let's say you typed into a router, no
IP routing. You do that at the global level.
And then you try to turn on OSPF, let's say.
I've seen some routers that will actually allow you to enable the OSPF
protocol. You'll see it exchange hellos, exchange LSA's, it'll populate
the link state database, but none of that stuff will go into the routing
table. Because if you do no IP routing, it can't populate the routing
table. There is no routing table.
It can't create that table.
So all the stuff can be running in the background, but there's no place
to put that information.
PIM is the same.
With PIM, you can enable PIM on your interfaces and it will learn of neighbors
and it will send, it'll receive, IGMP membership reports and stuff, but
it will not populate the multicast routing table with anything that's
learned unless you enable multicast routing.
So at the global level, the very first thing you have to type in is IP
multicast-routing.
Otherwise enabling PIM is useless.
It won't do anything.
We've already talked about how PIM performs RPF checks by default and
it cannot work alone.
PIM requires something to populate the unicast routing table because of
that bullet I just mentioned.
Can't perform an RPF check if there's no routes in the routing table to
match what you're trying to find.
Now you could do to static routes, but there's got to be something in
the routing table.
So what is the role of a PIM RP?
So we've talked a little bit about this already.
This is the central focus point where when a receiver joins the network
by sending an IBIGMP membership report, that default gateway that's directly
connected to it will send a PIM join up to the rendezvous point.
And this builds the core tree, the shared tree, so it's ready and waiting
for multicast to flow down it.
Similarly, when the multicast source starts sending its multicast data,
the router that it's directly connected to will forward that multicast
data to the rendezvous point to complete the process to connect everything
together. And how does a router know who the RP is?
For our purposes, we're going to statically configure that.
But you can also have routers dynamically determined via things like auto
RP and the PIM bootstrap router.