[AUDIO LOGO]
So now it's time to jump onto the command line
and actually implement bidirectional
PIM in our environment.
However, before we can do that, we
are going to have to make a change
to our current environment.
Right now, we are using anycast RP.
And of course, the main idea behind anycast RP
is the rendezvous points are essentially acting
in an active-active role.
This is why we had to have MSDP to cluster
or synchronize the rendezvous points so that they
would know all the information.
That's fine for the control plane.
That's no problem.
But we can't have multiple active RPs in the data plane.
That simply doesn't work.
Now, with bidir PIM, can we still have redundant RPs?
Yes, of course we can.
But it has to be an active-standby scenario,
sort of like what we can do with auto-RP or BSR,
changing priorities.
However, we can't have them active-active.
So the first thing we're going to do
is disable anycast RP in the environment.
Then we'll change our tree over to be bidirectional.
We will have to stop our current traffic flow to allow
the current route to time out.
That way, it can get rebuilt as a bidirectional tree.
So let's take a look at our topology
just real quickly so we know exactly what we're doing.
And then we'll jump into the command line
and make all of this happen.
So for this demonstration, we will still
be on Multicast Topology 2.
Just as a reminder, that means all of our routers
are running IOS XE.
And what we're going to be doing is configuring our environment
so that only router 2 is the RP.
Now, we'll go ahead and keep the current address
we have on there of the 100.1.1.1,
using its loopback 100 interface.
However, we will be unconfiguring
all of that information on router 4
as well as taking down the MSDP peering between router 2
and router 4.
Once that's done, we will verify that our environment is still
working.
And then we'll convert everything over to bidir
and take a look at what that changes in the environment
as far as which devices are actually
in the forwarding path.
So let's go ahead and get started.
We'll begin by reconfiguring router 4.
So the first thing we want to do here on router 4
is configure it not to be an RP candidate.
So we'll start with the no ip pim rp-candidate
on the loopback 100 interface.
Since we're not using loopback 100 anymore,
we can also say no interface loopback 100.
That's no longer needed.
And we want to take down the MSDP peering with router 2
as well.
So we'll simply say no ip msdp peer 10.2.2.2.
We can exit configuration.
And then we'll go make our modifications on router 2
as well.
So we see that router 2 knows that the MSDP peering
session is already going down.
So all we really need to do on this side
is remove that configuration.
We'll simply say, no ip msdp peer 10.4.4.4.
Everything else on router 2 can stay the same
because as it's still going to be an RP.
And it's still going to use its loopback 100 interface.
Let's go over to the BSR.
And let's do a show ip pim rp map.
And we see that we still know the RP as 100.1.1.1.
And we're learning that information from 100.1.1.1.
Problem is since that was an anycast address,
there's no real way to verify that that's router 2 and not
still router 4, except for the uptime.
Notice the uptime on this is only 42 seconds.
So it's a pretty good indicator that this information
is coming strictly from router 2 at this point.
And this is new information.
So that said, let's go ahead and verify that our environment is
still functional before we switch this over
to bidirectional.
To do that, let's go ahead and start our ping on router 10.
And we'll verify that that traffic is actually
getting to router 8.
We'll do that, of course, by verifying router 7.
We'll start with a show ip mroute.
It should have the S comma G entry.
We can see here that it does.
If it didn't have the S comma G entry, of course,
that pretty much indicates that the first packet didn't even
get to router 7, but it has.
So if we do our show ip mroute count,
we can see that it's currently forwarded 19 packets
down the source-based tree.
And again, we give it a few seconds.
Look at it again.
And we can see that now it has forwarded 24.
So clearly, it is forwarding packets, and it is working.
Now, what we don't want is all of this information
to stay here as we switch over to bidir.
So there's two things we have to do
to allow all these routing entries to time out.
First, we're, of course, going to have to stop the source.
So let's go back over to router 10 and shut this down.
And we want the star comma G to time out as well.
So now let's go over to router 8, go into its gigabit
1 interface.
And say, no ip igmp join 224.1.1.1.
We want to take this out of the group.
At this point, we want to let all
of the multicast routes on all of the devices time
out or go around and clear all the tables.
So at this point, we'll just forward until they time out.
So now we've given it a moment.
Let's hop over here to router 2.
And let's do a show ip mroute.
And what we see is all that's left
is that default auto-RP group, which is perfectly fine.
So now what we need to do is configure everything
for bidirectional PIM.
So the first thing we need to do is enable the feature
on all the routers.
The way we do this is we simply go into configuration mode.
We type ip pim bidir-enable.
That's all we have to do.
So we'll go ahead and paste that in here on router 1.
We just did router 2, router 3, router 4, router 5, router 6,
and last but not least, router 7.
So now all of our devices have been enabled
to support bidirectional PIM.
The next thing we have to do is configure the RP so
router 2 to advertise itself as a bidir RP.
So on the ip pim rp-candidate line,
where we're advertising our loopback 100,
we simply have to add bidir to the end of this statement.
We'll go ahead and hit Enter.
We can exit configuration.
We'll give this just a few seconds to propagate.
And then all of the devices should then
be aware that router 2 is a bidir-capable rendezvous point.
So let's use our chat window here.
We'll do a show ip pim rp map.
Notice that here on router 2, it's now
added bidir to the end of the RP statement.
All of the other routers should know this as well.
Let's hop over to router 1.
We see router 1 also has the bidir statement.
So let's just verify all of them quickly.
Router 3 has it.
Router 4 has it.
So does router 5, router 6, and router 7.
So all of our PIM-enabled routers
are aware that the RP is 100.1.1.1
and it is bidir capable.
Just a quick note here on the bidir statement--
this can also be put on the line, advertising a candidate
RP into auto-RP as well.
Or if we are doing static RP assignment, on the static RP
line, there is also a place to put bidir.
So regardless of how we're learning about the RP,
there is a choice to configure bidir on every option.
We just happen to be using BSR right now in our demonstration.
So now that all of the routers are
aware of the bidir-capable RP, let's
go back over to router 8 and rejoin our group.
So we'll simply take the "no" off the beginning here.
Join the group again.
We can exit configuration.
Let's go back to router 10 and start our ping again
so we have a source.
And as usual, let's go back over to router 7
and see if we're getting the S comma G entry.
So if we do our show ip mroute, notice
there's no S comma G entry, because this is bidir PIM.
We shouldn't have one.
Remember, in bidir, everything is going to be a shared tree.
So notice, instead, what we have is
first we have a flag on there, which
is the capital B, indicating that this is a bidir group.
We can also see that we have a bidir upstream, which
is sort of like the incoming interface, so to speak,
except with bidir, of course, we see
that the same interface, gigabit 2,
can be both bidir upstream as well as an outgoing interface.
But the upstream is always going to be towards the rendezvous
point.
That's what the RPF check is going to be for here.
So we see that the bidir upstream
is gigabit 2 towards router 3.
And then the outgoing interfaces are both interfaces
gigabit 3 and gigabit 2 because we can, of course,
forward traffic in both directions.
If we do a show ip mroute count, notice
that again, there's no source tree listed here anymore.
It's just the RP tree.
It has forwarded 59 packets so far.
And if we hit Up, we can see that it's now 64.
So once again, the environment is working,
and we are forwarding traffic.
However, let's take a look at this tree
just a little bit more.
So let's, for example, look at the rendezvous point, router 2.
Let's do a show ip mroute here.
Once again, what do we see?
Well there's no S comma Gs.
We see that our group has the B flag on it.
We see that the bidir upstream is null because remember,
the incoming interface on the rendezvous point
is always null.
But notice, on the outgoing interface list,
we right now just have gigabit 2.
That's currently the only direction
that we've received the join from.
Let's also take a look at the first-hop router.
So let's look at router 6.
So notice, on the first-hop router,
it is, of course, still flagged as bidirectional.
But notice, it's not even for our specific group,
because that join hasn't actually come here.
We haven't gotten a star comma G join for that particular group,
224.1.1.1.
What it has done is it has received
the traffic going to 224.1.1.1.
It did a show ip pim rp map.
And what did it find out?
For that group, the RP is 100.1.1.1.
So it did the RPF check that says to go to router 1,
50.0.16.1, as the RPF neighbor.
And it forwards up the tree using the bidir upstream,
gigabit 1, towards router 1.
So that's how this works on both sides of the tree
as well as on the rendezvous point.
So in this video, we set up and configured bidir PIM.
And as we saw, a lot of the battle
here was just getting everything cleared out,
then enabling bidir PIM on all of the routers,
setting bidir on the RP announcement.
And again, that can be done either through BSR, auto-RP,
or static RP assignment.
We just have to add bidir to the end.
What's interesting, by the way, is
if you have not enabled bidir on that router
yet, that command doesn't even show up.
So you'll actually think you're looking in the wrong place.
You have to enable bidir on the router first.
Then you get that option on the RP announcement line.
Now, once everybody knew about the bidir RP,
we started up our source.
We started up our receiver.
And the traffic flowed through just as it normally would,
except there was no SPT switchover.
Everything flowed through the rendezvous point.
We had no S comma G entries in any of our routing tables.
Everything was star comma G. And also remember
that on the upstream side of our tree,
it didn't even go to the specific group.
It just used the general RP mapping
to know which way to send the traffic up the shared tree.
So all of this is pretty cool.
But we have another cool feature we have to look at--
source-specific multicast.
And in a way, it's almost the opposite of bidir PIM,
but not exactly.
We're going to cover that next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.