[AUDIO LOGO]
So moving on to trouble ticket 3,
we are still on MPLS topology 3 and our ticket says that router
8, so it looks like we're going to be over here at customer
site 1 again, is missing the customer A
headquarter's network 10.6.6.6/32 from its routing
table.
Now, that particular network is actually
not on our diagram here, that's actually
loopback 0 on router 6.
So for some reason, that's missing
from the routing table on router 8 according to our ticket.
So let's go ahead and jump into the command line.
Of course, we'll verify that ticket first on router 8,
and then we'll see if we configure what's gone wrong.
So starting off with a show IP route OSPF, we see that,
in fact, the 10.6.6.6/32 is not here.
Now, what's sort of interesting is we even
saw this in our previous ticket, we
are getting some prefixes from router 6.
This 10.100.1.6 is actually from router 6 as well.
So it's something about that particular prefix.
So why don't we go to our egress PE router 5, the closest router
to router 8 here and see if it has the route?
So let's start with a show IP route for VRF customer A1,
and we see that it's not in the VRF on router 5 either.
So let's see if we're learning it through BGP.
And as we can see, it's not here in the BGP table either.
So it looks like router 5 is not receiving
anything about the 10.6.6.6 prefix at all.
So why don't we go see if the ingress or the head-end PE
knows about this route?
That would be router 1.
Let's do a show IP route for the VRF customer A.
What we see here is that router 1 does, in fact,
have the 10.6.6.6/32 being learned via OSPF.
So the next question, of course, would be,
if we're receiving it from OSPF in the customer's VRF,
are we putting it into BGP?
So let's do a show BGP for VPNv4 unicast for the VRF customer A.
And according to this output, we are, in fact,
redistributing this into BGP.
We can see right here that it's in the BGP table.
It has a weight of 3768, which generally speaking means
that it's been locally injected on this router--
unless, of course, we've done something
to manipulate wait, which I can tell you
in this particular case, we have not.
So that 32768 does definitely indicate that it's
being locally injected.
So I guess the next question would be,
is it being received on the route reflector?
Let's go up to the route reflector
and see if it knows about this route.
So we'll do a show BGP VPNv4 unicast for our VRFs.
And what we see here is for the route distinguisher 100:10,
which actually is customer A router 1,
we see that we're getting this 10.6.6.6/32 prefix.
We can tell from the next hop that it's most likely
coming from router 1.
Of course, next hop can be manipulated,
but assuming that it's not, that next hop of 10.111
would also indicate who's advertising it.
So again, it appears that it's at the route reflector,
but for some reason, router 5 is not getting this route.
So let's go back to router 5 and take a look
at what router 5 is actually accepting in terms of the VRF.
So back on router 5 again, let's start with a show VRF
detail for customer A1.
So what are the important things we
want to see off of this output?
First is we want to see the import VPN route target
communities, and we see that we're importing route target
100:1000.
And that is, in fact, exactly what we're
supposed to be doing for customer A.
That's customer A's route target.
We don't have an import route map set,
so we're not doing any kind of filtering.
So everything here actually looks OK as far
as which route targets VRF customer A1 is accepting.
So since this looks OK, it brings up
the interesting question, maybe we
need to look at what route target is actually
on that prefix.
So let's go back up to the route reflector.
On the route reflector, let's get some more detail
on that particular prefix.
And right here, we're beginning to see our problem.
Notice that the route target on this update is 100:5000.
And we just saw that router 5 is not
importing that route target.
So the real question is, why is that route target on there,
and is it configured incorrectly?
So since router 1 is the one bringing this route into BGP,
let's go see if there's anything entertaining
going on router 1 that would be causing this problem.
So let's start with a show VRF customer A.
And we see here the customer A is configured
with the correct import and export route targets
for address family IPv4 and IPv6.
So again, at first glance, this appears to be correct,
but something has to be changing this.
So let's see if we can get some more detail.
And here on the detailed output for the VRF,
we're starting to get our first hint
as far as what's going on here.
We see that our import and export route
targets are correct, but we saw that without the decal,
didn't we?
What we're seeing here that's a little more interesting
is that this VRF is configured with an export route policy
RP_ROUTES.
Let's take a look at what that policy says.
So we'll do a show rpl route-policy for RP_ROUTES.
And we see here that if the destination is in PL_ROUTES,
then set the extended community to the route target 100:5000.
So now we're really starting to get an idea of what's going on,
we could go look at that prefix list if we needed to.
But I would say that based on the evidence we've seen so far,
I'm going to bet that prefix list happens to permit
10.6.6.6/32.
What do you think?
Because it's matching this route policy, and this route policy
is setting the extended community to the 100:5000.
Now, we should assume when we're troubleshooting something
like this that this route policy is probably here for a reason.
It's probably not just randomly put in here.
Now, it might be and if you look at your network design
documents and this is not supposed to be like this,
then by all means we could remove this.
But I think the more fundamental problem here
is it looks like somebody tried to add 100:5000 to the route
targets on purpose.
It looks like this was not an accident.
But I don't think that they were meant
to replace the 100:1000 that's supposed to be on here.
So we should know from going through all of our lessons
what's wrong here.
We forgot the word, "additive" at the end
of our set statement.
So to fix this, we need to change
this to additive so it doesn't replace the route target,
but rather adds to the root targets.
So let's go ahead and go into configuration here
and fix this problem.
So we'll go into configuration mode.
We'll go into our route-policy RP_ROUTES.
Now, this is going to warn us that we're
going to overwrite it and that's OK because it only
has one statement in it anyway, and that's the statement,
we need to update.
So we'll say if destination is in PL_ROUTES,
then we want to set the extended community route
target to 100:5000 additive.
That's what was missing.
We'll end the if, and we'll end the policy, commit our changes,
and exit configuration.
We'll give this just a moment to converge,
and then we'll double-check our fix.
So it's been a few seconds.
Let's do a show BGP VPNv4 unicast for the VRF customer A,
and let's look specifically at that 10.6.6.6/32.
And we see our extended communities
getting pretty long here.
It's wrapping around the screen a little bit,
but we can see that the route targets are now
100:1000 and 100:5000.
So if this was the route of the problem,
we should be able to verify this by going over to router 5.
Let's do our show IP route for VRF customer A1 again.
Now we see that we are receiving that 10.6.6.6, which
means it should be going all the way out
to the customer as well, which of course,
was the original ticket.
So let's go back out to router 8,
and we'll simply repeat our show IP route OSPF that we started
this whole ticket with, and we see that now we're getting
the 10.6.6.6/32, indicating that this ticket is now resolved.
So in this ticket, we got a little reminder
that when we use an export map with extended communities
such as the route target, if we don't say additive,
it will actually replace the existing community string
rather than just adding to it.
And of course, in this particular case,
that actually broke the connectivity for customer A
for that prefix in the environment.
But as soon as we corrected the problem,
it ended up with both root targets on it.
Router 5 started importing that prefix correctly
since it had the right route target on it,
and that resolved the entire ticket.
I hope this has been informative for you,
and I'd like to thank you for viewing.