|
0:00:13
|
Our last topic here for multicast is IPv6 multicast routing
|
|
0:00:19
|
which we'll see is fairly similar to IPv4 multicast routing
|
|
0:00:23
|
with the exception of the changes in the Layer 3 addressing.
|
|
0:00:28
|
So in the case of IPv4 multicast we were using protocol independent
|
|
0:00:32
|
multicast for the router to router communication
|
|
0:00:35
|
same is going to be true with IPv6 multicast.
|
|
0:00:39
|
At IPv4 we were using IGMP from the host to the
|
|
0:00:42
|
router signaling for the host to tell the router what particular
|
|
0:00:46
|
group addresses it wants to receive.
|
|
0:00:48
|
In the case of IPv6 this is the multicast listener discovery
|
|
0:00:52
|
or MLD protocol stack that is part of the ICMPv6
|
|
0:00:58
|
protocol of IPv6
|
|
0:01:01
|
so it's actually natively built into ICMP.
|
|
0:01:05
|
Now again, just like the other IPv6 topics that we talked about
|
|
0:01:09
|
the big hurdle to get over with this is the format of the
|
|
0:01:12
|
addressing. Now if you actually look at the RFC specification
|
|
0:01:16
|
for IPv6 multicast, it uses a fairly complex design of how
|
|
0:01:22
|
the address is supposed to be allocated where it's going to
|
|
0:01:26
|
start with the first two digits as FF
|
|
0:01:31
|
so in binary it's eight 1s
|
|
0:01:36
|
followed by flags and then the scope value.
|
|
0:01:39
|
So this means essentially there's a 112 bits left over for the multicast
|
|
0:01:43
|
groups. Now the scope is going to be like whether we're talking
|
|
0:01:48
|
about link local scope or site local scope or global scope
|
|
0:01:52
|
where the previous addresses that we looked at things like
|
|
0:01:55
|
the OSPF multicast, FF02::5 or ::6
|
|
0:02:01
|
RIP using FF02::9, EIGRP using A
|
|
0:02:06
|
these are considered the link local scope which means
|
|
0:02:09
|
that they're not supposed to be routed between interfaces.
|
|
0:02:14
|
For things that are considered site local would be the DHCP servers
|
|
0:02:18
|
or the DHCP relays or basically all router within the entire site
|
|
0:02:23
|
this would be a scope of five.
|
|
0:02:26
|
But the key with the scope values they're technically
|
|
0:02:30
|
not enforced automatically in the IOS.
|
|
0:02:37
|
So we do have the different definitions where the scope of
|
|
0:02:40
|
one is going to be the node like FF01::1 is the local node.
|
|
0:02:47
|
Two is the link, five is the site, E is global
|
|
0:02:50
|
so for an actual globally routable IPv6 multicast address
|
|
0:02:55
|
usually it's going to be FF0E
|
|
0:03:00
|
Then we have the flags that are whether this is coming from
|
|
0:03:05
|
an embedded rendezvous point address
|
|
0:03:09
|
that is used in the case where we're not doing the rendezvous point
|
|
0:03:11
|
address assignment automatically through BSR or we're doing it
|
|
0:03:16
|
in a static assignment, the actual sender can encode inside the
|
|
0:03:21
|
IPv6 multicast address who the rendezvous
|
|
0:03:24
|
point is supposed to be and this is known as the embedded RP.
|
|
0:03:30
|
For the T bit it says if T is 1 it's a temporary.
|
|
0:03:35
|
Most of the time this is going to be a zero, but again
|
|
0:03:37
|
these flags and scope it technically -- it could be whatever you want
|
|
0:03:43
|
unless it's actually a globally routable address on the internet.
|
|
0:03:46
|
So for some application that's going to be given an address
|
|
0:03:50
|
by IENA, then they're going to decide what the flags are
|
|
0:03:53
|
and what the scope is supposed to be
|
|
0:03:54
|
but for our purposes just for within the network it's not
|
|
0:03:58
|
really going to matter what the flags and the scope are.
|
|
0:04:00
|
So if we were to use E as the global scope
|
|
0:04:04
|
we could say FF0E and theoretically that should be able
|
|
0:04:09
|
to be routed between any of the sites.
|
|
0:04:12
|
Now PIM for IPv6 is similar to PIM version 2 for IPv4
|
|
0:04:20
|
main difference is that it does not support dense mode.
|
|
0:04:24
|
So IPv6 multicast uses sparse mode only.
|
|
0:04:28
|
Configuration wise, technically it's only one command in order to
|
|
0:04:31
|
enable the process.
|
|
0:04:33
|
If we say ipv6 multicast-routing globally
|
|
0:04:37
|
and this is automatically going to enable multicast listener discovery
|
|
0:04:40
|
on all of the attached interfaces.
|
|
0:04:45
|
Now previously when we looked at IPv4 PIM
|
|
0:04:49
|
one of the design issues is that if there is a disconnect
|
|
0:04:52
|
between your IGP interfaces and your PIM interfaces
|
|
0:04:57
|
generally that's when you run into the RPF failure.
|
|
0:05:01
|
So in IPv6 multicast routing, they're trying to prevent this
|
|
0:05:04
|
by saying as soon as you turn multicast routing on
|
|
0:05:07
|
it's essentially going to be on every single interface
|
|
0:05:10
|
that you're already routing IPv6
|
|
0:05:14
|
The only thing you would need to do at the link level is
|
|
0:05:16
|
disable PIM if you did not want to run it on that particular interface.
|
|
0:05:21
|
But then just like in normal IP multicast routing,
|
|
0:05:24
|
you do have the potential of dropping traffic based on the
|
|
0:05:26
|
reverse path forwarding if you have a difference in your
|
|
0:05:30
|
IGP enabled interfaces versus your PIM enabled interfaces.
|
|
0:05:35
|
So just like in IPv4 we have PIM as the router to router signaling.
|
|
0:05:40
|
For the end host to router signaling, we're replacing
|
|
0:05:44
|
IGMP with the multicast listener discovery
|
|
0:05:47
|
which is now part of ICMPv6
|
|
0:05:51
|
Again, once IPv6 multicast routing is enabled globally
|
|
0:05:56
|
MLD is automatically going to be on all interfaces
|
|
0:05:59
|
where PIM is running.
|
|
0:06:02
|
So as long as we say IPv6 multicast routing, we could look at
|
|
0:06:05
|
the show ipv6 mld interfaces it's going to show us that
|
|
0:06:08
|
for all the local links we are running the protocol.
|
|
0:06:13
|
Now just like IGMP version 2 and IGMP version 3
|
|
0:06:16
|
there's two different versions of MLD.
|
|
0:06:19
|
One of them supports only *,g joins where MLD version 2
|
|
0:06:26
|
this supports s,g joins.
|
|
0:06:29
|
So the same logic of the registration process
|
|
0:06:33
|
of the join from the receiver up to the RP
|
|
0:06:36
|
then the RP back to the sender. It's going to be the same
|
|
0:06:39
|
between IP version 4 PIM and IP version 6 PIM.
|
|
0:06:43
|
The only main difference is that there's sparse mode only
|
|
0:06:46
|
there is no dense mode.
|
|
0:06:51
|
There's a question here, "Can NTP be multicast in IPv6?"
|
|
0:06:54
|
I'm not a 100 percent sure if they have implemented that yet
|
|
0:06:58
|
but I know there is a specification for it. If you look under the
|
|
0:07:03
|
the configuration guide for IPv6
|
|
0:07:07
|
that's where the multicast would be located
|
|
0:07:09
|
so let's go to the main configuration guide
|
|
0:07:14
|
then IPv6 configuration.
|
|
0:07:18
|
Let's look at NTP and also multicast.
|
|
0:07:24
|
So let's see in NTP actually you can.
|
|
0:07:42
|
It says that for NTP version 4 for IPv6, multicast messages
|
|
0:07:46
|
instead of broadcast messages are used to send and receive the
|
|
0:07:49
|
the clock updates.
|
|
0:07:52
|
So basically the idea behind this is pretty much every
|
|
0:07:54
|
device in the network should be running NTP anyways
|
|
0:07:57
|
so there's no reason that the NTP server needs to be
|
|
0:08:00
|
sending tons of unicast messages down to the
|
|
0:08:03
|
nodes in the network.
|
|
0:08:04
|
So for IPv4 you can configure the router as an NTP multicast client
|
|
0:08:11
|
and then likewise in IPv6 now it supports it as well.
|
|
0:08:15
|
For the rest of the multicast configurations if you look at
|
|
0:08:19
|
the examples here, there's really not much that you can do
|
|
0:08:21
|
with the protocol.
|
|
0:08:23
|
So if you look at configuring PIM, basically look at
|
|
0:08:27
|
the configuration task list here. It's says that
|
|
0:08:41
|
let's see this says configuring PIM
|
|
0:08:48
|
it says go to enable mode go to global config
|
|
0:08:53
|
IPv6 PIM, specify the rendezvous point address
|
|
0:08:56
|
ok, it also supports bidirectional PIM
|
|
0:09:01
|
basically that's the only command here so the rest of them are show
|
|
0:09:04
|
commands. The only thing else you would do is just configure the rendezvous point globally.
|
|
0:09:08
|
It does also support BSR same type of logic as IPv4
|
|
0:09:14
|
multicast where you have the bootstrap router that is in charge
|
|
0:09:17
|
of the mappings between the rendezvous points and the groups.
|
|
0:09:21
|
And then the RP candidates that are going to be the actual
|
|
0:09:24
|
devices that are the rendezvous points, so if you look at the examples
|
|
0:09:28
|
for this let's say
|
|
0:09:34
|
configuring PIM
|
|
0:09:36
|
there should be an example of BSR here let's try down
|
|
0:09:44
|
configuration examples
|
|
0:09:50
|
then from here search for BSR.
|
|
0:10:06
|
So somewhere in this document, it does show the syntax examples
|
|
0:10:10
|
but if we were to look at this on the command line
|
|
0:10:12
|
basically the only thing that you need to do and what I have
|
|
0:10:16
|
right now in the topology is from Switch 1
|
|
0:10:22
|
transiting this way down to Switch 2
|
|
0:10:25
|
IPv6 is enabled on all of these transit interfaces.
|
|
0:10:28
|
So between Router 6 and Switch 1, I have 2001:67::/64
|
|
0:10:37
|
this link is 2001:146::/64
|
|
0:10:42
|
this is 2001:45
|
|
0:10:48
|
and this is 2001:58
|
|
0:10:56
|
then of course since PIM does not exchange its own
|
|
0:10:58
|
topology information, it's assuming we have some
|
|
0:11:01
|
underlying IGP
|
|
0:11:03
|
which in this case I simply have RIPNG enabled on all of the interfaces.
|
|
0:11:07
|
So if we were to go to Switch 1
|
|
0:11:11
|
and look at the show ipv6 route
|
|
0:11:16
|
we have routing information that is going to take us all the way
|
|
0:11:18
|
down to 2001:58::8 which is Switch 2
|
|
0:11:25
|
If we were to trace this path, this should be going from us
|
|
0:11:28
|
to Router 6 to Router 4 to Router 5 and then down to Switch 2
|
|
0:11:39
|
So next on the routers in the transit path which are
|
|
0:11:42
|
6, 4 and 5
|
|
0:11:46
|
once multicast routing is enabled for unicast
|
|
0:11:49
|
the only other thing we would need to do is say ipv6 multicast
|
|
0:11:54
|
ipv6 multicast-routing
|
|
0:12:00
|
so we'll do this on 5
|
|
0:12:03
|
and 4
|
|
0:12:13
|
if we now look at the show ipv6 pim neighbors
|
|
0:12:19
|
it says we have an adjacency with some link local address
|
|
0:12:24
|
over serial 0/1/0
|
|
0:12:27
|
which is going to be Router 4
|
|
0:12:32
|
then Router 4 should have an adjacency with 5 and 6
|
|
0:12:35
|
show ipv6 pim neighbors
|
|
0:12:39
|
so just like the IGPs, it is using the link local addresses on the
|
|
0:12:44
|
interfaces, so you don't necessarily need global
|
|
0:12:47
|
unicast configured on the transit network between the
|
|
0:12:50
|
routers. Really the only requirement of global unicast
|
|
0:12:54
|
is what the end hosts are going to be assigned.
|
|
0:12:58
|
Now since we are running in sparse mode, it implies that
|
|
0:13:02
|
we're going to be assigning the rendezvous point
|
|
0:13:06
|
so we can do this either by statically configuring
|
|
0:13:09
|
with the IPv6 PIM RP address
|
|
0:13:12
|
or we could use bootstrap router.
|
|
0:13:16
|
So again, just like IPv4 we have the candidate RPs and we have
|
|
0:13:19
|
the BSR.
|
|
0:13:23
|
Now in this particular case I have Router 4
|
|
0:13:25
|
with a loopback address that is 2001::4/128
|
|
0:13:34
|
so assuming that we can reach this from IGP everywhere
|
|
0:13:37
|
if we were to go to Router 6
|
|
0:13:40
|
and ping 2001
|
|
0:13:43
|
2001::4
|
|
0:13:45
|
we have reachability to that address.
|
|
0:13:48
|
So now on everyone I'm going to simply say ipv6 pim rp address is 2001::4
|
|
0:13:56
|
so both Router 4 and Router 5
|
|
0:14:00
|
are going to agree on this.
|
|
0:14:18
|
The verification for this is a little bit different than IPv4
|
|
0:14:22
|
instead of saying show ipv6 pim rp mappings
|
|
0:14:29
|
so this would be for the IPv4 syntax
|
|
0:14:34
|
we say show ipv6 pim range list
|
|
0:14:43
|
where we can see that there are some static source
|
|
0:14:46
|
specific multicast groups
|
|
0:14:49
|
that these are automatically assigned
|
|
0:14:53
|
here we have a static sparse mode rendezvous point that is 2001::4
|
|
0:14:58
|
which is for the rest of the multicast range which
|
|
0:15:02
|
is FF00::8
|
|
0:15:06
|
so basically anything that starts with FF is going to be multicast
|
|
0:15:09
|
now Router 4 is assigned as the rendezvous point for that.
|
|
0:15:14
|
If we were to go to any of the LAN interfaces let's say
|
|
0:15:17
|
on Router 5's Fast Ethernet 0/0
|
|
0:15:21
|
and we'll configure essentially any address of multicast
|
|
0:15:26
|
we could say ipv6 mld so again, this is replacing
|
|
0:15:31
|
IGMP ipv6 mld
|
|
0:15:33
|
I want to join a group we'll say FF0E because again
|
|
0:15:40
|
E is going to be the global scope, but it could technically
|
|
0:15:43
|
be anything here, so FF0E::1
|
|
0:15:48
|
if we now show ipv6 mld interfaces
|
|
0:15:56
|
we can see MLD is enabled
|
|
0:15:59
|
we have the timers for the query interval, the query
|
|
0:16:02
|
timeout, the max response time same type of logic as
|
|
0:16:05
|
IGMP version 2 and IGMP version 3
|
|
0:16:09
|
If we look at the show ipv6 mld groups
|
|
0:16:14
|
those are going to be the actual memberships
|
|
0:16:17
|
so in this interface there's actually two groups that are
|
|
0:16:19
|
assigned FF0D::1 FF0E::1
|
|
0:16:25
|
so those are simply two static join groups that are configured.
|
|
0:16:30
|
Now if we were to sent traffic to this let's say from
|
|
0:16:35
|
Switch 1
|
|
0:16:37
|
Switch 1 is going to ping 2000 -- or not 2000
|
|
0:16:41
|
ff0d::1
|
|
0:16:45
|
this is going to go out VLAN 67
|
|
0:16:52
|
and we get a response in from Router 5
|
|
0:16:55
|
so now in the transit path if we were to go to Router 4
|
|
0:16:59
|
who is the rendezvous point look at the show ipv6 mroute
|
|
0:17:06
|
it's the same type of logic.
|
|
0:17:08
|
It says that we have this particular source
|
|
0:17:11
|
sending to this particular group, the RPF neighbor is
|
|
0:17:14
|
that link local neighbor on Fast Ethernet 0/1
|
|
0:17:18
|
This is a sparse mode group and right now we're -- we are on the
|
|
0:17:21
|
shortest path tree.
|
|
0:17:23
|
So packets are coming in Fast Ethernet 0/1
|
|
0:17:26
|
we're forwarding the amount serial 0/1/0
|
|
0:17:30
|
So again, just like the other IPv6 protocols, if you're
|
|
0:17:34
|
familiar with the IP version 4 counterparts
|
|
0:17:37
|
then there's really not that much of a jump to get to IPv6 multicast.
|
|
0:17:42
|
Now there is one exception to this which is the feature known as embedded RP.
|
|
0:17:46
|
Basically the issue with this is that it uses a very complicated
|
|
0:17:50
|
conversion of a rendezvous point's address that is encoded inside
|
|
0:17:55
|
of the actual multicast address.
|
|
0:17:59
|
So for the BSR you can see from the commands here it's pretty
|
|
0:18:02
|
straightforward. We just specify who is the candidate RP
|
|
0:18:05
|
who's the candidate BSR.
|
|
0:18:09
|
The BSR normally is going to dynamically learn the rendezvous points
|
|
0:18:13
|
based on the unicast pim messages
|
|
0:18:15
|
if we wanted to override that for some reason, we could.
|
|
0:18:18
|
We can also specify what are the different ranges of groups
|
|
0:18:22
|
that the rendezvous points are going to service
|
|
0:18:28
|
and again, the embedded RP is going to allow the rendezvous point's
|
|
0:18:32
|
address to be encoded in the group itself.
|
|
0:18:36
|
So the advantage of this is that we do not need a static RP assigned
|
|
0:18:39
|
and we don't need BSR.
|
|
0:18:42
|
So the original logic for this is based on inter-AS multicast
|
|
0:18:47
|
that based on whoever the sender is using
|
|
0:18:52
|
as the rendezvous point in the group address
|
|
0:18:54
|
that's where the packet is going to be registered to.
|
|
0:19:00
|
Now the one caveat about this is that the rendezvous point
|
|
0:19:03
|
needs to know that itself is the RP
|
|
0:19:05
|
just like an IP version 4 multicast.
|
|
0:19:08
|
This would be configured statically on the device that is the embedded RP.
|
|
0:19:13
|
Now the problem is when we look at the conversion format
|
|
0:19:16
|
it uses this complex encoding
|
|
0:19:19
|
where it's FF7 followed by the scope. 0 then i is the 4 bit
|
|
0:19:27
|
RP's interface identifier.
|
|
0:19:29
|
So if the RP was 2001::4
|
|
0:19:36
|
then if we look at 4 in binary
|
|
0:19:40
|
that would be 0100
|
|
0:19:44
|
so in hex it's also 4
|
|
0:19:47
|
so this would be if we were to say it was global scope
|
|
0:19:50
|
which is D it would be FF7D04
|
|
0:19:54
|
then the 8 bit RP prefix length
|
|
0:19:58
|
where the prefix length is generally going to be /64
|
|
0:20:03
|
so then this would be 64 encoded in hex
|
|
0:20:07
|
so 64
|
|
0:20:13
|
64 in hex is going to be 40
|
|
0:20:17
|
followed by the prefix of the rendezvous point so that would be
|
|
0:20:19
|
their actual network, then the 32 bit group ID this is going to
|
|
0:20:23
|
be whatever we want for the actual multicast group.
|
|
0:20:25
|
So when we look at an example of a conversion for this
|
|
0:20:29
|
if the rendezvous point's address is 2001:1234:5678:ABCD::1
|
|
0:20:36
|
E is global scope -- I think I said D before it should be E for
|
|
0:20:40
|
global scope. The RP's interface identifier is one because that's what's
|
|
0:20:45
|
after ::1
|
|
0:20:48
|
/64 in hex is or /64 in decimal is 40 in hex
|
|
0:20:54
|
then we have the actual prefix which is 2001
|
|
0:20:57
|
1234:5678:ABCD
|
|
0:21:01
|
so then it finally ends up in that result FF7E:0140:2001
|
|
0:21:07
|
1234:5678:ABCD::1
|
|
0:21:13
|
Now the only issue with this is that I don't believe there's a
|
|
0:21:15
|
reference for this in the documentation
|
|
0:21:18
|
you would have to just search Cisco's website for
|
|
0:21:20
|
embedded RP for the document that talks about the conversion.
|
|
0:21:23
|
So I doubt that they're going to test on this in the exam
|
|
0:21:26
|
unless they already give you what the conversion is.
|
|
0:21:30
|
So it's not really fair for them to make you memorize
|
|
0:21:32
|
all these different hex conversions.
|
|
0:21:39
|
So essentially to test this out the only thing you would need to do
|
|
0:21:42
|
is just assign like a loopback that is 2001:1234:5678:ABCD::1
|
|
0:21:52
|
then send traffic to that particular group address
|
|
0:21:55
|
and the rendezvous point should automatically receive the registration.
|
|
0:22:00
|
Then of course when a client wants to actually receive it,
|
|
0:22:02
|
they would still need to send the MLD port message
|
|
0:22:06
|
saying I want to receive traffic for this particular group.
|
|
0:22:10
|
So generally if you spend some time just reading through
|
|
0:22:13
|
the basics of this document
|
|
0:22:16
|
which is the section here information about implementing
|
|
0:22:18
|
IPv6 multicast
|
|
0:22:21
|
the vast majority of the theory is pretty much the
|
|
0:22:25
|
same as the IPv6 counterparts.
|
|
0:22:28
|
Another feature just like an IPv4 we also have static
|
|
0:22:32
|
multicast routing. This would be used if we wanted to
|
|
0:22:35
|
override the reverse path forwarding check
|
|
0:22:37
|
for a particular source.
|
|
0:22:40
|
The difference in the syntax though is we're not saying
|
|
0:22:42
|
ipv6 mroute
|
|
0:22:44
|
we're doing a normal ipv6 route
|
|
0:22:46
|
but then adding the keyword multicast at the end.
|
|
0:22:51
|
So just like an IP version 4 this is used to change the
|
|
0:22:54
|
reverse path forwarding
|
|
0:22:57
|
which then in turn means it's going to change the
|
|
0:22:59
|
interface which the tree is going to be built out.
|
|
0:23:04
|
So if I have a unicast route out Fast Ethernet 0/0
|
|
0:23:08
|
but I want to build the tree out serial 0/0
|
|
0:23:12
|
I could point my multicast route out the serial link
|
|
0:23:14
|
and it means that's where I'm going to send my PIM join messages.
|