[AUDIO LOGO]
Now let's take a look at our first choice
for doing dynamic RP discovery, which is Cisco's Auto-RP.
So given that static configuration can
be a little tedious and that it doesn't provide for any way
to do redundancy, Cisco came up with a way
to dynamically discover the RP so that all we have to do
is turn on the RP in our environment, all of the routers
automatically learn it.
And we can have redundancy because we
can have multiple routers be a candidate RP.
And then we have something called a mapping agent that
will choose the winner and advertise that to everybody
else in the network.
And then everybody agrees on which device is the RP.
Now, Cisco had to get this to work in PIM version 1.
That's because that's what was out at the time.
I bring this up because in our next video,
we're going to look at another option called BSR or bootstrap
router.
That's the industry standard way of doing this.
However, it only operates in PIM version 2.
They updated the PIM standard to support automatically
finding the RP.
Cisco did this before this standard was updated.
And the reason I bring all of that up
is as we're looking at how Auto-RP works,
its mechanism is a little odd.
We're going to actually use multicast to disseminate
the information that we need to do multicast routing.
So it is a little bit of a cart before the horse problem
in that we have to have our multicast routing working
to send out this information.
Now we're, of course, going to jump into the detail of how
that works.
But that's a fundamental problem that we have with Auto-RP.
So let's jump in, and take a look at the detail,
and how that actually operates.
And we'll look at, of course, at the two moving
parts of Auto-RP.
So let's go ahead, and jump in, and get started.
And then, of course, we'll configure this on the command
line, and take a look at some of our show commands,
and stuff to verify that this is working.
So now we're talking about Auto-RP and its attributes.
So first and foremost, as we mentioned
during the introduction, this is in fact, Cisco proprietary.
And Cisco does enable this by default
on most of their platforms, certainly,
the routing platforms.
And we also mentioned that this actually uses
multicast for communication.
Now, it uses two different groups.
Let's just go ahead and bring both of those up here.
So it uses 224.0.1.39 for its announcements.
This is for the information where the candidate RPs will
announce their willingness to be the RP to the mapping agent.
Then it uses 224.0.1.40 for the discovery portion,
which is where the mapping agent sends this information out.
Now, the reason I underlined the 1 in this discussion is we
have to realize that 224.0.1 is not link local multicast.
These two groups are routed multicast groups.
And herein lies the problem.
We have to route these groups through our network
in order to learn the Auto-RP information,
in other words, the RP that we need to use for sparse mode.
So we'll talk about how that's handled here in just a moment.
Now, the way auto handles redundancy
is we're actually going to use a mapping agent to elect
the rendezvous point.
So the way this works is the candidate RPs
advertise the groups that they're
willing to be the RP for to the mapping agent.
And that is what's using the 224.0.1.39.
The mapping agent then collects all the information
about all of the candidate RPs for each group.
The mapping agent then chooses which RP to use for that group.
And then that RP is then announced
to the rest of the routers.
That's where it's using the 224.0.1.40 address.
Now as we mentioned, there is a slight issue
with using these multicast groups.
Since these groups are routed groups,
as we said, and sparse mode is not up and running because we
don't have a rendezvous point yet,
these have to use dense mode.
So yes, it's true.
We are going to use dense mode to disseminate the information
about who the RP is so that the routers know the RP,
so that they can do sparse mode.
Now, like I said during the introduction,
this is a little bit of an odd situation.
But it's necessary because none of this
is built into PIM itself.
So Cisco had to find a way to get this
to work within the parameters.
So how do we get these groups to operate
in dense mode and all of the other groups
to operate in sparse mode?
Let's take a look.
So we basically have two options here for IOS XE.
Notice that this bottom choice here, this is automatically
handled on IOS XR.
So we don't have to do anything on IOS XR for this.
It effectively already does the second choice here.
But let's talk about the two choices we have on IOS XE.
First and foremost, we can run what's called sparse-dense mode
on every interface.
That's going to allow these groups to operate
in dense mode, and everything else
will operate in sparse mode.
The general rule with sparse dense mode
is if we have a rendezvous point, well,
then use sparse mode.
If we don't, then use dense mode.
And since we won't have an RP until these two
groups advertise one, these groups
will advertise in dense mode.
Now I want to be clear, sparse dense mode
was the initial way to do this.
But over time, well, we'll say that a small issue
was discovered.
What happens if the RP goes down or Auto-RP fails?
For whatever reason, we lose the RP information.
Again, maybe it's not available or maybe auto
fails, guess what?
All of our groups would then revert to dense mode.
And as we've mentioned in previous skills,
there's reasons we don't just want to use
dense mode on our network.
There's a reason we chose to run sparse mode to begin with.
So we don't really want the entire network
to fall back to dense mode.
And that's why they gave us this second option.
The second option here is your IP PIM Auto-RP listener.
This is configured in global configuration.
And again, this is specifically on IOS XE
because IOS XR automatically does this.
But what this allows is these two groups and only
these two groups to operate in dense mode.
There is no falling back to dense mode
for any other groups.
It's limited specifically to the groups for Auto-RP,
and that's it.
So our best choices for running Auto-RP
is we're probably going to want to use IP PIM Auto-RP
listener on IOS XE.
And, of course, we don't have to do anything on IOS XR.
It just does this automatically.
I have seen some newer versions of IOS XE that
also have IP PIM Auto-RP listener already enabled.
But just be aware of these commands.
And these are things that we may have to actually configure.
Also be aware here of the default
timers, which are 60 and 180.
So this can be a little bit slow to respond.
We'll see as we go through our configuration.
We will have to wait a few minutes for things
to happen because these aren't exactly fast timers.
And truth be told, in most environments,
they don't need to be.
It's not usually critical that we find out
where the RP is right away or that it went down right away.
So these default timers are generally OK.
But if you need them to operate faster, of course,
they can be adjusted.
And as we can tell by the discussion
we've been having, Auto-RP does provide redundancy.
Because if one of our candidate RPs were to go down--
so if we were to lose one of these candidate RPs up here,
well, the mapping agent will simply choose a different RP
and then advertise that to the rest of the network again.
So that's where the redundancy comes in.
It can also provide mobility because not only could this
be an RP went down and a new one came up,
it could be in a different location.
So the redundancy and mobility go together.
But what this does not offer us is a way to do load sharing.
The mapping agent chooses one out of the group
and advertises it to everybody else.
Now I will put one qualification on this.
Just like we mentioned with static RP,
well, remember what we said up here
that the candidate RPs will advertise
the groups that they're willing to be the RP for.
So just like with static RP, I could have different Auto-RP
routers for different groups.
This again, would involve manual load sharing.
But from that perspective, it can
do that type of load sharing.
But it has no built-in automatic mechanism for load sharing.
I'm just trying to bring this up because we're
going to contrast this to some other options coming up later,
BSR for example, which does have a built-in load sharing option.
That's why we're contrasting this.
Can you do it manually?
Yes.
But that's not what we're exactly
referring to when we say that the technology itself
is not doing load sharing.
So that takes care of all of the detailed discussion of Auto-RP.
Let's jump into the command line and see how we configure this.
So once again, we'll just be using one router for this.
And let's start with a show ip mroute.
And what we want to see here is notice
that without configuring Auto-RP at all on this router,
all we've done is enabled a few interfaces
and turned on multicast routing.
We're already listening to the 224.0.1.40.
And we have a star comma G entry for it here in our table.
Also note the D on this entry indicating that this
is operating in dense mode.
We don't have to worry too much about the other flags
right now.
Those are connected and local.
That's, of course, because it's locally
listening to this on the loopback 0 and the gigabit 1
interfaces.
But nonetheless, we're listening for this Auto-RP group
automatically.
However, if we do a show ip pim rp map,
we currently do not have any RP mappings.
So let's start by configuring this router
to be an RP candidate.
The way we do that is we say ip pim send-rp-announce.
Then we have to tell it what interface we want to announce.
And we're going to be announcing our loopback 0 interface.
The other thing we have to specify here is the scope.
Or you could call this the TTL.
What TTL is it going to put on these announcements?
This announcement message has to have a scope high enough
to reach the mapping agent.
Now, this router is also going to be our mapping agent
because we only have this one router
right now that we're working with.
However, if the mapping agent was four hops away
then you want to make this at least four.
In a lot of environments, we'll just
make it something like 16, which should
cover the whole environment.
But if you want, you can scope how far these messages will go.
Also note that this is where we could specify that group
list if we only want to announce our willingness
to be the RP for certain groups just like we
did on our static entries.
Also this is where we can change that interval if we
don't like the default timers.
Now they're going to be OK for us here today.
We'll just go ahead and hit Enter.
But those are some options that we have on the announce line.
If we do a show ip mroute again, notice that now we
have a star comma G and an S, G entry for the group 224.0.1.39.
That's us advertising ourselves as being a candidate RP.
Remember, the 224.0.1.40 is us listening
for somebody else, the mapping agent,
to tell us who the RP is.
But now that we're advertising our candidacy,
we're now using the 224.0.1.39, which
is what we use to talk to the mapping agent.
Now unfortunately, if we do a show ip pim rp map,
we're going to discover that we still don't have an RP.
That's because as of right now, we
don't have the second part of Auto-RP.
We don't have a mapping agent yet.
However, notice that it does recognize that this system
is configured as an RP.
It's not using itself.
But it knows that it's advertising its candidacy
because it has seen that announce command
in the configuration.
So in order for this to work, we're
going to need a mapping agent.
The way you configure a mapping agent
is almost the same way as you configure the candidate.
It's ip pim send-rp.
But this time, it's discovery.
Once again, we have to specify a loopback.
Once again, we have to specify a scope.
And the only real option we have on this one
is simply to change the timers.
So we'll just go ahead and hit Enter.
We'll exit configuration.
Now if we do a show ip pim rp map,
notice that we still don't have the information.
As we said, these timers are a little bit slow.
So we'll give this just a few minutes
to realize who the RP is.
One indicator that it's probably working
is our tunnel interfaces just came up
like they did when we configured this statically.
So it'd be a pretty good guess to say
if we do a show ip pim rp map again,
that now we know who the RP is.
We see that just like with static.
It says that for the groups 224.0.0.0/4,
the entire multicast group, the RP is 10.1.1.1.
It did resolve to the host name R1
because our IP host entry is still
in there from our previous lab.
This is compatible with PIM version 2 and PIM version 1.
The info source is telling us who the mapping agent is.
It's telling us who told us about the rendezvous point.
That's a little confusing on this output
just because it's the same device.
But our mapping agent is also 10.1.1.1.
This was, of course, elected via Auto-RP.
We can see that the current uptime is about 19 seconds.
That's how long it took us to look
at this from when the tunnels came up essentially.
And we can see that it's going to expire
in 2 minutes and 41 seconds.
It times out after three minutes.
Another good command to look at to verify this
is show ip pim autorp.
What we see here is, of course, that Auto-RP is enabled.
RP packet discovery MTU is 1,500 bytes, probably not
all that critical in most environments.
But notice that the 224.0.1.40 is joined on the loopback 0
interface.
And it has sent, and received multiple RP announcements,
and RP discovery messages.
So all of this indicates that Auto-RP is up and running
as it should on this device.
It's acting as an RP candidate and as the Auto-RP mapping
agent.
And ultimately, I guess we could say
it's acting as an Auto-RP client as well since it's
learned its own information.
So in this video, we saw how to configure
Cisco's proprietary Auto-RP solution for providing
a dynamic way of discovering the rendezvous point
and electing the rendezvous point out
of a group of possible candidates,
which allows us to do some redundancy here as well.
Now as we mentioned, this doesn't exactly
support load sharing.
Although we can do some manually if we restrict those group
numbers.
Now this works a little bit odd as we
said because it has to use dense mode in order
to flood the information it needs
to learn who the Auto-RP is so that it can do sparse mode.
But again, in its defense, that's
because it came along before PIM version 2.
And this can operate in PIM version 1 where it's--
we'll call it competitor, BSR cannot.
Now BSR is the industry standard way of doing this.
And it doesn't need its own special groups.
So that's what we need to take a more detailed look at next.
And until then, I hope this has been informative for you.
And I'd like to thank you for viewing.