[AUDIO LOGO]
We know that MPLS creates a label for every route
in the routing table.
That doesn't necessarily mean, however,
that we want to advertise those labels
to every one of our peers.
So what we have is a way that we can limit
or filter which labels are sent to which peers.
This is a relatively easy process.
However, there are some rather unique rules
that we want to look at before we just jump into this.
So that's actually what we're going to do first.
Then, of course, we'll take a look at our topology,
just to see what we're going to build,
and jump into the command line and make this happen.
But on the other side, there's also--
we may not want to receive all labels.
That's a much easier process.
We don't have to worry about a bunch of rules,
it's just the filter.
But we're going to be taking a look at that as well.
So again, let's go ahead and jump into that topology,
take a look at what we're going to build and look at,
and then, of course, get this up and operational.
So let's begin by looking at these filtering
rules around our conditional label advertisement.
So the first rule is, if there is
no ACL about a particular label, that label is
going to be sent to everyone.
And you could argue that this is the default condition.
There is no ACL about any labels.
And therefore, those labels are sent to everyone.
But what we mean here is that if we
don't create an ACL about a particular label,
then anything else we do is not going to affect
that particular label.
The next rule is, if there is an ACL about a label,
then that label will be sent only
to the configured neighbors.
In other words, it will stop being
advertised to the neighbors that are not listed.
Another rather interesting rule is these ACLs
that we create can only be applied to one neighbor.
So in that ACL, you're going to have
to list all of the prefixes that you want labels advertised
to that particular neighbor.
And again, this is related to the first rule,
but it's saying that if there is an ACL
to a particular neighbor, but a particular label is not
addressed, it will still be sent.
Like I said, closely related to the first rule,
but it's just a little bit different
because, in this case, there actually is an ACL.
It's just not addressing that particular label.
And then, the last one here isn't necessarily a rule,
but a modification of the rules.
We can actually turn off all label distribution
and only send things if they are explicitly allowed,
which would effectively kill the first rule here.
We're saying, no, no, no, we don't send labels to anybody,
unless we have an ACL saying that we should.
If you want to look at it this way,
the default behavior is pretty much a permit all.
We send labels to everybody.
And then, we implement our filters
to say where we don't want them sent.
But with this bottom choice, we're
changing that to a default deny.
We don't send labels to anybody, unless our ACLs say we should.
So let's go ahead and jump into our topology diagram,
take a look at where we're going to implement this, and then
let's jump into that command line and get this working.
Now, the way we have this configured right now,
particularly since we're doing prefix suppression on all
of the transit networks, we're really
not generating and sending labels for any prefixes
that we don't need.
So we've already optimized our network here.
So that means we can really filter anything
without breaking something.
So what we're going to do is, we're just
going to create a new loopback interface on router 2,
just so we can filter out its label and see how all of this
works.
So let's go ahead and jump into the command line.
Of course, we'll be starting on router 2,
creating that loopback.
So what we're going to do is just create
an interface loopback 22 here.
We'll give it an IP address, and we'll just make it a /32
address of all 22s.
We'll go into router OSPF 1 into area zero,
and we'll bring interface loopback 22 into OSPF.
And the same thing with MPLS LVP.
We'll enable that on the interface as well.
We'll commit those changes.
So now, routers 3 and 4 should have
a label for this new network.
Let's go over and verify.
So we'll do our show MPLS forwarding table.
And we see that we have this 22.22.22.22 network, which
is configured as pop, which is fine.
It's doing PHP.
We should see the same thing on router 4.
And we see that router 4 has the exact same configuration.
So now that we have this network and label on router 3,
of course, you know what we're here for.
We're here to filter it.
So now, let's configure router 2 so
that it no longer sends the label for 22.22.22.22
to router 3.
But, of course, we still want router 4 to get it.
So let's jump back over to router 2 and configure
our filtering.
So on router 2, what we need to do is create an ACL.
So we'll say, IPv4 access list.
And we'll just call this ACL_R4.
Because what we're going to be doing
is configuring this to only send this prefix to router 4.
So we're going to say to permit IPv4 host 10.4.4.4 any.
So that configures which peer we're
going to be applying this to.
Then, we're going to need another IPv4 ACL.
And let's call this one actually OUT.
This is going to be almost the same.
But for this one, we're going to be listing the network
that we're talking about.
So in this case, 22.22.22.22.
So which prefixes do we want to advertise to which peers?
That's the purpose of these two ACLs.
To apply this, we go into MPLS LDP.
We're going to address family IPv4.
We say label local advertise for.
and then, of course, it wants to know which prefixes, so
for which prefixes.
This would be where we put in the ACL_R4_OUT.
And then we say who we want to send it to.
And this, of course, would be the ACL_R4.
Now, remember our fundamental rules here.
If we configure ACLs to go to a neighbor
to advertise a particular prefix,
it means that prefix is no longer
advertised to anybody else.
So by telling it what to send a router 4,
we're telling it not to send this one to router 3.
So let's go ahead and commit those changes.
We'll exit configuration.
And just to make sure everything's up to date,
particularly since this is just a lab, let's just go ahead
and clear our MPLS LDP neighbors,
just to make sure everything's up to date.
And then if we go back over to router 3,
we should lose the label for the 22.22.22.22.
And we can see that we have.
We, of course, still know about the prefix.
The prefix still exists.
However, notice that the outgoing label is unlabeled.
That means we did not receive a label, even the pop label,
for that prefix.
So our filtering is working correctly.
If we go over to router 4, router 4 still
has that prefix listed as pop.
Because router 4 is still getting the label.
So that pretty much covers how to control conditional label
advertisement.
We've set this up so that router 4 gets the label,
but router 3 doesn't.
It's, again, fairly straightforward, as long
as we keep the rules in mind.
But what about accepting labels?
Well, since we're filtering things, why not configure
router 4 here to not accept the label for this prefix,
since we know that it's still getting it.
Let's go ahead and do that.
So once again, we're going to want an ACL.
So let's start by creating this access list.
We'll call it ACL_LABELS_R2, which
is going to list the prefixes that we're
willing to accept labels for.
So in this case, it's just going to be router 2's loopback.
So once again, let's go into MPLS LDP
Into the address family IPv4.
We'll say label.
But this time, it's label remote.
Which remote labels are we going to accept.
We're going to say from.
And here, we put in the LDP here that we're
going to accept this from, colon, the label space.
The label space is currently zero.
So we're going to put in the host address, colon, zero.
And then, we're going to say for, and we put in our ACL.
We'll commit those changes and exit configuration.
Then, let's look at our show MPLS forwarding table again.
And what we see is that to 10.2.2.2,
which we are still accepting the label for, says pop.
But now, the 22.22.22.22, which we just effectively filtered
out, is now set to unlabeled, exactly as it should be.
So now, we have our outbound and our inbound label
filtering working as we want.
So in this video, we saw how to configure conditional label
advertisement, as well as conditional label acceptance,
if we don't want to get labels or send labels
for every prefix in the routing table.
We can see that this is fairly easily filtered out.
And as long as we follow the rules correctly,
we should get the labels where we want them
on the devices that need them.
So that pretty much wraps up everything
we need to talk about in this skill, which leaves us
with just one more thing to do.
And that's our review in the form of a quiz.
That's exactly what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.