|
0:00:14
|
Welcome back everybody to internetwork expert CCIE routing and
|
|
0:00:17
|
switching advanced technologies class.
|
|
0:00:20
|
In today’s class sessions, we're going to be talking about
|
|
0:00:22
|
multicast both for IP version 4 and for IP version 6
|
|
0:00:27
|
and the goal of today's class session is going to be not only to
|
|
0:00:32
|
understand the individual components of multicast routing
|
|
0:00:36
|
both for IP version 4 and for IP version 6
|
|
0:00:39
|
mainly to figure out what are the different verification
|
|
0:00:41
|
techniques and what are the different troubleshooting
|
|
0:00:43
|
techniques that we can apply onto multicast within the
|
|
0:00:46
|
scope of the lab exam.
|
|
0:00:49
|
Now the key point that we'll see for multicast routing is that
|
|
0:00:52
|
the configuration syntax is generally pretty straightforward
|
|
0:00:56
|
the key is that we need to know what are the individual
|
|
0:00:59
|
components of both the multicast control plane
|
|
0:01:02
|
which is going to be used for things like IGMP
|
|
0:01:05
|
and PIM and MSDP in order to build the multicast routing for
|
|
0:01:09
|
the network, then ultimately the data plane that is going to
|
|
0:01:13
|
control how traffic is forwarded between the interfaces.
|
|
0:01:17
|
So any time that we run into problems with either the verification
|
|
0:01:20
|
or the individual portions of the control plane versus the
|
|
0:01:24
|
data plane, then we need to figure out where we can go
|
|
0:01:27
|
from there in our troubleshooting steps.
|
|
0:01:30
|
So we'll see it's kind of similar to how QoS is going to work
|
|
0:01:33
|
within this class that generally the configuration itself is pretty
|
|
0:01:37
|
straightforward, a lot of it has to do with just the overall
|
|
0:01:40
|
design of the network, interpreting what the questions are
|
|
0:01:43
|
asking for, then based on that figuring out what is the ultimate
|
|
0:01:47
|
solution that we're trying to implement.
|
|
0:01:50
|
Now first and foremost for IPv4 multicast we need to know
|
|
0:01:53
|
what are the addresses that we're going to be using
|
|
0:01:56
|
these are the numbers that fall into the class D address range
|
|
0:01:59
|
which are 224.0.0.0/4
|
|
0:02:03
|
where mainly this is going to be broken down into
|
|
0:02:06
|
the public multicast range and then three separate reserved
|
|
0:02:10
|
ranges which are the link local space of 224.0.0.0/24
|
|
0:02:17
|
this is where we would see our routing control plane protocols
|
|
0:02:20
|
or protocol independent multicast, things like 224.0.0.5 and 6 for OSPF
|
|
0:02:27
|
224.0.0.13 for PIM
|
|
0:02:31
|
then the all hosts and all routers multicasts 224.0.0.1
|
|
0:02:36
|
and 224.0.0.2
|
|
0:02:39
|
so to figure out exactly what type of protocols are
|
|
0:02:42
|
transiting between the routers' interfaces
|
|
0:02:44
|
when we're doing our troubleshooting,
|
|
0:02:45
|
it is a good idea to understand what are the pre-reserved
|
|
0:02:49
|
multicast numbers in the link local space.
|
|
0:02:54
|
A little bit later today, we'll get into source specific
|
|
0:02:56
|
multicast in which by default should use the range 232.0.0.0/8
|
|
0:03:02
|
which essentially means that the router will not
|
|
0:03:05
|
expect *,G join messages for any multicast addresses
|
|
0:03:10
|
in this particular range.
|
|
0:03:12
|
So we're going to be talking about what are the differences
|
|
0:03:14
|
between the different types of multicast trees
|
|
0:03:17
|
what's the difference between the shared tree for the
|
|
0:03:19
|
rendezvous point, the source tree or the shortest path tree
|
|
0:03:22
|
both for PIM dense mode, PIM sparse mode from the
|
|
0:03:26
|
rendezvous point to the source and then for source
|
|
0:03:30
|
specific multicast in PIM sparse mode from the source
|
|
0:03:34
|
all the way down to the receiver.
|
|
0:03:38
|
Then lastly we have the administratively scoped range
|
|
0:03:41
|
this could be considered the private addressing for multicast
|
|
0:03:44
|
so if there's any type of traffic flows that you don't want
|
|
0:03:47
|
to leave your network or you don't want to use a
|
|
0:03:49
|
reserved range or particularly allocated range
|
|
0:03:52
|
then you could use 239.0.0.0/8
|
|
0:03:57
|
Now it is important to note that the scoping here for the
|
|
0:04:00
|
addresses is not automatically enforced by the router
|
|
0:04:04
|
so this means that if you want 220 -- or 239.0.0.0/8
|
|
0:04:08
|
not to be forwarded out particular interfaces, then we
|
|
0:04:12
|
are going to have to manually configure that.
|
|
0:04:13
|
So there's no actual enforcement in the data plane of what the scoping is.
|
|
0:04:18
|
We'll also see that this is going to be true for
|
|
0:04:21
|
IPv6 multicast so in the addresses themselves
|
|
0:04:26
|
there's an encoding of whether the packets are supposed to be
|
|
0:04:28
|
forwarded between local links, whether they're supposed to be
|
|
0:04:31
|
forwarded within the local site or globally
|
|
0:04:36
|
but technically there is no enforcement of the scoping
|
|
0:04:38
|
in the data plane, so we would have to manually
|
|
0:04:41
|
do that with access lists or any type of filtering
|
|
0:04:44
|
to make sure that the packets are not going to portions of the
|
|
0:04:46
|
network that we do not want them to.
|
|
0:04:48
|
Now the control plane in multicast is what we're going to be
|
|
0:04:52
|
using to figure out how should traffic be routed through the
|
|
0:04:55
|
network so this is analogous to the normal unicast routing
|
|
0:05:00
|
control plane where we're using protocols like OSPF
|
|
0:05:03
|
or EIGRP for the routers to figure out how would we normally
|
|
0:05:06
|
route the unicast packets between the interfaces.
|
|
0:05:09
|
This is ultimately what the multicast control plane is used to do.
|
|
0:05:13
|
Now specifically multicast needs to know who are the
|
|
0:05:17
|
senders in the network and what particular group addresses
|
|
0:05:20
|
are they sending to and also who are the receivers in the network.
|
|
0:05:26
|
So it's a little bit different forwarding paradigm than we see
|
|
0:05:29
|
versus unicast routing when in unicast the router generally
|
|
0:05:32
|
only cares about the destination of the packet where multicast
|
|
0:05:37
|
is going to use source based routing
|
|
0:05:40
|
because the router needs to know both who is the sender
|
|
0:05:42
|
of the packet and then also who is the receiver.
|
|
0:05:49
|
Once the router figures out both of these pieces of the puzzle
|
|
0:05:51
|
that's what it's going to use to build the multicast tree
|
|
0:05:54
|
and the multicast tree ultimately is going to control how the router
|
|
0:05:57
|
forwards the packets between the interfaces.
|
|
0:06:00
|
Again, we'll see that there's a couple different types of
|
|
0:06:02
|
trees that we can use, we can use shortest path
|
|
0:06:05
|
trees, we can use shared trees. It depends on
|
|
0:06:08
|
the mode of PIM and whether we are using source specific
|
|
0:06:12
|
multicast or just general *,G multicast.
|
|
0:06:17
|
Now specifically the protocols that we're going to look at for
|
|
0:06:20
|
building the multicast control plane are going to be
|
|
0:06:23
|
IGMP, PIM and MSDP
|
|
0:06:26
|
where IGMP is going to be from the host to the
|
|
0:06:29
|
router where our actual receiver whether it's a
|
|
0:06:33
|
Windows or Mac OS machine that's trying to receive a multicast feed
|
|
0:06:37
|
it could also be like an IPTV receiver
|
|
0:06:40
|
like an actual cable box that's hooked up to your TV
|
|
0:06:43
|
that's what's going to tell the router that's connected to
|
|
0:06:46
|
it on the LAN what particular group it wants to receive
|
|
0:06:49
|
and possibly from what particular sources it wants to receive it from.
|
|
0:06:55
|
Once the host tells the router what particular traffic it wants
|
|
0:06:58
|
then the routers are going to have to signal to each other
|
|
0:07:01
|
how do we actually get the traffic from the sender down to the receiver.
|
|
0:07:05
|
So mainly this is going to be done with PIM which is the
|
|
0:07:08
|
protocol independent multicast protocol. We'll also see
|
|
0:07:11
|
that some portions of the network might need the multicast
|
|
0:07:14
|
source distribution protocol or MSDP in order to figure out
|
|
0:07:18
|
who are the senders in the network.
|
|
0:07:22
|
Once the router builds the control plane
|
|
0:07:24
|
for multicast, then we can actually start to send the
|
|
0:07:28
|
traffic from the source of the multicast feed like
|
|
0:07:31
|
the multimedia server, the IPTV server
|
|
0:07:34
|
then down to the receivers.
|
|
0:07:37
|
Now multicast is kind of interesting different than
|
|
0:07:40
|
normal unicast routing where packets that are sent
|
|
0:07:44
|
in the data plane are going to trigger events in the
|
|
0:07:48
|
control plane where normally for unicast routing
|
|
0:07:52
|
whether we're dealing with OSPF or EIGRP
|
|
0:07:55
|
or BGP, the control plane is built separately
|
|
0:07:58
|
before we actually start to forward traffic.
|
|
0:08:02
|
So the routers figure out what are the different destinations in the
|
|
0:08:04
|
network, the Cef table is going to be built that's loaded at
|
|
0:08:07
|
the actual line card, then when the packets are
|
|
0:08:10
|
forwarded, the actual data plane like web browsing
|
|
0:08:14
|
doesn't really have anything to do with the routing protocols.
|
|
0:08:19
|
But we'll see in multicast the control plane in certain cases
|
|
0:08:23
|
is actually driven by the data plane so once packets are
|
|
0:08:27
|
received, then the router is going to signal the
|
|
0:08:30
|
other devices through either PIM or through
|
|
0:08:33
|
MSDP to figure out how the traffic needs to actually be routed.
|
|
0:08:37
|
Now specifically in the data plane, this is going to be
|
|
0:08:39
|
done with two main operations.
|
|
0:08:41
|
The first is going to be the reverse path forwarding check
|
|
0:08:44
|
this is what we'll use to make sure that there is not
|
|
0:08:47
|
a loop of the actual traffic flow.
|
|
0:08:50
|
So the router is going to say when I receive a packet
|
|
0:08:52
|
in a particular interface is that actually the
|
|
0:08:55
|
correct interface that I have predicted the packet should
|
|
0:08:58
|
come inbound and this ultimately is going to be
|
|
0:09:01
|
based on our underlying unicast routing.
|
|
0:09:05
|
Once the router figures out that the packet came in
|
|
0:09:07
|
the correct interface, then we're going to use
|
|
0:09:10
|
the multicast routing table to figure out where
|
|
0:09:12
|
the packet should be actually switched to.
|
|
0:09:17
|
Now what is generally different about the multicast routing table
|
|
0:09:20
|
versus the unicast routing table is that the multicast
|
|
0:09:24
|
table is used for source based routing where the
|
|
0:09:27
|
unicast routing table is generally based on destination based routing.
|
|
0:09:32
|
So we'll see that we're going to make different
|
|
0:09:34
|
decisions where the traffic is supposed to go
|
|
0:09:36
|
depending on the actual source of the packet.
|
|
0:09:40
|
Now additionally since we are having a one to many application
|
|
0:09:44
|
for multicast as opposed to one to one for unicast
|
|
0:09:48
|
we'll see that generally when the packet comes inbound, it can be
|
|
0:09:52
|
forwarded out multiple interfaces and ultimately the
|
|
0:09:55
|
multicast routing table is what is going to be controlling that.
|
|
0:10:01
|
So we'll look at the different verifications that we can do here
|
|
0:10:04
|
things like the show ip mroute, show ip mroute count
|
|
0:10:07
|
to see the actual numbers of the packet flows
|
|
0:10:11
|
the debug ip mpacket is going to show us similarly
|
|
0:10:14
|
to the debug ip packet
|
|
0:10:16
|
the actual real time flow between the interfaces
|
|
0:10:19
|
then things like the show ip rpf to figure out
|
|
0:10:23
|
if there's any type of problem in the reverse path
|
|
0:10:25
|
forwarding check for the data plane.
|
|
0:10:29
|
Now the first of the control plane protocols that we're going to look at
|
|
0:10:32
|
today is the internet group management protocol or IGMP
|
|
0:10:36
|
This is mainly used for the receiver of the multicast feed
|
|
0:10:40
|
to tell the routers on the LAN what particular traffic
|
|
0:10:43
|
that it actually wants to receive.
|
|
0:10:47
|
Now the end host can signal the router to tell it it wants
|
|
0:10:49
|
to receive traffic for a specific group
|
|
0:10:52
|
or for a specific source and group pair.
|
|
0:10:56
|
Now we denote those two in the multicast routing table
|
|
0:10:58
|
as either *,G entries which are considered traffic from
|
|
0:11:04
|
any source going to a particular group
|
|
0:11:07
|
or an S,G pair that is one particular source
|
|
0:11:11
|
going to one particular group.
|
|
0:11:15
|
Depending on which one the end host requests
|
|
0:11:18
|
it's going to be dependent on whether we're running
|
|
0:11:20
|
source specific multicast or not and that the particular
|
|
0:11:23
|
IGMP version that we're running is.
|
|
0:11:26
|
By default, the router is going to be running IGMP
|
|
0:11:28
|
version 2 when we enable protocol independent multicast
|
|
0:11:32
|
at the link level.
|
|
0:11:34
|
So syntax wise, there's no separate command that's actually
|
|
0:11:37
|
used to enable IGMP, once we say ip pim dense mode
|
|
0:11:41
|
or ip pim sparse mode or ip pim passive
|
|
0:11:44
|
then IGMP is implicitly going to be enabled on the interface.
|
|
0:11:50
|
In general, when you have segments that are going down to
|
|
0:11:53
|
your end hosts and there's only one router that is
|
|
0:11:57
|
servicing that LAN, that's when it would be appropriate
|
|
0:12:00
|
to issue the ip pim passive command.
|
|
0:12:03
|
So it's similar to the passive interface command in
|
|
0:12:06
|
EIGRP or OSPF where we're running the protocol on the
|
|
0:12:10
|
interface, but we're not sending control plane
|
|
0:12:13
|
packets out there like PIM hellos or EIGRP or OSPF hellos
|
|
0:12:18
|
which is going to make sure that the end host is not
|
|
0:12:20
|
learning the control plane information about the network.
|
|
0:12:24
|
So the ip pim passive command it would only be appropriate for an
|
|
0:12:29
|
interface that we're basically just trying to turn IGMP on
|
|
0:12:32
|
but we actually don't have routers that we need to
|
|
0:12:35
|
route on the segment between.
|
|
0:12:37
|
For any case that we're going down to the LAN, but there are
|
|
0:12:40
|
multiple routers on the segment, we would not be able to
|
|
0:12:44
|
run the link in passive mode. The reason why it has to
|
|
0:12:46
|
do with how we disable the querier check on the link
|
|
0:12:51
|
where essentially we can end up with multiple routers
|
|
0:12:54
|
forwarding duplicate packets onto the LAN.
|
|
0:12:58
|
So within the scope of our particular topology that we're going to look
|
|
0:13:01
|
at today, it would be appropriate for Router 5
|
|
0:13:05
|
on its connection to Fast Ethernet 0/1 to run this
|
|
0:13:07
|
link as PIM passive, but it wouldn't make sense for
|
|
0:13:11
|
routers 1, 4 and 6 to configure the VLAN 146 link as passive
|
|
0:13:16
|
because if there's multiple routers servicing that same LAN
|
|
0:13:19
|
we want to avoid the case where there's a server
|
|
0:13:22
|
on VLAN 9
|
|
0:13:26
|
whose packet's get received by Router 6
|
|
0:13:29
|
they get received by Router 1
|
|
0:13:31
|
then both of these devices forward the duplicate packets
|
|
0:13:34
|
down onto the LAN.
|
|
0:13:36
|
So in general, if there's more than one router on the segment, only
|
|
0:13:39
|
one of them should be in charge of doing the forwarding.
|
|
0:13:43
|
Depending on what type of mode that we're running PIM in
|
|
0:13:45
|
whether we're running dense mode or sparse mode or
|
|
0:13:48
|
source specific or bidirectional PIM, it's going to control who
|
|
0:13:52
|
is actually in charge of forwarding the traffic onto the link.
|
|
0:13:56
|
So again, once we enable the PIM process, that's
|
|
0:13:58
|
automatically going to enable IGMP, the default IGMP
|
|
0:14:02
|
version is going to be version 2
|
|
0:14:04
|
which means the router will not listen to source specific
|
|
0:14:07
|
join messages automatically.
|
|
0:14:11
|
So the router will allow a *,G join to come in
|
|
0:14:16
|
but not an S,G join.
|
|
0:14:19
|
So once we have PIM enabled on the interface, again
|
|
0:14:22
|
that's automatically going to enable IGMP
|
|
0:14:24
|
them the router is going to start listening for the IGMP
|
|
0:14:27
|
report messages which are essentially the joins
|
|
0:14:31
|
where the end host is telling the router what particular
|
|
0:14:34
|
traffic that it wants to receive.
|
|
0:14:37
|
So there's two different types of reports that we'll look at today
|
|
0:14:40
|
the *,G report which is for IGMP version 1 or 2
|
|
0:14:44
|
where the end host is basically saying I don't care where the
|
|
0:14:47
|
traffic comes from, I just care where it's going to.
|
|
0:14:52
|
So I want traffic for this particular group, but
|
|
0:14:54
|
I don't care if there's multiple servers that are sending traffic to that.
|
|
0:14:58
|
For IGMP version 3, the end host is going to ask not only
|
|
0:15:03
|
for the group for the traffic, but also for the sender.
|
|
0:15:08
|
We'll see that in the overall design, source specific multicast is
|
|
0:15:11
|
much more straightforward to implement than
|
|
0:15:14
|
dense mode or normal sparse mode with rendezvous points
|
|
0:15:19
|
because the end host since it already knows where the traffic
|
|
0:15:22
|
is coming from, we don't need an additional control plane
|
|
0:15:26
|
signaling mechanism like the rendezvous point
|
|
0:15:29
|
or the PIM register messages to figure out where the
|
|
0:15:31
|
senders are and where the receivers are.
|
|
0:15:37
|
Now the only limitation of this is that you're assuming
|
|
0:15:39
|
that the actual application has some knowledge about
|
|
0:15:43
|
who is supposed to send traffic into the network.
|
|
0:15:47
|
So a good example of this would be IPTV applications
|
|
0:15:50
|
where your cable box that's plugged into the TV is
|
|
0:15:53
|
the actual IPTV client where it's the IGMP version 3 client.
|
|
0:15:57
|
So when you change the channel on your TV
|
|
0:16:01
|
the cable box is sending an IGMP V3 report basically
|
|
0:16:05
|
saying I want this particular channel which is the group
|
|
0:16:08
|
to come from the source which is the IPTV server or the
|
|
0:16:12
|
media server.
|
|
0:16:14
|
But in order to do that, there's some sort of out of band signaling
|
|
0:16:17
|
mechanism that goes between the sender and the receiver
|
|
0:16:20
|
so they know who are the sources of traffic and then
|
|
0:16:22
|
who are the receivers of the traffic.
|
|
0:16:27
|
So in any case, the application does not know where the
|
|
0:16:30
|
traffic is going to come from in the first place
|
|
0:16:33
|
then they would use the *,G join as opposed to the S,G join
|
|
0:16:40
|
so the key is that for IGMP the report message is the same as
|
|
0:16:44
|
the join.
|
|
0:16:45
|
so syntax wise, we configure this on the router as
|
|
0:16:48
|
the ip igmp join or the ip igmp static command
|
|
0:16:52
|
technically it's not doing a join. The official name for
|
|
0:16:57
|
this is the report message, but the report message is when we're
|
|
0:17:00
|
trying to join a particular group.
|
|
0:17:02
|
Now again, generally this message is supposed to come
|
|
0:17:04
|
from the end host that is connected to the LAN
|
|
0:17:08
|
where it's actually going to be receiving the traffic.
|
|
0:17:11
|
Normally the router is not going to be an IGMP client
|
|
0:17:15
|
unless we're trying to do some sort of basic testing in the topology
|
|
0:17:19
|
to make sure that we can get traffic from the sender
|
|
0:17:21
|
down to a particular LAN segment.
|
|
0:17:24
|
Now we'll see that there's a couple of issues when we
|
|
0:17:26
|
try to do this verification from the routers themselves
|
|
0:17:30
|
because they were not originally designed to
|
|
0:17:33
|
be multicast senders and multicast receivers.
|
|
0:17:36
|
The router is designed just to be a transit device for
|
|
0:17:41
|
multicast. It means that the router is not going to be
|
|
0:17:43
|
sending the IPTV stream
|
|
0:17:46
|
or it's not actually going to be watching TV.
|
|
0:17:50
|
So we'll see that there's some certain cases that we
|
|
0:17:52
|
can run into that the network is configured correctly and the
|
|
0:17:55
|
design is correct, but we can't actually verify
|
|
0:17:58
|
it from the router itself.
|
|
0:18:00
|
We would need an actual application server to
|
|
0:18:02
|
send the packets and then some sort of receiver that
|
|
0:18:05
|
is generating the IGMP report message
|
|
0:18:07
|
in order to see if they're actually receiving the traffic.
|
|
0:18:12
|
And this can be really frustrating for a lot of people if you don't
|
|
0:18:15
|
understand the particular circumstances where you cannot
|
|
0:18:18
|
do the verification from the router, you can end up
|
|
0:18:21
|
wasting a bunch of time trying to fix a problem
|
|
0:18:24
|
that's not really there in the first place.
|
|
0:18:27
|
So we'll look at this specifically on the command line certain
|
|
0:18:29
|
cases where we know that the network is working
|
|
0:18:33
|
but we can't actually test it from the routers.
|
|
0:18:35
|
So there are some additional ways that we can go a little bit
|
|
0:18:38
|
further out of the way to try to get that to work
|
|
0:18:40
|
things like using the IP SLA agreement in order to
|
|
0:18:44
|
generate different UDP multicast feeds
|
|
0:18:47
|
but a lot of the times when you're testing this just with
|
|
0:18:49
|
ICM pings, that's not really a good indication of whether
|
|
0:18:53
|
the network is actually going to work or not.
|
|
0:18:56
|
So the ip igmp join message we'll see -- specifically the
|
|
0:19:01
|
ip igmp join group command
|
|
0:19:03
|
this is going to be used to test from the router
|
|
0:19:06
|
can it receive traffic to that particular segment.
|
|
0:19:09
|
But under normal circumstances in a real design, you wouldn't
|
|
0:19:12
|
use that command.
|
|
0:19:13
|
The second one the ip igmp static group
|
|
0:19:17
|
this is used to manually put the interface in the outgoing
|
|
0:19:21
|
interface list
|
|
0:19:23
|
for a particular group or for a particular source and group pair.
|
|
0:19:31
|
Now the reason that you would want to do that is
|
|
0:19:33
|
that if you know that particular LAN segment should always receive
|
|
0:19:36
|
that particular feed, then you would not need to rely on the
|
|
0:19:40
|
IGMP query messages which are basically the router
|
|
0:19:44
|
asking the end hosts do you still want to receive this traffic
|
|
0:19:48
|
so with the igmp static group command, we're not relying on the
|
|
0:19:52
|
query messages to converge whether the traffic should or
|
|
0:19:55
|
should not be forwarded to that link.
|
|
0:20:01
|
We'll also see that the functional difference between the
|
|
0:20:03
|
two is that with the ip igmp join group command
|
|
0:20:06
|
it's going to force the router to process switch the traffic
|
|
0:20:10
|
where the ip igmp static group would allow the traffic
|
|
0:20:12
|
still to be Cef switched.
|
|
0:20:14
|
So if you were doing this in an actual production design
|
|
0:20:17
|
and you want to manually force the router to forward
|
|
0:20:20
|
traffic for a group, you would want to use the igmp static group
|
|
0:20:23
|
static group command, not the ip igmp join group command.
|
|
0:20:28
|
Now we'll see that from this point on configuration wise
|
|
0:20:31
|
for IGMP, there's not really much more that you need to do
|
|
0:20:34
|
besides simply turning PIM on the interface
|
|
0:20:38
|
again, the only time you would say ip igmp join group
|
|
0:20:40
|
or ip igmp static group it's either you're just trying to do
|
|
0:20:44
|
basic testing of the deployment or you don't want to rely on
|
|
0:20:47
|
the end host to be running the query messages between the
|
|
0:20:51
|
router and the receiver.
|
|
0:20:55
|
So we'll see there's a bunch of minor things we can change
|
|
0:20:57
|
at the interface level to affect the convergence of
|
|
0:21:00
|
IGMP, for example the ip igmp query interval
|
|
0:21:03
|
this says how often is the router going to ask the
|
|
0:21:06
|
end hosts if you actually still want to receive the traffic.
|
|
0:21:10
|
So depending on what type of version we're running in IGMP
|
|
0:21:13
|
the router has a couple different types of queries where we can send
|
|
0:21:18
|
the general query that's going to go down to all end hosts
|
|
0:21:21
|
or we have the group specific query that says are there any
|
|
0:21:25
|
hosts that are listening for this particular destination
|
|
0:21:28
|
address, then if the end hosts don't want it, they're going to
|
|
0:21:32
|
send the query response back to the router saying yeah, I'm
|
|
0:21:35
|
still listening for that, don't prune the group off of the interface.
|
|
0:21:40
|
Now normally once the router sends the query message out
|
|
0:21:43
|
and it doesn't get a response within the query maximum response
|
|
0:21:46
|
time, then it's going to assume that no one else wants to receive that
|
|
0:21:50
|
particular traffic and it's going to prune the group off of the interface.
|
|
0:21:57
|
Now for IGMP version 2 and IGMP version 3, normally you
|
|
0:22:01
|
don't even need to do this because when the end host
|
|
0:22:04
|
is joining, they're going to explicitly tell the router
|
|
0:22:07
|
I want this particular traffic and then when they are done
|
|
0:22:10
|
with the traffic, they're going to send an explicit leave
|
|
0:22:13
|
saying I no longer want the traffic.
|
|
0:22:16
|
So in the case of IGMP version 2 and version 3
|
|
0:22:20
|
the only reason that you really need the query interval
|
|
0:22:23
|
and the query max response time is if the receiver basically
|
|
0:22:27
|
crashes and they don't send the explicit leave when they're
|
|
0:22:31
|
done using the group.
|
|
0:22:35
|
But like for an IPTV application, if it's your actual cable box
|
|
0:22:38
|
that's doing the IGMP version 3
|
|
0:22:41
|
every time you change the channel, it's going to send a
|
|
0:22:44
|
new IGMP report to listen for the new group and then it's
|
|
0:22:48
|
also going to send an IGMP explicit leave saying I'm done with the
|
|
0:22:51
|
previous channel.
|
|
0:22:55
|
Now in the case that there are multiple routers on
|
|
0:22:58
|
the segment that are servicing the same destination LAN
|
|
0:23:01
|
only one of them is going to be elected the querier
|
|
0:23:04
|
which essentially says they're in charge of asking the end hosts
|
|
0:23:07
|
if they actually still want that traffic.
|
|
0:23:11
|
So the router by default also has a querier timeout
|
|
0:23:14
|
that says if I am not the person in charge of doing the querying
|
|
0:23:18
|
so if there's some other router on the LAN that is the querier
|
|
0:23:22
|
if the querier timeout expires, it means that that router disappeared
|
|
0:23:27
|
so I need to start polling the end host to figure out if they still want the traffic.
|
|
0:23:34
|
So these type of commands you don't necessarily need to memorize
|
|
0:23:37
|
the syntax, within the scope of the exam, you could always go to the
|
|
0:23:40
|
command reference and look this type of stuff up to figure out
|
|
0:23:43
|
what are the default values, what are the different values that
|
|
0:23:45
|
I can change them to as long as you understand what are the
|
|
0:23:48
|
general features of IGMP and what are the different things that
|
|
0:23:51
|
we can change. Some additional convergence timers would be
|
|
0:23:56
|
how long we wait after the explicit leave is sent before we
|
|
0:24:01
|
send the query messages so this would be the last member
|
|
0:24:04
|
query interval and then how many queries do we have to miss before
|
|
0:24:08
|
we assume that no one else is actually listening for
|
|
0:24:10
|
that particular group or we could tell the router if we
|
|
0:24:14
|
hear an explicit leave, then automatically assume that there are
|
|
0:24:19
|
no other receivers on the link and prune the group without
|
|
0:24:22
|
sending a query.
|
|
0:24:24
|
So this feature, the ip igmp immediate leave, this is off by default
|
|
0:24:29
|
because normally once an end host says I'm done with this
|
|
0:24:32
|
particular group, the router is then going to ask does anyone
|
|
0:24:36
|
else on the segment still want this group.
|
|
0:24:43
|
So generally these type of modifications it's going to
|
|
0:24:46
|
control how quickly the router can prune
|
|
0:24:49
|
the group from actually being sent down to the LAN
|
|
0:24:53
|
which would then ultimately affect how quickly it can send
|
|
0:24:56
|
a PIM prune messages, send the PIM prune message upstream
|
|
0:25:00
|
to remove the feed from the actual routers' transit links.
|
|
0:25:06
|
So again, the signaling of the IGMP from the host to the
|
|
0:25:09
|
router, it's going to tell the router I want to receive
|
|
0:25:12
|
traffic for this particular group which will then trigger the
|
|
0:25:15
|
router to do its PIM join messages that are going to
|
|
0:25:19
|
build the multicast tree from the sender all the way down
|
|
0:25:22
|
to the receiver.
|
|
0:25:26
|
Then in source specific multicast the last one here
|
|
0:25:28
|
the ip igmp explicit tracking, this means that the router will
|
|
0:25:32
|
keep track of not only the source and group
|
|
0:25:35
|
on the link, but also all the individual receivers that
|
|
0:25:39
|
sent the IGMP report messages for, so if I know that there were
|
|
0:25:43
|
five receivers, then I get five explicit leaves one from each
|
|
0:25:48
|
of them, once I receive the fifth one, I automatically
|
|
0:25:52
|
know that there's no more receivers on the link
|
|
0:25:54
|
so I can prune the group immediately without having to
|
|
0:25:58
|
send the query messages and then wait for the query response.
|
|
0:26:03
|
So igmp explicit tracking, it kind of does the same thing as the
|
|
0:26:05
|
igmp immediate leave, but it prevents the case where there
|
|
0:26:09
|
are still people on the LAN that want the group
|
|
0:26:14
|
and we prune it before they can actually send the query response
|
|
0:26:19
|
message back, but again, the vast majority of these
|
|
0:26:26
|
features if we were to go to the documentation
|
|
0:26:29
|
let's go to the 12.4 T command reference
|
|
0:26:32
|
then down to multicast command reference
|
|
0:26:37
|
you'll see that for multicast as a whole, there's really not that
|
|
0:26:40
|
many features to begin with that you can even change
|
|
0:26:43
|
so if we look under the ip igmp access group
|
|
0:26:47
|
through ip igmp v3lite
|
|
0:26:49
|
pretty much this one page is all of the different options that you
|
|
0:26:53
|
can change with IGMP
|
|
0:26:56
|
things like filtering with an IGMP access group
|
|
0:26:59
|
or IGMP limit that's going to say how many groups you can
|
|
0:27:01
|
have on the interface.
|
|
0:27:03
|
The IGMP snooping stuff we'll talk about that a little bit later
|
|
0:27:06
|
this is related to Layer 2 multicast
|
|
0:27:10
|
so in the case for the IOS documentation, this would be
|
|
0:27:13
|
if we're running like a 7600
|
|
0:27:17
|
or a 6500 that's running the regular router IOS code
|
|
0:27:22
|
but they're also doing Layer 2 multicast switching
|
|
0:27:25
|
this is going to control how the router does the CAM table association
|
|
0:27:31
|
for the Layer 2 Mac addresses to the Layer 3 multicasts.
|
|
0:27:37
|
But in our case for the regular routers, the router is not going to
|
|
0:27:40
|
run IGMP snooping, it's going to be up to the Layer 2
|
|
0:27:42
|
switches' job in order to figure out when the packet
|
|
0:27:47
|
comes -- when the multicast packet comes in my Layer 2
|
|
0:27:49
|
switch port, what are the other interfaces I need to
|
|
0:27:52
|
send it to based on the multicast CAM table.
|
|
0:27:56
|
So a couple other minor features we have here
|
|
0:27:58
|
IGMP filtering with the IGMP access group, this would be
|
|
0:28:01
|
if we wanted to tell the host they can only join
|
|
0:28:04
|
the administratively scoped addresses or maybe we don't
|
|
0:28:07
|
want them using source specific multicast, so we could say
|
|
0:28:11
|
deny joins going to the 232.0.0.0/8
|
|
0:28:15
|
or only allow joins going to 239.0.0.0/8
|
|
0:28:19
|
which would be the administratively scoped
|
|
0:28:22
|
so by default, the router is not going to filter out whatever
|
|
0:28:24
|
report messages that are coming in the interface.
|
|
0:28:31
|
Then we can control how many groups could be joined
|
|
0:28:34
|
this would prevent any type of denial of service attack
|
|
0:28:37
|
against the router's control plane itself
|
|
0:28:40
|
because we'll see once the end host sends the IGMP
|
|
0:28:44
|
report to the router, it's going to force it to install
|
|
0:28:47
|
either a *,G entry in the routing table or an S,G
|
|
0:28:53
|
entry in the routing table depending on whether we
|
|
0:28:56
|
are running PIM in dense mode, sparse mode or source specific
|
|
0:29:03
|
so the potential problem that you could run into
|
|
0:29:05
|
if you are running multicast down to your LAN segment
|
|
0:29:09
|
and let's say on Router 5 on this Fast Ethernet 0/1, we're
|
|
0:29:13
|
running IGMP, we're listening for the hosts to send the
|
|
0:29:17
|
reports coming inbound.
|
|
0:29:19
|
If there's some sort of attacker on that segment
|
|
0:29:23
|
they could send IGMP report messages for every possible
|
|
0:29:27
|
multicast address so we know that the multicast
|
|
0:29:33
|
range is 224.0.0.0/4
|
|
0:29:40
|
so if the range is 224 let's see
|
|
0:29:44
|
224.0.0.0/4
|
|
0:29:49
|
this means that the host addresses can have how many
|
|
0:29:52
|
combinations here?
|
|
0:29:56
|
Well we know that the address is 32 bits long right?
|
|
0:30:01
|
So if the network portion is going to be the first four bits
|
|
0:30:03
|
it means that we have 28 bits for host addressing
|
|
0:30:08
|
so if we were to look at
|
|
0:30:17
|
2
|
|
0:30:19
|
let's see this is under scientific...
|
|
0:30:21
|
2 to the 28th
|
|
0:30:25
|
so this is how many possible multicast addresses that we could have
|
|
0:30:32
|
so the end host potentially they could send multicast
|
|
0:30:35
|
reports for all of them
|
|
0:30:37
|
and the end result is just that the router is going to
|
|
0:30:39
|
run on a memory in the routing table.
|
|
0:30:42
|
So to protect against this type of control plane attack
|
|
0:30:47
|
we generally would want to limit the number of
|
|
0:30:49
|
group addresses that can be received on the end link.
|
|
0:30:55
|
So if we know that it's never feasible for
|
|
0:30:57
|
them to receive more than a thousand groups or
|
|
0:31:00
|
it could be even some number less than that, generally you would
|
|
0:31:03
|
want to configure that as it goes down to the LAN.
|
|
0:31:06
|
Now additionally we could make the network even more
|
|
0:31:09
|
secure. Depending on the particular application that
|
|
0:31:12
|
we're trying to use like for high availability trading environments
|
|
0:31:17
|
where the application that is the receiver is some sort of
|
|
0:31:20
|
like stock ticker application, it may make sense that you
|
|
0:31:23
|
don't even want to run IGMP at all
|
|
0:31:28
|
that would be the case where you could effectively
|
|
0:31:31
|
filter out all of the join messages with an IGMP access group
|
|
0:31:37
|
but then go to the link level and configure the router with the
|
|
0:31:40
|
IGMP static group for the particular feeds that you
|
|
0:31:44
|
would want to send out that interface.
|
|
0:31:46
|
So then in that case, you're not listening for the
|
|
0:31:50
|
end host to trigger a join in the control plane
|
|
0:31:56
|
you're basically statically telling the router that I always want to be
|
|
0:31:59
|
part of the multicast tree for this particular group and it's
|
|
0:32:02
|
always going to be forwarded down to that particular LAN segment.
|
|
0:32:08
|
Now we'll talk about some other designs related to this today
|
|
0:32:11
|
like bidirectional PIM when the end hosts are both
|
|
0:32:15
|
senders and receivers for the application and that's
|
|
0:32:18
|
typical in a trading environment where the stock ticker application
|
|
0:32:23
|
is sending the trades out, but it also wants to receive the
|
|
0:32:26
|
trades in from the other end hosts. In that case
|
|
0:32:31
|
again, we would need to make sure that the size of the
|
|
0:32:33
|
multicast routing table doesn't get too big
|
|
0:32:37
|
so bidirectional PIM is a protection mechanism
|
|
0:32:40
|
against that basically to limit how many S,G entries that we can
|
|
0:32:45
|
install versus the *,G entries.
|
|
0:32:50
|
So we'll see when we get into the specifics, what are the
|
|
0:32:53
|
different types of trees for multicast, we'll see
|
|
0:32:56
|
when and why we should see the *,G in the routing table
|
|
0:33:00
|
versus the S,G, where the incoming interfaces are
|
|
0:33:04
|
supposed to point and then where the outgoing interfaces
|
|
0:33:06
|
are supposed to point.
|
