|
0:00:13
|
Our next control plane protocol for multicast is going to be PIM
|
|
0:00:17
|
or Protocol Independent Multicast
|
|
0:00:19
|
that's used between the routers to figure out how should the multicast
|
|
0:00:23
|
tree be built from the sender down to the receiver
|
|
0:00:27
|
or from the sender to the rendezvous point and then from the
|
|
0:00:30
|
rendezvous point down to the receiver.
|
|
0:00:32
|
Now PIM is considered protocol independent because it doesn't
|
|
0:00:36
|
advertise any topology information when it's building the
|
|
0:00:39
|
multicast tree which we'll see that implies that we need an
|
|
0:00:43
|
underlying interior gateway protocol, so a regular unicast
|
|
0:00:47
|
routing protocol in order to make sure that the topology
|
|
0:00:50
|
is loop-free to begin with.
|
|
0:00:53
|
So when you're running multicast, it implies that you already
|
|
0:00:56
|
have OSPF or EIGRP
|
|
0:00:58
|
or some other IGP to establish the basic loop-free
|
|
0:01:01
|
topology before we start to send the multicast traffic
|
|
0:01:04
|
through the network.
|
|
0:01:07
|
Now we'll see that there are some loop prevention mechanisms
|
|
0:01:10
|
built into multicast forwarding logic mainly it's going to be
|
|
0:01:13
|
based on the reverse path forwarding check
|
|
0:01:16
|
but overall, PIM is not going to be advertising the topology
|
|
0:01:19
|
information, that's going to be up to IGP.
|
|
0:01:22
|
Now currently there's two different version of PIM
|
|
0:01:25
|
PIM version 1, PIM version 2 the router is going to run
|
|
0:01:27
|
PIM version 2 by default which is the newer specification.
|
|
0:01:31
|
The main difference we'll see is that PIM version 2 supports the
|
|
0:01:35
|
advertisement of the rendezvous point information dynamically
|
|
0:01:39
|
inside the PIM packet itself
|
|
0:01:41
|
and this is with the bootstrap router or the BSR message.
|
|
0:01:46
|
The other alternative to that auto RP is basically the
|
|
0:01:50
|
legacy Cisco proprietary way that you can do the same
|
|
0:01:53
|
result, but in PIM version 2 the rendezvous point advertisement
|
|
0:01:58
|
is standardized so that's what the router is going to be running by default.
|
|
0:02:03
|
Now it will be listening for other routers that are running
|
|
0:02:06
|
PIM version 1 on the interface and it can fall back to that
|
|
0:02:10
|
mode, but generally there's no reason that you would want to
|
|
0:02:13
|
configure the router as PIM version 1
|
|
0:02:15
|
it should have PIM version 2 by default at the interface level.
|
|
0:02:21
|
Now within the scope of troubleshooting
|
|
0:02:23
|
what this could possibly mean is that if you're trying to
|
|
0:02:26
|
run BSR on the interface, but the interface is configured for
|
|
0:02:30
|
PIM version 1, then it's not going to work
|
|
0:02:33
|
because the actual packet format for PIM version 2
|
|
0:02:36
|
has the field for the BSR where the PIM version 1
|
|
0:02:39
|
packet doesn't have that.
|
|
0:02:42
|
So unless the version has been changed back to version 1
|
|
0:02:45
|
then it should be fine. It's going to run version 2 by default
|
|
0:02:48
|
and it's going to detect are the neighbors on that link running version 1
|
|
0:02:51
|
or are they running version 2
|
|
0:02:55
|
We'll also see here that PIM has a couple different modes of
|
|
0:02:58
|
operation which are ultimately going to control how the multicast
|
|
0:03:02
|
tree is built and who is going to receive traffic when we
|
|
0:03:06
|
actually go to forward packets in the data plane.
|
|
0:03:11
|
So there's three different modes of PIM's operation
|
|
0:03:14
|
we have dense mode, sparse mode and then a combination
|
|
0:03:19
|
of both which is sparse dense mode.
|
|
0:03:22
|
Now the main differences are that with dense mode, we're going
|
|
0:03:26
|
to assume that all multicast traffic should be sent throughout the
|
|
0:03:29
|
network unless someone says that they do not want it.
|
|
0:03:33
|
So dense mode is considered implicit join
|
|
0:03:38
|
that you are going to receive multicast traffic for all possible
|
|
0:03:41
|
groups unless you specifically say you don't want that traffic.
|
|
0:03:45
|
So this is known as the flood and prune behavior
|
|
0:03:48
|
of dense mode where we just send all of the traffic
|
|
0:03:51
|
everywhere, then for links that we do not want to
|
|
0:03:54
|
forward it on, the routers are going to send the prune messages.
|
|
0:03:59
|
Now in general, there's really no reason why you would want to
|
|
0:04:01
|
implement dense mode because of this flooding and
|
|
0:04:05
|
pruning behavior, we'll also see later when we get into
|
|
0:04:08
|
IPv6 multicast, it doesn't even support dense mode
|
|
0:04:12
|
so it only runs in sparse mode operation
|
|
0:04:15
|
so 99 percent of the time, you would want to run in sparse mode.
|
|
0:04:18
|
The reason why is that the multicast trees are
|
|
0:04:22
|
built more efficiently because the router specifically has to
|
|
0:04:26
|
ask for it before the traffic is going to be received.
|
|
0:04:30
|
So where dense mode is implicit join, sparse mode is explicit join.
|
|
0:04:34
|
The router has to say I have a receiver that wants this particular
|
|
0:04:38
|
group. Now in order to do this to figure out what particular
|
|
0:04:43
|
destinations want what particular groups
|
|
0:04:46
|
we need to use the rendezvous point as the reference point in
|
|
0:04:51
|
order to process the join requests.
|
|
0:04:55
|
So with sparse mode, only if we are running source specific
|
|
0:04:58
|
multicast would we not need the rendezvous point.
|
|
0:05:01
|
So with source specific multicast, you do not need the
|
|
0:05:05
|
RP, it's only when you're running normal sparse mode
|
|
0:05:08
|
with only group specific joins do you need the rendezvous point.
|
|
0:05:13
|
So we'll look at in detail what are the differences
|
|
0:05:16
|
between those two, when do we build the shared tree versus the
|
|
0:05:20
|
shortest path tree and the ultimately how that's going to
|
|
0:05:23
|
affect the traffic flow in the network.
|
|
0:05:28
|
Then lastly we have a combination of both of them, sparse dense mode,
|
|
0:05:31
|
which basically means that for any group that we have a
|
|
0:05:34
|
rendezvous point assigned, that is going to run in sparse mode
|
|
0:05:39
|
where any other group that does not have a rendezvous point,
|
|
0:05:42
|
that's going to fall back to dense mode.
|
|
0:05:45
|
The third control plane protocol we're going to look at today is
|
|
0:05:48
|
multicast source discovery protocol or MSDP
|
|
0:05:52
|
This is going to be used between multiple rendezvous points
|
|
0:05:55
|
in a sparse mode PIM network
|
|
0:05:58
|
for them to signal to each other who are the multicast
|
|
0:06:01
|
senders in the network.
|
|
0:06:05
|
Now generally MSDP is designed for inter-AS multicast designs
|
|
0:06:10
|
where there's two different service providers that want to
|
|
0:06:12
|
exchange multicast sources, but we'll also see that this can be
|
|
0:06:17
|
used for an intra-AS application so inside one autonomous system
|
|
0:06:22
|
in our local enterprise network that's known as anycast RP
|
|
0:06:29
|
so we'll see more of the details about this later, but the basic
|
|
0:06:32
|
idea of anycast RP is that it gives redundancy to
|
|
0:06:35
|
our rendezvous points based on the fact that they're
|
|
0:06:39
|
simply sharing the same IP address in the network.
|
|
0:06:43
|
So it's going to be the same type of logic as how anycast
|
|
0:06:46
|
DNS works on the internet that when I send a request
|
|
0:06:49
|
to the top level DNS servers
|
|
0:06:51
|
if I'm in Europe, then they're going to go to the European servers
|
|
0:06:55
|
if I'm in US West Coast, it's going to go to the West Coast servers.
|
|
0:06:59
|
But technically the top level DNS servers they all have the same
|
|
0:07:02
|
IP address in the internet
|
|
0:07:04
|
so it's going to based on just whatever is my closest route
|
|
0:07:07
|
geographically to the server, that's where the packets are going to go.
|
|
0:07:12
|
So we'll see it's the same type of logic with anycast RP.
|
|
0:07:15
|
Basically it means that whoever is the closest rendezvous point
|
|
0:07:17
|
that's the one that you're going to use
|
|
0:07:20
|
but if that rendezvous point goes down, you should be able to
|
|
0:07:22
|
reroute towards another one simply based on the reconvergence
|
|
0:07:26
|
of IGP.
|
|
0:07:30
|
Now one of the key points we'll see about this with MSDP
|
|
0:07:33
|
is that it is not a replacement for PIM. Between the different
|
|
0:07:38
|
autonomous systems, we would still have the requirement
|
|
0:07:40
|
of running PIM sparse mode in order to actually build the
|
|
0:07:44
|
multicast tree.
|
|
0:07:46
|
MSDP is only used to signal about the multicast senders.
|
|
0:07:50
|
It doesn't have anything to do with the receivers and it doesn't
|
|
0:07:53
|
have anything to do with building the tree.
|
|
0:07:56
|
Now once we build the control plane for multicast
|
|
0:07:59
|
the end hosts send the signaling to the routers with IGMP
|
|
0:08:02
|
saying I want to receive traffic for this specific group.
|
|
0:08:06
|
Then the routers signal each other with PIM saying that
|
|
0:08:09
|
there's these senders, there's these receivers in the network
|
|
0:08:12
|
if we're running some sort of anycast or inter-AS design
|
|
0:08:15
|
the rendezvous points are then going to tell each other
|
|
0:08:18
|
with MSDP who are the different servers or the different sources in the network.
|
|
0:08:26
|
Then our final step for the forwarding is going to be in the data
|
|
0:08:29
|
plane where we need to make sure that when we actually
|
|
0:08:32
|
forward the traffic, we're not causing a loop of the multicast feed.
|
|
0:08:39
|
Now we'll see that the reason that this is an issue
|
|
0:08:42
|
is that there can be valid designs where the tree
|
|
0:08:46
|
builds itself as a looped network so PIM ends up building the tree
|
|
0:08:52
|
and the tree is not loop-free this is where the rendezvous
|
|
0:08:57
|
or excuse me, the reverse path forwarding check is going to come
|
|
0:08:59
|
in to make sure that when we actually forward the packets
|
|
0:09:03
|
they're only used on the interfaces that are actually the loop-free
|
|
0:09:06
|
paths back to the sources.
|
|
0:09:11
|
So the key point with the reverse path forwarding check
|
|
0:09:14
|
is that every time the router receives a multicast packet in
|
|
0:09:18
|
and the key is that it happens for every single packet.
|
|
0:09:22
|
So every time the packet comes in, the router is going to do a lookup
|
|
0:09:24
|
on the source address. It's going to correlate this
|
|
0:09:27
|
with the incoming interface for the feed.
|
|
0:09:31
|
If the incoming interface at the packet matches the
|
|
0:09:36
|
outgoing interface to get back to the source
|
|
0:09:38
|
then the reverse path forwarding check passes.
|
|
0:09:43
|
If for some reason the incoming interface for the multicast feed does not
|
|
0:09:46
|
match the outgoing unicast interface back to the source
|
|
0:09:51
|
then the RPF check fails and the packet is going to be dropped.
|
|
0:09:57
|
So this is an additional data plane protection mechanism
|
|
0:10:01
|
that if for some reason IGP does not build in the loop-free
|
|
0:10:04
|
topology or PIM was not able to build the loop-free
|
|
0:10:07
|
tree that we're going to make sure that the packets do not
|
|
0:10:10
|
loop over and over and over as they're sent through the network.
|
|
0:10:14
|
Now a basic case where this would be needed let's
|
|
0:10:16
|
say again that we have a server that's located on
|
|
0:10:19
|
VLAN 9
|
|
0:10:21
|
and we are running PIM dense mode on every interface in the network.
|
|
0:10:26
|
So Switch 3 when it receives the packets in from the server, it's
|
|
0:10:29
|
going to flood them out VLAN 79
|
|
0:10:32
|
When Switch 1 receives them, it's going to flood them out
|
|
0:10:34
|
VLAN 7, 67 and Fast Ethernet 0/3
|
|
0:10:41
|
Router 3 is going to flood this to routers 1, 2 and 5
|
|
0:10:45
|
1 is going to flood this to 6, 4 and 5
|
|
0:10:50
|
6 is going to flood it to 4 and 1
|
|
0:10:54
|
4 is going to flood it to 5 5 is going to flood it back to
|
|
0:10:57
|
3 back to 1 back to 4
|
|
0:11:01
|
so we see that there's a couple portions of the topology here
|
|
0:11:04
|
where the traffic is actually looping.
|
|
0:11:05
|
From 6 it's going out to 1 but from 1 it's going back to 6
|
|
0:11:10
|
From 4 it's going to 5, but from 5 it's going back to 4
|
|
0:11:16
|
So technically, PIM can build the tree as a looped topology
|
|
0:11:23
|
and the RPF check should then ultimately figure out
|
|
0:11:27
|
which interfaces should or should not be used for
|
|
0:11:29
|
that particular sender.
|
|
0:11:31
|
So in the case that Router 1 sends the packet out to Router 6
|
|
0:11:35
|
Router 6 is going to say look at the incoming interface
|
|
0:11:39
|
of Fast Ethernet 0/0.146
|
|
0:11:42
|
and let's assume that the source of the packet is
|
|
0:11:46
|
155.28.9.100
|
|
0:11:51
|
so this is some server that's on that LAN segment.
|
|
0:11:55
|
Router 6 is going to say what is my unicast route to
|
|
0:11:58
|
reach 155.28.9.100
|
|
0:12:02
|
if my route points out this link, then it's fine
|
|
0:12:05
|
I would be able to receive the multicast packets in.
|
|
0:12:08
|
But if my route points out this direction, the outgoing
|
|
0:12:13
|
unicast interface does not match the incoming multicast interface
|
|
0:12:19
|
so the packet would then be dropped as it came in from Router 1
|
|
0:12:26
|
So essentially even if the tree is built in a looped fashion
|
|
0:12:30
|
the data plane is going to figure out which interfaces
|
|
0:12:33
|
should or should not be used for forwarding based
|
|
0:12:35
|
on the underlying unicast routing table.
|
|
0:12:39
|
Now we'll see that a lot of the problems in
|
|
0:12:41
|
the actual end design for multicast are going to be
|
|
0:12:44
|
related to problems with the reverse path forwarding check
|
|
0:12:48
|
so we'll spend a bunch of time looking at cases where the
|
|
0:12:51
|
RPF check fails and we need to fix it either by changing the
|
|
0:12:55
|
unicast routing by doing static multicast routes or
|
|
0:12:58
|
by doing multicast BGP in order to allow us to receive traffic
|
|
0:13:02
|
from that particular source.
|
|
0:13:05
|
Then our final step in the data plane for forwarding is
|
|
0:13:08
|
going to be based on the multicast routing table.
|
|
0:13:11
|
Now when PIM is exchanging its messages, the join messages
|
|
0:13:15
|
and the prune messages to figure out how to build the
|
|
0:13:18
|
multicast tree, the multicast routing table is then used to
|
|
0:13:22
|
keep track of what are the incoming interfaces
|
|
0:13:26
|
for the particular sender and what are the outgoing
|
|
0:13:29
|
interfaces that go down to the receivers.
|
|
0:13:33
|
In the multicast routing table, we're going to denote this two
|
|
0:13:36
|
different ways, the interface that faces towards the source
|
|
0:13:40
|
is considered the upstream interface for that feed
|
|
0:13:43
|
and it's considered the incoming interface.
|
|
0:13:48
|
The other links that face downstream towards the receivers
|
|
0:13:52
|
those make up what's known as the outgoing interface list or
|
|
0:13:55
|
the OIL.
|
|
0:13:57
|
So under a normal loop-free topology, traffic should always
|
|
0:14:02
|
be coming in the incoming interface and then going
|
|
0:14:05
|
out all the interfaces in the outgoing interface list.
|
|
0:14:11
|
We'll also see that there's a basic split-horizon like
|
|
0:14:14
|
behavior that multicast uses to make sure that
|
|
0:14:17
|
an interface is not listed both in the incoming and the
|
|
0:14:20
|
outgoing interface list at the same time.
|
|
0:14:23
|
Now where this is going to cause some problems in our design
|
|
0:14:26
|
is that if we have a multipoint non-broadcast interface
|
|
0:14:31
|
where Router 5 needs to receive a multicast feed in from
|
|
0:14:35
|
Router 2 and then forward it back out the same interface to
|
|
0:14:38
|
Router 3 or Router 1 or Router 4
|
|
0:14:41
|
there's some design cases where that's simply not going to
|
|
0:14:44
|
work with PIM.
|
|
0:14:48
|
So in general, when we're looking at the Layer 2
|
|
0:14:51
|
design of the network if we're running multicast
|
|
0:14:55
|
over the network between the routers it's best to have
|
|
0:14:58
|
point to point segments where PIM is enabled on
|
|
0:15:02
|
every possible link.
|
|
0:15:05
|
So on the frame relay connection between
|
|
0:15:07
|
Router 2 and Router 5 here
|
|
0:15:10
|
we would ideally want this to be configured as
|
|
0:15:13
|
a point to point sub interface
|
|
0:15:15
|
that has a separate subnet assigned then the link that goes
|
|
0:15:21
|
to Router 4 and 5 or the link that goes from 1 to 5
|
|
0:15:25
|
and from 3 to 5
|
|
0:15:28
|
Now once the multicast routing table is populated based on the
|
|
0:15:31
|
PIM join messages and the PIM prune messages
|
|
0:15:35
|
if the reverse path forwarding check passes
|
|
0:15:40
|
we're going to prefer any entry that is an S,G
|
|
0:15:45
|
so this is both the sender and the receiver
|
|
0:15:48
|
versus a *,G which is just the receivers
|
|
0:15:52
|
without knowing who the sender is.
|
|
0:15:55
|
So the S,G is used to denote the source
|
|
0:15:59
|
tree where the *,G is used to denote the shared tree.
|
|
0:16:04
|
So in the routing table we would always prefer the
|
|
0:16:06
|
source tree over the shared tree.
|
|
0:16:10
|
Once we figure out which entry we're going to use
|
|
0:16:13
|
whether we have an S,G entry or whether we have
|
|
0:16:15
|
just a less specific *,G
|
|
0:16:18
|
then the router should switch the packet from the incoming
|
|
0:16:21
|
interface to all interfaces in the outgoing interface list.
|
|
0:16:26
|
So the key point with multicast is that from the application point of view
|
|
0:16:31
|
there's only one packet going out. It's up to the network
|
|
0:16:35
|
to do the replication and the router is doing that replication
|
|
0:16:38
|
by saying as the packet comes in the incoming interface
|
|
0:16:40
|
I'm going to do a Layer 3 replication as it goes towards the
|
|
0:16:44
|
outgoing interface list.
|
