|
0:00:14
|
In our next section for multicast we're going to look at the three different
|
|
0:00:16
|
ways that the rendezvous point's addresses can be assigned
|
|
0:00:20
|
both statically and dynamically through either auto RP and BSR.
|
|
0:00:26
|
Now we saw with the configuration up to this point that without the
|
|
0:00:30
|
rendezvous point, the issues that we run into with sparse mode are
|
|
0:00:34
|
that the sources cannot tell the rendezvous point who are
|
|
0:00:37
|
or excuse me, the designated router cannot tell the rendezvous point
|
|
0:00:41
|
who are the sources in the network which means we would not be able to
|
|
0:00:44
|
install S,G entries and the receivers will not be able to have
|
|
0:00:49
|
their join messages processed which means there will not be the *,G entries
|
|
0:00:54
|
from the receiver up to the rendezvous point.
|
|
0:00:59
|
Now additionally we do need to make sure that all of the
|
|
0:01:01
|
routers within the domain agree on the rendezvous point's
|
|
0:01:05
|
address on a per group basis
|
|
0:01:08
|
because if a join message comes in and it is going to a different
|
|
0:01:12
|
rendezvous point than the originator had specified
|
|
0:01:16
|
then ultimately the tree is not going to be built to the proper address.
|
|
0:01:20
|
So from the receiver up to the rendezvous point, everyone
|
|
0:01:23
|
has to agree on what the value is and then from the
|
|
0:01:26
|
sender to the RP likewise everyone has to agree.
|
|
0:01:30
|
Now we also saw that the registrations and the join messages
|
|
0:01:33
|
would be rejected on the RP if it did not agree with the other
|
|
0:01:37
|
routers that it was supposed to service those particular groups.
|
|
0:01:41
|
So regardless which three of the mechanisms we're using to assign
|
|
0:01:44
|
them whether it's statically with auto RP or with BSR
|
|
0:01:48
|
we do need to make sure that everyone in the network agrees on this.
|
|
0:01:51
|
Now the simple way to verify it
|
|
0:01:54
|
is to go to the different routers and look at the show ip pim rp address
|
|
0:02:02
|
or actually show ip pim rp mapping
|
|
0:02:05
|
we see on Router 1 it says the for the groups 224.0.0.0/4
|
|
0:02:09
|
we have a static assignment of the address 1.2.3.5
|
|
0:02:16
|
The question mark here simply means that we do not have
|
|
0:02:19
|
a DNS resolution for the address
|
|
0:02:21
|
so if I were to say that the host R1 is the address 1.2.3.5
|
|
0:02:30
|
when we look at the show ip pim rp mapping
|
|
0:02:32
|
that's what this is referring to.
|
|
0:02:34
|
So you'll see that if you have domain lookup on and you don't
|
|
0:02:38
|
actually have a DNS server that's configured
|
|
0:02:41
|
when you look at the show ip pim rp mapping, the command is
|
|
0:02:43
|
going to hang when it tries to do the resolution of that particular address.
|
|
0:02:47
|
So either you could simply disable DNS lookup with the
|
|
0:02:51
|
no ip domain lookup command or you can actually give it a
|
|
0:02:54
|
DNS entry for that particular address.
|
|
0:02:58
|
Now in this particular case when we compare what Router 1
|
|
0:03:00
|
is saying to the other routers, we can see from the change that I did
|
|
0:03:04
|
previously, Router 1 is configured with the address 1.2.3.5 where
|
|
0:03:08
|
everyone else is configured with 1.2.3.4
|
|
0:03:11
|
since they don't agree
|
|
0:03:13
|
Router 1 is rejecting the PIM join messages
|
|
0:03:16
|
and it's also rejecting the registrations
|
|
0:03:19
|
where Router 5 is trying to say I have this particular source
|
|
0:03:23
|
sending to a group, Router 1 is not going to accept this.
|
|
0:03:30
|
So with our static configuration, this is pretty straightforward when we look at
|
|
0:03:33
|
the show run include pim
|
|
0:03:37
|
simply everyone in the domain should have identical statements that
|
|
0:03:40
|
specify who the RP the address is.
|
|
0:03:44
|
Now if we look at the detail under the end of this command
|
|
0:03:48
|
we can see that there are options for specifying the particular
|
|
0:03:52
|
group range that the rendezvous point services
|
|
0:03:55
|
so we could do multiple rendezvous points on a per group basis
|
|
0:03:58
|
this would allow us to do redundancy and load balancing for different
|
|
0:04:02
|
portions of the network. We could also specify
|
|
0:04:06
|
that the static address overrides the dynamic ones which is kind of
|
|
0:04:11
|
strange because by default, the dynamically information
|
|
0:04:14
|
does override the static one
|
|
0:04:17
|
whereas in most of the cases for IOS, a static configuration is going to
|
|
0:04:21
|
override dynamic, this is not the case with the rendezvous point address.
|
|
0:04:24
|
So this means if we learned an address through either auto RP
|
|
0:04:28
|
or BSR, that would override what I have here configured as the static
|
|
0:04:32
|
address of 1.2.3.4
|
|
0:04:40
|
Now specifically the two different dynamic protocols we have are
|
|
0:04:43
|
auto RP and BSR where the first one in auto RP is now
|
|
0:04:47
|
pretty much considered a legacy mechanism
|
|
0:04:51
|
it was the Cisco proprietary version of doing dynamic
|
|
0:04:53
|
advertisement before it was actually standardized in the
|
|
0:04:57
|
PIM version 2 specification.
|
|
0:04:59
|
We'll see that there's a lot of functional similarities between
|
|
0:05:02
|
auto RP and BSR, but behind the scenes the way that the
|
|
0:05:06
|
two protocols work are different, so just like
|
|
0:05:09
|
dot1q and ISL or LDP and TDP
|
|
0:05:12
|
they're not going to be compatible in their advertisements.
|
|
0:05:15
|
We could technically have some portions of the network run
|
|
0:05:18
|
auto RP, some portions of the network run BSR
|
|
0:05:20
|
but generally there's no advantage of that type of design.
|
|
0:05:25
|
Now in auto RP, there are two functional roles
|
|
0:05:27
|
the candidate RP and the mapping agent
|
|
0:05:30
|
where the candidate RP is the device or devices that
|
|
0:05:33
|
actually want to be the rendezvous point and the
|
|
0:05:36
|
mapping agent is the one that is going to choose between the different
|
|
0:05:39
|
candidates who actually is assigned on a per group basis.
|
|
0:05:46
|
Now in order to advertise this information, auto RP uses
|
|
0:05:49
|
two different multicast data plane addresses which are
|
|
0:05:53
|
224.0.1.39 and 224.0.1.40
|
|
0:05:59
|
where the candidate rendezvous points advertise themselves to the
|
|
0:06:02
|
mapping agent as 224.0.1.39
|
|
0:06:07
|
and the mapping agent is going to advertise the candidate RPs
|
|
0:06:10
|
down to everyone else as 224.0.1.40
|
|
0:06:16
|
Now the potential issue with this is that the mapping agent
|
|
0:06:21
|
must listen for 224.0.1.39 in order to hear about the candidate RPs.
|
|
0:06:27
|
And likewise, everyone else must listen to 224.0.1.40
|
|
0:06:31
|
in order to learn the information that the mapping agent is advertising.
|
|
0:06:36
|
But the problem is we run into kind of a recursive logic with
|
|
0:06:39
|
sparse mode that it says we cannot join these two groups
|
|
0:06:43
|
unless we know a rendezvous point of where to send the join messages.
|
|
0:06:48
|
But since we don't know who the rendezvous point is
|
|
0:06:51
|
we can't actually join the group.
|
|
0:06:55
|
So with normal sparse mode configured on the interface
|
|
0:06:58
|
if we enable auto RP with both the candidate RP
|
|
0:07:02
|
and the mapping agent, unless they are physically connected
|
|
0:07:06
|
essentially unless everyone is physically connected in a full
|
|
0:07:09
|
physical mesh, then none of the devices are going to learn about
|
|
0:07:12
|
the rendezvous points, so we need to figure out a couple different
|
|
0:07:15
|
ways that we can actually get these two group addresses
|
|
0:07:18
|
224.0.1.39 from the candidate RPs to the mapping agent
|
|
0:07:23
|
then from the mapping agent get the destination address
|
|
0:07:26
|
224.0.1.40 down to everyone else.
|
|
0:07:32
|
Now as I mentioned, the dynamically learned information will be preferred
|
|
0:07:36
|
over any statically configured ones, so this would then mean
|
|
0:07:41
|
from a security point of view if the network is running
|
|
0:07:44
|
static rendezvous point assignments and we do not want auto RP or
|
|
0:07:48
|
BSR, we generally would want to use the override command on the
|
|
0:07:51
|
ip pim rp address command to make sure that no other
|
|
0:07:56
|
device starts advertising either a BSR or an auto RP
|
|
0:08:00
|
into the network.
|
|
0:08:02
|
Additionally, we'll see that the auto RP messages are subject
|
|
0:08:06
|
to the RPF check in the date plane.
|
|
0:08:10
|
So if for some reason we do not have the correct
|
|
0:08:12
|
route back to the candidate RPs or to the mapping agent
|
|
0:08:15
|
then those packets could potentially get dropped
|
|
0:08:17
|
and we would not be able to learn who the rendezvous point is.
|
|
0:08:29
|
Now again, since everyone in the network needs to join the
|
|
0:08:31
|
224.0.1.40 network -- address
|
|
0:08:35
|
and the mapping agent needs to join 224.0.1.39
|
|
0:08:40
|
we need to figure out a couple different ways to do this other than just
|
|
0:08:42
|
using normal sparse mode at the interface level
|
|
0:08:46
|
because again, we run into that type of recursive logic
|
|
0:08:49
|
where to join the groups, we need to know the RP
|
|
0:08:52
|
but to know the RP, we need to join the groups to begin with.
|
|
0:08:57
|
So one possible solutions to this is to configure statically a
|
|
0:09:00
|
default rendezvous point that would be used for the registration
|
|
0:09:05
|
messages of 224.0.1.39 and 224.0.1.40 and
|
|
0:09:10
|
to send the PIM join messages in order for us to receive
|
|
0:09:14
|
the actual traffic flow inbound.
|
|
0:09:17
|
But since we're trying to do the advertisements dynamically
|
|
0:09:20
|
it kind of defeats the purpose of the design to configure
|
|
0:09:23
|
static rendezvous points just to allow us to join the groups
|
|
0:09:26
|
to learn a dynamic rendezvous point.
|
|
0:09:31
|
So technically you can do that if you look in the volume 1 workbook
|
|
0:09:34
|
there's some examples of using the default RP placement
|
|
0:09:38
|
but generally the other two options either running in PIM
|
|
0:09:41
|
sparse-dense mode or enabling the auto RP listener
|
|
0:09:45
|
are going to be a little bit more feasible in the design
|
|
0:09:47
|
where in the case of PIM sparse-dense mode
|
|
0:09:51
|
since these two groups 224.0.1.39 and 224.0.1.40
|
|
0:09:56
|
do not have a rendezvous point assignment, it means that
|
|
0:10:00
|
automatically they are going to fall back to dense mode.
|
|
0:10:06
|
Now the auto RP listener feature is similar to sparse-dense mode
|
|
0:10:10
|
with one exception.
|
|
0:10:12
|
Sparse-dense mode will allow any group address to be dense
|
|
0:10:16
|
as long as it does not have a rendezvous point assignment
|
|
0:10:20
|
whereas in the case of auto RP listener
|
|
0:10:23
|
the only two groups that are allowed to be dense
|
|
0:10:26
|
are 224.0.1.39 and 224.0.1.40
|
|
0:10:31
|
This means that if we do not learn a specific mapping
|
|
0:10:36
|
about a rendezvous point to group address
|
|
0:10:39
|
and we are using auto RP listener, it means that for
|
|
0:10:43
|
whatever address we don't have the mapping for
|
|
0:10:45
|
we would not be able to join addresses in that range
|
|
0:10:49
|
and we would not be able to send registration messages.
|
|
0:10:53
|
So we do not automatically fall back to dense mode
|
|
0:10:57
|
for other groups besides 224.0.1.39 and 224.0.1.40
|
|
0:11:08
|
Now configuration for this is fairly simple to implement
|
|
0:11:12
|
from the syntax point of view. If we look at the
|
|
0:11:14
|
configuration guide
|
|
0:11:18
|
multicast is located under the IP documentation
|
|
0:11:22
|
so IP then IP multicast configuration guide
|
|
0:11:27
|
where the vast majority of the stuff that we're talking about here today
|
|
0:11:30
|
is going to be under the first document that is configuring
|
|
0:11:32
|
basic IP multicast.
|
|
0:11:35
|
In here we see auto RP, BSR, static rendezvous point assignments
|
|
0:11:40
|
source specific multicast, bidirectional PIM
|
|
0:11:43
|
so the vast majority of the stuff that will be within the scope of the
|
|
0:11:46
|
routing and switching exam is going to be inside this one single
|
|
0:11:49
|
document basic IP multicast routing.
|
|
0:11:53
|
If we look at the configuration examples for auto RP or BSR or
|
|
0:11:58
|
anycast, most of the time you should be able to take the
|
|
0:12:01
|
syntax examples here and then change them around
|
|
0:12:05
|
in order to meet the specific needs of the question
|
|
0:12:08
|
again, if you did not know what the particular syntax was
|
|
0:12:12
|
so if we look at the section here, it says sparse mode with auto RP
|
|
0:12:31
|
In this case they are using ip pim auto rp listener command
|
|
0:12:34
|
which means that we can enable just single sparse mode
|
|
0:12:37
|
at the interface level without having to run in dense mode for
|
|
0:12:42
|
other groups.
|
|
0:12:45
|
The ip pim send rp announce command this means that
|
|
0:12:49
|
this device is a candidate rendezvous point
|
|
0:12:53
|
and specifically it is advertising itself for any groups that are
|
|
0:12:57
|
matched in access list 1
|
|
0:12:58
|
which in this case are 239.254.2.0/24 and
|
|
0:13:05
|
239.254.3.0/24
|
|
0:13:09
|
The ip pim send rp discovery this is the mapping agent's advertisement
|
|
0:13:15
|
where loopback 0 and loopback 1 these are the source
|
|
0:13:17
|
IP addresses that we are using for the actual
|
|
0:13:25
|
advertisements and I'm not sure what access list 10 is doing here
|
|
0:13:29
|
it's not actually referenced from their configuration anywhere.
|
|
0:13:35
|
So for the access list 1 in this example, this is what
|
|
0:13:38
|
the groups that we're advertising ourself as the rendezvous point.
|
|
0:13:44
|
And in this case they're using the mapping agent as the
|
|
0:13:46
|
same device.
|
|
0:13:49
|
So again, as long as we can get transit for the 224.0.1.39
|
|
0:13:54
|
and 224.0.1.40
|
|
0:13:56
|
we really should not have any issues with the advertisement
|
|
0:13:59
|
of the rendezvous point's address through auto RP
|
|
0:14:04
|
The only design issue we run into is that if there's some
|
|
0:14:07
|
limitation of the Layer 2 topology where either the
|
|
0:14:11
|
mapping agent message or the candidate RP message
|
|
0:14:14
|
cannot be sent between interfaces, then we would
|
|
0:14:17
|
ultimately not learn the rendezvous point's address.
|
|
0:14:23
|
Now one potential case for this would be that if the candidate
|
|
0:14:27
|
RP or the mapping agent were on one of the spokes
|
|
0:14:31
|
of the NBMA network, when Router 2 sends its message
|
|
0:14:36
|
up to Router 5 that is going to 224.0.1.39
|
|
0:14:43
|
as the candidate RP
|
|
0:14:46
|
normally when Router 5 receives this inbound
|
|
0:14:49
|
it would not be able to forward this back out the same interface.
|
|
0:14:56
|
Now in this case, we see that there's multiple physical
|
|
0:14:58
|
links that we could use, so as long as Router 2 could send its
|
|
0:15:01
|
advertisement out to Router 3, 3 should be able to send this
|
|
0:15:04
|
to 1, 1 should be able to send it to 4, then ultimately everyone
|
|
0:15:10
|
would be able to learn who the candidate RP is and who
|
|
0:15:12
|
the mapping agent is.
|
|
0:15:15
|
But in the case where Router 2 does not have any other physical
|
|
0:15:18
|
connectivity other than the frame relay link
|
|
0:15:21
|
and likewise Router 5 does not have a link to anywhere else
|
|
0:15:24
|
besides this WAN interface
|
|
0:15:27
|
then there's going to be some problems with auto RP in this design.
|
|
0:15:30
|
So unless we're going out of the way to add some
|
|
0:15:34
|
unicast tunneling solution like doing a GRE tunnel between
|
|
0:15:38
|
Router 2 and Router 5 where we can send the candidate RP
|
|
0:15:43
|
or the mapping agent messages out the tunnel, then Router 5
|
|
0:15:47
|
would be able to receive them and send them back out the serial
|
|
0:15:52
|
we're going to have some problems over the Layer 2 media.
|
|
0:15:56
|
Now we'll see there is an option on Router 5's WAN interface
|
|
0:15:59
|
to run the frame relay in NBMA mode for PIM
|
|
0:16:05
|
but the key point is that is only going to apply to sparse
|
|
0:16:08
|
mode groups.
|
|
0:16:11
|
Now since the auto RP groups the 224.0.1.39 and 224.0.1.40
|
|
0:16:17
|
are being treated as dense, Router 5 would not be able to
|
|
0:16:22
|
receive these inbound and then forward them back out the
|
|
0:16:25
|
same interface.
|
|
0:16:32
|
So let's take a look at an example of this where
|
|
0:16:34
|
Router 2 is trying to be either the candidate RP or the mapping agent
|
|
0:16:40
|
the messages are going to Router 5 and then Router 5 is trying to send them
|
|
0:16:43
|
down to the rest of the topology.
|
|
0:16:54
|
So the first thing that I'm going to do is go to all of the routers
|
|
0:16:56
|
and remove their previous static configuration
|
|
0:17:00
|
of the rendezvous point's address.
|
|
0:17:06
|
So we'll say no ip pim rp address 1.2.3.4
|
|
0:17:12
|
Additionally I'm going to turn the ip pim auto rp listener feature on.
|
|
0:17:22
|
And let's see, I'm not sure if that's the exact syntax. It should be
|
|
0:17:25
|
autorp all one word space listener
|
|
0:17:34
|
which it is. Now if we look at the show ip mroute
|
|
0:17:42
|
we see that for the group address 224.0.1.40
|
|
0:17:47
|
it has a flag of capital D or dense.
|
|
0:17:51
|
Even though we have only sparse mode configured at the
|
|
0:17:54
|
interface level, the auto RP listener is overriding
|
|
0:17:58
|
it just for those specific two groups that are related to auto RP.
|
|
0:18:05
|
Now for BSR, you do not have this type of design issue
|
|
0:18:08
|
because the bootstrap information is contained inside the PIM packet
|
|
0:18:12
|
itself that is always regenerated on a hop by hop basis by the local router.
|
|
0:18:20
|
But in the case of auto RP, we're using a separate data plane group
|
|
0:18:23
|
in order to advertise the control plane information
|
|
0:18:27
|
so it means that we have to have proper routing of 224.0.1.39
|
|
0:18:31
|
and 224.0.1.40 first
|
|
0:18:34
|
before we can learn who the rendezvous points are.
|
|
0:18:42
|
So next on Router 5 I'm going to shut down its link that connects to
|
|
0:18:45
|
Router 4, so essentially Router 5's only route
|
|
0:18:50
|
to the left hand portion of the topology is going to be out
|
|
0:18:53
|
the frame relay interface.
|
|
0:18:56
|
And then likewise on Router 2 I'm going to shut its link down
|
|
0:18:59
|
that is connecting to Router 3
|
|
0:19:15
|
Now on Router 2 I should be advertising my loopback
|
|
0:19:18
|
into EIGRP already, so whether this is EIGRP or OSPF or RIP
|
|
0:19:23
|
it doesn't really matter as long as I have basic IP transport
|
|
0:19:26
|
then I should be able to run multicast on top of the network.
|
|
0:19:29
|
But what I want to know here is do these other routers have a
|
|
0:19:34
|
route back to me when I am sourcing traffic from my loopback 0
|
|
0:19:40
|
because if I'm going to advertise my loopback 0 as the rendezvous point's
|
|
0:19:44
|
address, these are the devices they need to be able to do a
|
|
0:19:47
|
lookup on that address.
|
|
0:19:52
|
So this would then to mean if we were doing anycast RP
|
|
0:19:56
|
whatever the anycast address that we're assigning to the multiple
|
|
0:19:59
|
rendezvous points likewise this would also have to be advertised
|
|
0:20:02
|
into IGP.
|
|
0:20:04
|
We always need to make sure that IGP routing or regular unicast
|
|
0:20:08
|
routing is solved before we move on to the multicast.
|
|
0:20:16
|
Next Router 2 is going to announce itself as both a candidate
|
|
0:20:19
|
rendezvous point and the mapping agent.
|
|
0:20:22
|
Technically these could be two separate devices, but for
|
|
0:20:26
|
simplicity purpose in this particular design I'm going to have
|
|
0:20:28
|
it on the same one, so on Router 2 we'll say ip pim send rp announce
|
|
0:20:35
|
this is the rendezvous point advertisement.
|
|
0:20:39
|
I'm going to source this from my loopback 0
|
|
0:20:41
|
the scope is the time to live value, it doesn't really matter
|
|
0:20:45
|
what this is as long as the value was large enough, so
|
|
0:20:48
|
I'll put it just as the maximum IP TTLs 255
|
|
0:20:55
|
I could then specify the interval as how often I'm sending the advertisement
|
|
0:20:59
|
the group list would be the access list that does the
|
|
0:21:02
|
group to my rendezvous point mappings.
|
|
0:21:06
|
If I just leave it like this, then it means I'm going to advertise
|
|
0:21:09
|
everything.
|
|
0:21:11
|
Now notice the parser is doing an error check for me.
|
|
0:21:14
|
It says that if I'm using the loopback as the rendezvous point's
|
|
0:21:18
|
address, I need to make sure to go to the loopback and actually
|
|
0:21:21
|
turn PIM on.
|
|
0:21:23
|
So if I say ip pim sparse mode
|
|
0:21:28
|
then I can announce this as the rendezvous point
|
|
0:21:33
|
and I'm essentially going to do the same thing for the RP discovery message.
|
|
0:21:38
|
So I'll say ip pim send rp discovery. This is the mapping agent message.
|
|
0:21:43
|
In this case I am going to set the interval to lower
|
|
0:21:47
|
because this is the group that I need to advertise to all of the
|
|
0:21:50
|
other routers in the topology.
|
|
0:21:58
|
Now ideally once this is configure, what we should see in the network
|
|
0:22:01
|
is that for each of the candidate RPs, we should see an S,G entry
|
|
0:22:09
|
for the candidate RP that is whatever their source address
|
|
0:22:13
|
they're advertising in this case would be Router 2's loopback
|
|
0:22:16
|
with the destination address of 224.0.1.39
|
|
0:22:23
|
For the mapping agent, we would have the source address
|
|
0:22:28
|
in this case is Router 2's loopback and 224.0.1.40
|
|
0:22:36
|
Now the key point being here that the .39 address this is the
|
|
0:22:39
|
one that the mapping agent needs to receive
|
|
0:22:43
|
where the .40 address this is what everyone needs to receive.
|
|
0:22:50
|
So this means that if there's some sort of RPF failure or some
|
|
0:22:53
|
sort of transport problem from the candidate RP to
|
|
0:22:56
|
the mapping agent with the group 224.0.1.39
|
|
0:23:01
|
or there's a transport problem from the mapping agent to everyone
|
|
0:23:05
|
via 224.0.1.40, then ultimately the rendezvous point address is
|
|
0:23:10
|
not going to be learned.
|
|
0:23:16
|
Regardless of what type of assignment we're doing whether it's
|
|
0:23:18
|
going to be statically or auto RP or BSR
|
|
0:23:21
|
the final verification in any of these cases would be to
|
|
0:23:25
|
look at the show ip pim rp mapping
|
|
0:23:29
|
so here Router 2 says that I am the rendezvous point
|
|
0:23:32
|
the address is 150.28.2.2
|
|
0:23:36
|
The information source is the same address
|
|
0:23:38
|
which means that Router 2 is not only the candidate RP, but
|
|
0:23:41
|
it's also the mapping agent.
|
|
0:23:47
|
So now let's look at this output from everyone in the topology.
|
|
0:23:53
|
We'll say show ip pim rp mapping
|
|
0:24:02
|
We see then on Router 1 we do not know the RP
|
|
0:24:06
|
Router 2 we do because that's the local configuration.
|
|
0:24:08
|
Router 3 we do not, 4 we do not
|
|
0:24:12
|
5 we do
|
|
0:24:18
|
5 we do have the RP
|
|
0:24:20
|
6 we do not
|
|
0:24:21
|
Switch 1 we do not
|
|
0:24:23
|
Switch 2 and Switch 4 we do.
|
|
0:24:28
|
Now if we were to correlate this with the topology
|
|
0:24:31
|
again, the devices that do know about the rendezvous point
|
|
0:24:35
|
are Routers 2, 5, Switch 2 and Switch 4
|
|
0:24:46
|
and what is different about these four devices versus the other
|
|
0:24:49
|
routers in the topology is that when the mapping agent
|
|
0:24:53
|
message comes from 2 to 5
|
|
0:24:55
|
for 5 to get this down to Switch 2 or Switch 4
|
|
0:25:00
|
the message does not need to go out the same interface that it
|
|
0:25:03
|
came in, so if we were to look at Router 5
|
|
0:25:08
|
and look at the show ip mroute
|
|
0:25:11
|
we should see the group 224.0.1.40
|
|
0:25:15
|
that is being sourced by Router 2
|
|
0:25:22
|
Now technically we also see 224.0.1.39 because Router 2 is
|
|
0:25:26
|
the mapping agent and the candidate RP
|
|
0:25:29
|
but the 224.0.1.39 this only needs to get to the mapping agent
|
|
0:25:34
|
the .40 address this needs to get to everyone.
|
|
0:25:41
|
But now since the incoming interface is already serial 0/0/0
|
|
0:25:46
|
we are not allowed to forward that group back out the interface.
|
|
0:25:51
|
So again, it's kind of like a split horizon functionality of
|
|
0:25:54
|
multicast in the date plane. We're not allowed to receive
|
|
0:25:57
|
a packet in and then forward it back out the same link.
|
|
0:26:04
|
Now again, this is the reason why in the case of NBMA
|
|
0:26:08
|
it would make more design sense to make these different
|
|
0:26:12
|
point to point sub interfaces.
|
|
0:26:14
|
So from Router 5 down to the spokes, if I had
|
|
0:26:17
|
different sub interfaces with different subnets
|
|
0:26:20
|
that are going down to Router 1 to 2 to 3 and to 4
|
|
0:26:24
|
this would never be a problem because multicast can treat them
|
|
0:26:28
|
as separate interfaces in the outgoing interface list
|
|
0:26:31
|
versus the incoming interface list.
|
|
0:26:34
|
This is only an issue in this particular design because Router 5
|
|
0:26:38
|
is using one single multipoint interface to reach all of the
|
|
0:26:42
|
other devices on the Layer 2 network.
|
|
0:26:46
|
Now additionally if we had a full mesh of the Layer 2 virtual
|
|
0:26:50
|
circuits, so if Router 2 had PVCs that were going directly
|
|
0:26:53
|
to routers 1, 3 and 4 this would not be an issue
|
|
0:26:57
|
then because Router 2 would be able to send them multicast
|
|
0:26:59
|
packets directly.
|
|
0:27:03
|
It's really only an issue in the multicast design when there
|
|
0:27:05
|
is a disconnect between the Layer 2 network and the Layer 3 network.
|
|
0:27:11
|
When the Layer 3 subnets do not map directly to the underlying
|
|
0:27:15
|
Layer 2 network, that's when we typically have transport
|
|
0:27:18
|
problems in the topology.
|
|
0:27:21
|
Now if this was Ethernet, we know that it wouldn't be a problem
|
|
0:27:24
|
because Ethernet can directly address all hosts at the same time
|
|
0:27:29
|
or all multicast hosts at the same time simply by having
|
|
0:27:33
|
the Mac addresses in the CAM table for the different interfaces.
|
|
0:27:38
|
So if Router 6 were the mapping agent, we would have no problem
|
|
0:27:41
|
getting the mapping over to Router 4 and to Router 1
|
|
0:27:45
|
even though they're on the same interface.
|
|
0:27:55
|
So in this particular design what could we do on Router 5
|
|
0:27:59
|
in order to get the mapping agent messages down to
|
|
0:28:03
|
the other spokes?
|
|
0:28:07
|
Now one thing we could do is just re-enable the interfaces
|
|
0:28:11
|
if the link between 2 and 3 was up or between 4 and 5
|
|
0:28:15
|
was up, there should be no issue with Router 5 accepting
|
|
0:28:18
|
the packet in serial 0/0/0 and then routing it out
|
|
0:28:22
|
another link, the only problem is that we're trying to go in
|
|
0:28:26
|
and out the same interface.
|
|
0:28:31
|
Again, another solution would be to simply change the
|
|
0:28:33
|
frame relay design that if we had separate point to point
|
|
0:28:37
|
sub interfaces with different subnets assigned, then there would be
|
|
0:28:41
|
no problem receiving it in from Router 2 and then forwarding it
|
|
0:28:43
|
out to Router 1 or to Router 3 and 4
|
|
0:28:52
|
So essentially with auto RP there's going to be a limitation
|
|
0:28:54
|
as to how many designs that we can solve with it.
|
|
0:28:59
|
One thing we could do in this particular topology would be
|
|
0:29:02
|
to use a tunnel as a workaround so if Router 5 was receiving the
|
|
0:29:07
|
update in a different interface than it's going out, that would
|
|
0:29:10
|
be valid, the problem is going to be with the tunnel
|
|
0:29:14
|
it means that the reverse path to the unicast source versus the
|
|
0:29:19
|
incoming multicast packet is going to be different
|
|
0:29:22
|
which is fine as long as we keep the reverse path forwarding
|
|
0:29:25
|
check in mind, but essentially any time we're using tunneling with
|
|
0:29:29
|
multicast, it means that there is going to be an RPF failure
|
|
0:29:33
|
unless we're actually routing our unicast packets over the tunnel.
|
|
0:29:40
|
And again, since the auto RP messages are sent in the
|
|
0:29:43
|
normal multicast data plane, they are subject to the RPF check.
|
|
0:29:50
|
This means both the candidate RP advertisement and the
|
|
0:29:52
|
mapping agent advertisement.
|
|
0:29:59
|
So now let's look at this possible solution on
|
|
0:30:01
|
Router 2 and 5
|
|
0:30:04
|
On Router 5 I'm going to create a tunnel
|
|
0:30:07
|
that the tunnel source is my frame relay interface
|
|
0:30:11
|
the tunnel destination is the frame relay interface of Router 2
|
|
0:30:18
|
As long as I have any IP address on here, it doesn't really matter
|
|
0:30:21
|
I can say the IP is unnumbered to the loopback
|
|
0:30:28
|
or I could just assign it to any other address.
|
|
0:30:31
|
Let's say the IP address is
|
|
0:30:34
|
25.0.0.5 on Router 5
|
|
0:30:44
|
and the goal of the tunnel here is that we want to run PIM on it.
|
|
0:30:46
|
So ip pim in sparse mode
|
|
0:30:52
|
then likewise on Router 2 we'll do the same thing
|
|
0:30:55
|
so interface tunnel 0
|
|
0:30:57
|
tunnel source is 155.28.0.2
|
|
0:31:01
|
where the tunnel destination is 155.28.0.5
|
|
0:31:09
|
The address is 25.0.0.2
|
|
0:31:12
|
and we're running PIM in sparse mode.
|
|
0:31:22
|
So we should see now here once the tunnel comes up, we have
|
|
0:31:25
|
a PIM adjacency with Router 5 if we look at the show ip pim
|
|
0:31:29
|
neighbors
|
|
0:31:31
|
Router 2 and 5 are adjacent over the tunnel.
|
|
0:31:34
|
If we go to Router 5 and look at the debug ip mpacket
|
|
0:31:48
|
we should see now the candidate RP advertisements
|
|
0:31:50
|
and the mapping agent advertisements coming in
|
|
0:31:53
|
on the tunnel, but the problem is going to be
|
|
0:31:58
|
our route back to those addresses
|
|
0:32:03
|
which is going to be the loopback of Router 2
|
|
0:32:06
|
is not reachable out the tunnel.
|
|
0:32:11
|
Now what I may need to do here is on the tunnels say
|
|
0:32:13
|
no ip mroute cache as well
|
|
0:32:23
|
so we can see we're receiving in from the tunnel
|
|
0:32:27
|
packets going to 224.0.1.40
|
|
0:32:29
|
but the problem is this is not the RPF interface.
|
|
0:32:33
|
So when Router 5 says what is my RPF lookup
|
|
0:32:36
|
for 150.28.5.5
|
|
0:32:42
|
or not 5.5, 2.2
|
|
0:32:46
|
it says that the RPF neighbor is 155.28.0.2 reachable via
|
|
0:32:51
|
serial 0/0/0
|
|
0:32:55
|
so now in this case it's not valid for Router 5 to be receiving the
|
|
0:32:58
|
traffic in from Router 2 over the frame relay
|
|
0:33:01
|
so now I would need to modify this.
|
|
0:33:05
|
Specifically I need to say that we have a static mroute
|
|
0:33:10
|
that goes to the loopback of Router 2
|
|
0:33:12
|
and this should be received in the tunnel.
|
|
0:33:17
|
Now from Router 2's perspective, it depends on whether the traffic is
|
|
0:33:22
|
going to be routed out the physical frame relay link
|
|
0:33:24
|
or routed out the tunnel when it goes from 5 back to 2
|
|
0:33:31
|
because remember with the rendezvous point
|
|
0:33:33
|
this is where the shortest path tree from the RP to
|
|
0:33:38
|
the source is built, then the rendezvous point tree or the
|
|
0:33:43
|
shared tree is built from the destination back to the RP.
|
|
0:33:53
|
So now let's assume in this case that we have some
|
|
0:33:56
|
sender and receiver that we're trying to get traffic between
|
|
0:33:59
|
we'll say that the receiver is on Switch 3
|
|
0:34:05
|
and the sender is on Switch 2
|
|
0:34:11
|
so Switch 2 is going to send the packets up to 5
|
|
0:34:16
|
5 is then going to have to register these with the rendezvous point.
|
|
0:34:19
|
So it's going to tell Router 2 about this specific address.
|
|
0:34:23
|
Now the way that Router 5 is going to route those is
|
|
0:34:26
|
based on the unicast route to the RP address
|
|
0:34:30
|
because remember the registration is a unicast.
|
|
0:34:34
|
Even though it's a PIM packet, it's a PIM packet
|
|
0:34:36
|
with a unicast destination, not a multicast destination.
|
|
0:34:42
|
In the reverse path when the receiver signals with
|
|
0:34:46
|
IGMP, the join message is going to go up the reverse path
|
|
0:34:51
|
to the rendezvous point, when Router 5 receives this in
|
|
0:34:56
|
we need to think about is the join going to go out the tunnel
|
|
0:35:00
|
or is the join going to go out the physical interface.
|
|
0:35:04
|
So first let's look at all of the other devices and make sure
|
|
0:35:06
|
that we can actually receive the rendezvous point number
|
|
0:35:09
|
the rendezvous point assignment
|
|
0:35:12
|
then assuming that that's working, let's look at receiving
|
|
0:35:16
|
with the IGMP join group command on Switch 3
|
|
0:35:19
|
and then sending with the ping on Switch 2
|
|
0:35:37
|
so the first thing I want to look at is on everyone
|
|
0:35:39
|
the output of the show ip pim rp address
|
|
0:35:41
|
or show excuse me -- show ip pim rp mapping
|
|
0:35:47
|
show ip pim rp mapping
|
|
0:35:53
|
Router 1 says I am learning about Router 2 now.
|
|
0:35:57
|
Router 2 knows because that's the local device.
|
|
0:36:00
|
Router 3 knows it, Router 4 does
|
|
0:36:03
|
5 does, 6 does
|
|
0:36:05
|
Switch 1, Switch 2, Switch 3 and Switch 4
|
|
0:36:08
|
so now there's nothing wrong with the control plane advertisement.
|
|
0:36:13
|
At least everyone is learning about who the rendezvous point is.
|
|
0:36:20
|
Now on Router 2 let's look at the debug ip pim
|
|
0:36:25
|
debug ip pim and the debug ip mpacket
|
|
0:36:29
|
Now I'm going to go on both of my links of Router 2
|
|
0:36:32
|
and say no ip mroute cache
|
|
0:36:38
|
because I want to make sure that any packets that are transiting
|
|
0:36:40
|
then I'm actually receiving them in there.
|
|
0:37:02
|
Next on Switch 3
|
|
0:37:06
|
who is going to be the receiver
|
|
0:37:09
|
we'll set the IGMP join so interface VLAN 9, we'll say
|
|
0:37:14
|
ip igmp join, let's pick a new group range let's say 226.0.0.1
|
|
0:37:22
|
Ideally Router 2 should be receiving the join now.
|
|
0:37:29
|
So if we look for 226.0.0.1
|
|
0:37:33
|
it says the join came in the tunnel.
|
|
0:37:38
|
The reason the join is coming in the tunnel is that when
|
|
0:37:41
|
Router 5 looks at the reverse path route to the rendezvous point
|
|
0:37:47
|
this is being overridden with the static multicast route.
|
|
0:37:54
|
So the key point is that when we look at Router 5
|
|
0:37:57
|
and look at the show ip rpf for the rendezvous point's address
|
|
0:38:03
|
since we have manually overridden the normal lookup with the static
|
|
0:38:07
|
multicast route, it means that any tree whether this is a
|
|
0:38:13
|
source tree or a shortest path tree, any tree that is being
|
|
0:38:17
|
built towards the address 150.28.2.2
|
|
0:38:22
|
is going to be built out the tunnel.
|
|
0:38:26
|
So now from Router 2's perspective, it means when the
|
|
0:38:28
|
traffic comes inbound, that is going to be received
|
|
0:38:32
|
in the tunnel and not on the frame relay interface.
|
|
0:38:38
|
So if we actually go to send the traffic now let's say from Switch 2
|
|
0:38:42
|
if we do an extended ping
|
|
0:38:43
|
that goes to 226.0.0.1
|
|
0:38:49
|
extended commands yes I want this to go out VLAN 58
|
|
0:38:53
|
coming from 155.28.58.8
|
|
0:39:14
|
and we can see now there's some sort of problem
|
|
0:39:20
|
switching over from the shared tree
|
|
0:39:26
|
to the shortest path tree. We actually should not be
|
|
0:39:28
|
dropping the packets here.
|
|
0:39:34
|
Let's if this keep going.
|
|
0:39:42
|
So now let's see what Router 2 said about this.
|
|
0:39:45
|
We should have seen
|
|
0:39:47
|
the
|
|
0:39:53
|
and we can see since 224.0.1.40 is running in dense mode, we
|
|
0:39:56
|
we keep sending an assert message for this
|
|
0:40:01
|
but I want to see what happened for 226.0.0.1
|
|
0:40:07
|
this says that this came in serial 0/0.1
|
|
0:40:14
|
then when we route this out, let's look at Router 2 let's see
|
|
0:40:17
|
what the show ip mroute says for 226.0.0.1
|
|
0:40:24
|
It says the incoming interface is serial 0/0.1
|
|
0:40:31
|
the outgoing interface is null so basically what this means
|
|
0:40:35
|
is that the receiver, it switched over to the shortest path.
|
|
0:40:39
|
So now Router 4 is no -- Router 2 here which is the rendezvous point
|
|
0:40:43
|
it's no longer in the transit path.
|
|
0:40:47
|
But let's say from Switch 3 I don't want to switch over to the
|
|
0:40:50
|
to the shortest path, so the way I can do this is by saying
|
|
0:40:54
|
ip pim spt threshold
|
|
0:40:56
|
is infinity.
|
|
0:40:58
|
And basically I'll say this on everyone, so I want no one
|
|
0:41:02
|
to be able to modify the tree
|
|
0:41:06
|
so that we are leaving the rendezvous point's tree
|
|
0:41:11
|
so I want to stay on the shared tree, I do not want to
|
|
0:41:13
|
switch over to the shortest path tree.
|
|
0:41:25
|
So now let's try this with a new group. On Switch 3
|
|
0:41:28
|
let's say on VLAN 9
|
|
0:41:30
|
ip igmp join 226.0.0.2
|
|
0:41:35
|
so it's a new address.
|
|
0:41:38
|
We should see that Router 2 who is the RP should have
|
|
0:41:41
|
received the PIM join for this so if we show ip mroute for
|
|
0:41:46
|
226.0.0.2
|
|
0:41:50
|
we know about the *,G
|
|
0:41:55
|
it says that the destination is reachable out tunnel 0
|
|
0:42:00
|
so that's where the join came in. It means that's where the
|
|
0:42:04
|
destination is reachable.
|
|
0:42:06
|
Now on Switch 3
|
|
0:42:09
|
let's try to send the traffic. Let's send to -- or not on Switch 3
|
|
0:42:13
|
this would be on Switch 2
|
|
0:42:18
|
we'll ping 226.0.0.2
|
|
0:42:23
|
extended commands yes this is coming from VLAN 58
|
|
0:42:28
|
from 155.28.58.8
|
|
0:42:44
|
so now from Router 2's perspective it again says
|
|
0:42:52
|
it says that this is pruned and we're no longer in
|
|
0:42:55
|
the...
|
|
0:43:00
|
We're no longer in the tree for this
|
|
0:43:06
|
and actually I'm not going to be able to prevent this
|
|
0:43:08
|
switch over here. The reason this is happening if we look back
|
|
0:43:12
|
at the topology here
|
|
0:43:14
|
if we look at the actual traffic flow, the packet is
|
|
0:43:19
|
going from...
|
|
0:43:24
|
it's going to go from Switch 2
|
|
0:43:26
|
to Router 5
|
|
0:43:29
|
Router 5 out the tunnel
|
|
0:43:33
|
5 out the tunnel
|
|
0:43:36
|
2 is then sending it back out the tunnel
|
|
0:43:41
|
and 5 is then forwarding it on the frame relay.
|
|
0:43:47
|
Now the key is that since Router 5
|
|
0:43:50
|
to start, it was first on the shared tree which is the rendezvous point's tree.
|
|
0:43:55
|
This is the one that is routed based on the *,G entry.
|
|
0:44:00
|
The S,G entry
|
|
0:44:02
|
is over here. This is where the source's traffic is actually
|
|
0:44:05
|
coming in.
|
|
0:44:08
|
Now any case where the outgoing interface for the S,G
|
|
0:44:14
|
is the same as the incoming interface for the *,G
|
|
0:44:20
|
the router basically knows that to get to the rendezvous point
|
|
0:44:24
|
I'm going out the same interface that the rendezvous point is forwarding
|
|
0:44:28
|
back to me, so it basically means that from the source to the destination
|
|
0:44:33
|
the rendezvous point does not need to be in the tree.
|
|
0:44:35
|
So what Router 5 is doing
|
|
0:44:38
|
basically since the packet is going out the tunnel and then back in
|
|
0:44:42
|
once this happens, it just removes that from the portion of the tree.
|
|
0:44:48
|
So if we were to look at Router 5 and look at the
|
|
0:44:52
|
show ip mroute for 226.0.0.2
|
|
0:44:58
|
Router 5 says I am on the SPT
|
|
0:45:02
|
even though we told it not to do that.
|
|
0:45:05
|
So there's actually no way that we can avoid this
|
|
0:45:07
|
because basically the router is preventing a loop of the traffic going
|
|
0:45:13
|
out and then coming back in the same interface.
|
|
0:45:22
|
So we can see on Router 5 I do have the ip pim spt threshold infinity command
|
|
0:45:26
|
which normally means that you would not switch over to the spt
|
|
0:45:30
|
but this particular case you cannot prevent.
|
|
0:45:34
|
And I actually did a write-up on this not too long ago
|
|
0:45:36
|
that's on our blog.
|
|
0:45:38
|
If you search for CCIE blog and multicast tree
|
|
0:45:48
|
it should be -- it's this one here, understanding advanced
|
|
0:45:50
|
PIM shared tree designs. There's a case basically where Switch 2
|
|
0:45:56
|
is sending traffic down to Switch 1
|
|
0:45:59
|
The packet goes from Switch 2 to Router 2
|
|
0:46:02
|
from 2 to 4, 4 to 3 who is the rendezvous point
|
|
0:46:07
|
then from 3 back to 4
|
|
0:46:10
|
4 to 5 and 5 to Switch 1
|
|
0:46:14
|
The issue is that from Router 4's perspective, the packets are going
|
|
0:46:17
|
out to 3 and then looping back in
|
|
0:46:21
|
so once Router 4 does this, it automatically edits Router 3
|
|
0:46:24
|
out of the tree and the final traffic flow you would see here
|
|
0:46:28
|
is Switch 2 to Router 2
|
|
0:46:30
|
Router 4 to Router 5
|
|
0:46:33
|
and then 5 to Switch 1
|
|
0:46:35
|
so even if you told them not to switch over to the shortest path tree.
|
|
0:46:40
|
If the rendezvous point is not -- it does not need to be in the physical
|
|
0:46:43
|
transit path, then it's automatically going to be removed.
|
|
0:46:51
|
So in our particular case here, using the tunnel it does work
|
|
0:46:55
|
it's kind of a hack on the process, but really the better design choice
|
|
0:47:00
|
is just to use separate interfaces for frame relay.
|
|
0:47:04
|
So if Router 5 had multiple point to point
|
|
0:47:06
|
subnets going down to the spokes, then it really doesn't matter
|
|
0:47:11
|
where the placement of the mapping agent is or the rendezvous point
|
|
0:47:16
|
because there's not an issue with traffic coming in one interface
|
|
0:47:19
|
and then out another.
|
|
0:47:22
|
But again, any time that we use the tunnel
|
|
0:47:24
|
if we were to go to Router 5
|
|
0:47:28
|
and look at the show run include mroute
|
|
0:47:33
|
I have a static multicast route that says for this particular address
|
|
0:47:36
|
which is Router 2's rendezvous point address
|
|
0:47:40
|
point this out the tunnel. Now if I were to change this
|
|
0:47:44
|
and say instead of the exact route to Router 2
|
|
0:47:48
|
I were to change this to a default route
|
|
0:47:54
|
let's say we're going to default out the tunnel.
|
|
0:48:03
|
Let's look at what happens on Router 5 once we receive
|
|
0:48:05
|
packets in on the other interfaces
|
|
0:48:10
|
so on 5 let's say clear ip mroute *
|
|
0:48:29
|
then let's try this with a new
|
|
0:48:32
|
address, let's go to Switch 2
|
|
0:48:39
|
and I'll do a ping let's ping
|
|
0:48:42
|
let's say any any random address 227.7.7.7
|
|
0:48:53
|
Extended commands yes this is going out VLAN 58
|
|
0:48:59
|
and let's say this is coming from our VLAN 8 interface
|
|
0:49:05
|
which is 155.28.8.8
|
|
0:49:16
|
Notice now what Router 5 says
|
|
0:49:19
|
about this particular traffic.
|
|
0:49:22
|
Stuff that's coming from 155.28.8.8
|
|
0:49:28
|
It says it came in Fast Ethernet 0/0 but what's wrong with this?
|
|
0:49:36
|
It says it's not the RPF interface.
|
|
0:49:41
|
But what's kind of strange here if we look at the unicast routing table
|
|
0:49:43
|
let's say show ip route 155.28.8.8
|
|
0:49:49
|
our route back to the source it is via Fast Ethernet 0/0
|
|
0:49:54
|
so it's not really an RPF failure, that is the correct
|
|
0:49:56
|
interface for the traffic to come in.
|
|
0:49:59
|
But the problem is now since I did a default multicast route
|
|
0:50:05
|
it's not saying that it's ok for the traffic to come in the tunnel
|
|
0:50:09
|
it's saying that the traffic must come in the tunnel.
|
|
0:50:12
|
So if I show ip rpf for 155.28.8.8
|
|
0:50:18
|
this points to the tunnel because of the /0 default route.
|
|
0:50:30
|
So you do kind of have to be careful with this, it is valid to use the
|
|
0:50:33
|
static multicast route to fix these RPF failures
|
|
0:50:37
|
but if your match to the particular sources
|
|
0:50:39
|
is too broad, you can accidentally override the traffic flows from other
|
|
0:50:46
|
valid sources that are supposed to come in on other interfaces.
|
|
0:50:51
|
This is why originally when I did the multicast route on Router 5 to
|
|
0:50:54
|
start, I did just an exact match for the rendezvous point's address
|
|
0:51:00
|
because this was the only one that I was trying to
|
|
0:51:02
|
fix the RPF failure for.
|
|
0:51:04
|
Once I change this to the default, this is going to
|
|
0:51:08
|
break everything with the exception of 150.28.2.2
|
|
0:51:21
|
and the problem with this is that with the static multicast
|
|
0:51:23
|
route, it's really not documented as clearly that this is how it works
|
|
0:51:28
|
that it is used to change the reverse path forwarding check
|
|
0:51:32
|
but the static route doesn't say that it is allowed to come in the
|
|
0:51:35
|
interface, it says that that traffic must come in the interface.
|
|
0:51:41
|
And since I'm matching 0.0.0.0/0
|
|
0:51:45
|
so that's a shorter match basically for everything
|
|
0:51:50
|
even though I have a longer match in IGP, the static
|
|
0:51:54
|
multicast route is overriding all of that.
|
|
0:52:04
|
Now there are other possible solutions for this type of problem
|
|
0:52:07
|
with the auto RP
|
|
0:52:09
|
and the mapping agent placement.
|
|
0:52:12
|
One way to do this if I were to simply change where the mapping
|
|
0:52:17
|
agent is located, if I put the mapping agent on Router 5
|
|
0:52:20
|
and Router 5 was also the rendezvous point
|
|
0:52:26
|
or technically Router 2 could stay the rendezvous point
|
|
0:52:28
|
as long as 5 was the mapping agent
|
|
0:52:31
|
because then there's no problem with 5 sending
|
|
0:52:34
|
the single mapping agent packet to all of the spokes
|
|
0:52:39
|
and then down to its other interfaces. The only issue is that the
|
|
0:52:42
|
the packet cannot come in the frame relay and then go
|
|
0:52:45
|
back out without it running in NBMA mode.
|
|
0:52:49
|
And with PIM NBMA mode, it only works for sparse mode groups.
|
|
0:52:54
|
But with the auto RP message we force that to be dense
|
|
0:52:59
|
so that we can just flood it on every single interface.
|
