[AUDIO LOGO]
So the first PIM enhancement that we want to look at
is Anycast RP.
The very simple concept here is that we're going to take
multiple devices, give them an interface--
we'll use a loopback interface with the same IP address--
advertise that into our routing protocol,
and then all of the other devices on our network
will go to the nearest instance of that IP address.
Now, since we could hit any of the devices
with that IP address, it's, of course,
imperative that those devices are performing the same task--
in other words, being a rendezvous point.
It's also critical that they have
the same information keeping in mind,
what is a rendezvous point for?
It's to help us find the source of a particular multicast
group.
So all of the RPs would have to know about all of the groups.
Now, here's where the problem comes in.
If a particular first hop router registers a source
with one instance of the RP and then
the client side or the last hop router
tries to get that group from that particular source
but contacts a different instance of the RP,
that other RP needs to know about that source's
availability.
We call this a source active message,
and we exchange this using MSDP or Multicast Source Discovery
Protocol.
Just as a quick note.
On some other Cisco platforms such as the Nexus platform,
this can actually be exchanged through PIM itself.
These platforms do not support that, so we will be using MSDP.
But just be aware there may be other methods
to do Anycast on other platforms if you ever run into those.
But we're going to advertise this Anycast address using
BSR, which is simply a method to advertise the rendezvous point.
So we're going to jump in, put all of these different moving
pieces together, and get our multicast working with Anycast
for the RP address and advertising
that using BSR, with MSDP being used to essentially cluster
the rendezvous points so that they have
the same information as far as which sources
are available for which groups.
So as usual, let's start with looking at our topology
so we know what we're going to be building and where,
and then we'll jump into the command line
and get all of this up and running.
So in this skill, we're going to be using Multicast Topology 2.
So let's begin by talking about what's changed in topology 2
because if you've been following along
with the multicast skills, this may
look very similar to topology 1, and, in fact, it is.
What's changed is all of the iOS XR routers,
so router 1, router 2, router 3, and router 4
have been replaced with iOS XE routers.
Now, just for the record, this is not a change
that I actually wanted to make.
However, iOS XRV, which is what we're using in these lab
demonstrations, does not appear to work correctly
with a lot of the features that we're
going to be talking about in this skill.
Just as one small example, MSDP would come up
perfectly fine between the iOS XR routers.
However, it wouldn't actually exchange any SA or Source
Active messages.
So even though it was learning the information
and one router--
what would potentially be the sender--
said that it was putting the entry into MSDP,
it wouldn't show up on the other side.
I also had a lot of issues with bidirectional PIM,
which we'll be talking about in an upcoming video.
So rather than trying to fight and get
iOS XRV to actually work, which it appears
to have some both control plane and data plane issues with some
of these technologies, unfortunately, we just
ultimately had to replace these with iOS XE routers, which
actually function perfectly fine in this environment.
So that also further proves that it
must be some sort of an issue with these particular versions
of iOS XRV.
And I did try a few different versions,
and I just couldn't get it functioning properly.
So although I didn't really want to do it,
this is a change we had to make in order
to make these demonstrations actually function.
So let's talk about what we're going
to actually do in this video.
But keep in mind, throughout this skill, all of our routers
are iOS XE.
So all of that said, what are we actually going
to configure here?
Well, we're going to start by creating new loopback
interfaces on both router 2 and router 4.
We're going to give both of them the address of the RP, which
we're going to use AS 100.1.1.1.
Then we're going to advertise both of these into OSPF.
So these are both going to get advertised into the IGP
so they're reachable from all of the other devices,
and then we're going to advertise them into BSR so
that router 5 will then advertise them
to the rest of the network.
And, of course, once all that is up and running,
we're going to have to then configure
MSDP between these routers so that they can exchange source
active messages.
Now, of course, MSDP cannot be run between the Anycast
loopback interfaces, so we'll run MSDP between the normal
standard loopback zero interfaces that these routers
already have configured.
So this is what we're going to be building.
Let's go ahead and jump in and get started.
We'll just start by creating these loopbacks,
so we'll start on router 2.
So we'll simply go into configuration mode.
We'll make this new loopback interface.
We'll simply make it loopback 100.
We'll give it its IP address.
Again, it's going to be 100.1.1.1.
This is going to be a slash 32.
We also, of course, need to bring it into OSPF,
so we'll simply say ip ospf 1 area 0.
And we need to enable PIM on it, so ip pim sparse mode.
We'll exit out of the interface, but we'll
stay in configuration mode because we're not quite done.
Let's do the same thing on router 4.
So we'll configure the exact same thing on router 4.
Again, it's interface loopback 100.
This is Anycast, so remember, it's
going to have the exact same IP address, again, a slash 32.
We need to bring it into OSPF, so we'll
bring it into area zero, and it's going to need PIM.
The next thing we need to do is advertise this
as a candidate RP into BSR.
So since we're already on router 4, we'll just start here.
It's ip pim rp-candidate, and we're
going to be advertising the loopback 100
interface that we just created.
We'll go ahead and exit configuration,
and we'll go do the same thing on router 2.
Now that that's done, let's make sure that all of our routers
now know which device is the RP.
So we'll simply use our chat window here,
and looking at all of the routers, here on router 2,
we can see that we know the RP is 100.1.1.1.
If we look back at router 1, it has the information as well.
Router 3 has been updated, 4 has been updated,
5 has been updated, 6, and 7.
8, 9, and 10 are not running PIM,
so we don't need to check there.
But now that everybody knows the RP, we do still have a problem.
Here on router 7, if we were to trace to that address,
notice the path is going from 7 to router 3 to router 4.
So ultimately, router 7 is going to the router 4
instance of the 100.1.1.1.
If we look at router 6, however, router 6 is going to router 1
and then to router 2.
So basically, what we have going on here,
we have the first hop router, which
is the one responsible for registering
the source with the RP, is going to router 2.
So it's going to register its source with router 2.
On the other hand, the last hop router,
which is router 7, which is what's
in charge of building the star comma G tree
or the shared tree to the rendezvous
point, well, that one's going directly to router 4.
So you can see here where we have a problem where
the source is going to get registered with router 2,
but the star comma G tree is going to be built to router 4.
Let's go ahead and check that out.
So if we come back over here to router 2
and we do our show ip mroute, what we see here
is that router 2 does, in fact, have the S comma G tree.
But let's take note of a few things about this entry.
First, it has the flag prune set on it.
Second, the incoming interface of gigabit one
is correct, so is the RPF neighbor of router 1.
But look at the outgoing interface list.
It's null because as far as router 2 is concerned,
no devices have requested this group.
However, if we go look at router 4,
our show ip mroute here shows the star comma G entry,
but there's no S comma G entry.
Now, the incoming interface is correct since it is an RP,
and that's the root of the star comma G.
That incoming interface should be null,
and the outgoing interface list is also correct--
gigabit 1.
That's what it should be.
But what we're missing here is router 4,
who actually does have a potential client all the way
over at router 8.
But nonetheless, the star comma G tree is built.
It doesn't know where to go for the source,
and this is exactly why we need MSDP.
So now let's build our MSDP neighborship
between router 2 and 4.
Since we're on router 4, let's just go ahead and start here.
MSDP can get complicated, but just
for the sake of doing Anycast, this
is going to be a very simple configuration.
We simply have to say ip msdp and then list
the peer router's address--
in this case, router 2's loopback.
Then we tell it to connect from our local source
interface of loopback 0.
That's actually all we have to configure.
We'll do a mirror configuration on router 2.
So again, we simply go into configuration mode.
Ip msdp peer, this is going to be 10.4.4.4,
and the connect source here is also loopback 0.
Remember, we can't build this neighborship
between the loopback 100 Anycast interfaces
because each router would think it
was trying to neighbor with itself
because they both have that same address.
So this definitely has to be between different interfaces,
not the Anycast address itself.
That would not work.
So let's go ahead and hit Enter.
We'll exit configuration, and we see
here the MSDP peer is already going up
between routers 2 and 4.
So now let's do some verification.
It's actually going to be best to verify this on router 4
since it's the one in this environment that should
be receiving some information.
So let's go over to router 4 and do some verification.
We can start with a show ip msdp summary.
We can see that it's saying our peer, 10.2.2.2, is currently
up.
And notice, it's actually telling us
that it has an SA count or a source active message
count of 1.
We can get a little bit more information
if we say show ip msdp peer.
This will give us a lot more information
about that neighbor, particularly
what interfaces we're connecting with,
how many messages have been sent and received,
if we're doing any form of SA filtering because we may not
want all of the S comma G entries
to be exchanged between these devices.
In our example, we do.
But again, in more advanced scenarios, we may not want to.
So like I said, this can get a lot more complicated, but not
for the sake of Anycast.
Probably the most important thing to keep an eye on though
is the show ip msdp SA cache.
This actually tells us the entries
that we've learned from the other side.
So as we can see here, we've learned the S comma G
entry available through the RP 10.1.1.1.
But most importantly, through the peer, 10.2.2.2.
So we're getting the information through MSDP,
but that doesn't really do us a whole lot of good
unless we're putting it in the multicast routing table.
So if we do our show ip mroute again,
notice that router 4 now has an S comma G entry,
and it has a flag of M on it, which means that it
was learned through MSDP.
So this is looking good.
If we take a look at router 2, notice that this S comma G
entry now has a flag of A on it, indicating
that it is a candidate for MSDP advertisement.
So now this information is being exchanged
between our rendezvous points.
Now that that's working, if we jump all the way over
to router 7, we see that the last hop router now also
has the S comma G entry and it has the correct incoming
and outgoing interfaces to forward
this traffic towards router 8.
And, of course, to verify that we're forwarding traffic,
we'll do a show ip mroute count.
We see that currently, it has forwarded 207 packets
down the source-based tree.
We give it just a second, repeat the command, it is now 212.
So this indicates that we are properly forwarding the traffic
through our multicast environment using
Anycast with BSR and MSDP.
So in this video, we saw how to configure Anycast
by putting loopback interfaces on our routers with the same IP
address, then advertising those into our routing protocol,
enabling PIM sparse mode on those interfaces,
then configuring BSR to advertise that address
as the rendezvous point.
Now, of course, that created a disconnect
between the rendezvous points as far
as where the sources were available on the network.
So then, we set up MSDP to exchange the source
active messages between the rendezvous points
to keep the source information synchronized in our Anycast
environment.
Another really cool feature that we have available with PIM
is bidirectional PIM, so let's go ahead
and talk about some more detail on bidirectional PIM coming up
next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.