So next up, we have trouble ticket 5.
This one is a traffic engineering ticket.
Therefore, this is on MPLS topology 5.
And we don't have a common core protocol.
This time, we have a domain 1 which
is running IS-IS and a domain 2 which is running OSPF.
Also keep in mind that we have a route reflector where
we're running BGP, with routers 7 and 8, for our unicast IPv4
and routers 1, 2, 5, and 6 for BGP link-state.
So all of that said, let's take a look at our ticket.
This ticket says that R8 cannot reach 100.7.7.7,
which is actually a network over here on router 7.
As usual, let's start by verifying the ticket,
and then we'll jump into our troubleshooting.
So to verify the ticket, we'll go ahead
and trace to the 100.7.7.7.
We'll source it from our loopback 100 interface.
Remember, this is reachable over a traffic engineering tunnel.
The only two networks available across that tunnel
should be the 100.7.7.7 and our loopback 100 interface,
which is 100.8.8.8.
So we need to source this from our loopback
100 or it wouldn't work either way.
So as we can see, this is going nowhere.
I let it go through about five hops there
and then it just broke out of the trace.
This is not five hops away.
So this should not take this many hops.
This is clearly not working.
So when a trace goes literally nowhere on even the first hop,
it's always a good idea to check your own local routing.
Because if I don't know where to send it,
then there's not even going to be a first hop,
let alone a last hop.
So a show ip route for the 100.7.7.7
would probably be a good place to start.
As we can see, this is not a spectacular answer.
It's telling us that we don't have the network.
OK.
Well, we should be learning it through BGP.
So let's do a show ip bgp.
And what we see here is we have an entry for our own loopback,
which I mentioned earlier, the 100.8.8.0/24.
But we don't have the 100.7.7.7.
Now remember, this is supposed to be advertised
and we're supposed to have a traffic engineering
tunnel based on that.
So without the route, we probably
don't even have the tunnel.
Let's verify that.
So if we do a show mpls traffic tunnel, as suspected,
we don't even have a tunnel up.
So this is definitely not going to work.
We're not getting the route through BGP.
So since we're not getting the update,
it's probably not a bad idea to go look at the route reflector
and see if the route reflector is getting
the update since that's sort of the central point of all
of the BGP updates.
Always a great place to check if we're missing updates, to see
if the route reflector has it.
So let's go check out the route reflector.
So here we'll still do a show IP BGP.
And interestingly, what we see here
is the route reflector actually has
both prefixes, the 100.7.7.0 and the 100.8.8.0.
And they're both selected as best,
which means it really should be sending this to router 8.
Let's check.
Let's do a show bgp neighbor for 10.8.8.8
and we'll do advertised routes.
So what we see here is it's actually advertising both
of these prefixes to router 8.
So maybe we should dig in a little bit more on router 8
to see why it's not getting this update.
Because it looks like the route reflector
is, in fact, sending it.
So let's go back to router 8.
And let's turn on a debug.
Let's do a debug IP BGP update and then clear a BGP table.
We'll just do a soft end, and we'll do it for all neighbors
since router 8 only has one neighbor anyway.
And here, we see a very important entry in our debug.
Right here, we see that we are, in fact,
receiving the 100.7.7.0/24 but it's denied due to a route map.
So that could be a significant problem.
So let's take a look at our configuration.
Let's do a show run section bgp.
And we see that we do, in fact, have
a route map, IPv4_IN, applied in the inbound direction.
So let's say-- do show route map IPv4_IN.
And the important thing we see in this route map
is we're matching on a community list called CL_LL_TRAFFIC.
So we should probably see what that community list says.
So we'll say show ip community-list CL_LL_TRAFFIC.
So this is permitting the community string 100:10.
This all looks appropriate.
This all looks correct.
So a good place to go from here would be back
to the route reflector.
Let's look at the detail on that prefix
and see if it has this community on it.
So now let's do our show ip bgp for the 100.7.7.0.
And what we see here is there's actually
no community on this at all.
And, of course, there needs to be the 100:10.
It's not here.
So that explains why router 8 is filtering out the route.
So if it's not on the update, that
means that router 7 must not be putting it on.
Let's go check out router 7 now.
So on router 7, let's just go right for the show
run section bgp and see what it's configured to do.
So actually, what we see here is on the network statement
where it's bringing the 100.7.7.0 into BGP,
that's being run through a route map called IPv4_OUT.
So let's see what that route map is doing.
What we see is it's configured to set the community to 100:10,
which is correct.
So let's see if it's actually doing it.
Let's do a show ip bgp for our own injected route.
So we see right here that it is, in fact, putting the community
100:10 on the update.
Yet we've also seen that that's not making it
to the route reflector.
So let's take a look at our BGP configuration again.
And if we look over this configuration,
we can actually see the problem.
Keep in mind that the default behavior of iOS XE
is actually to strip the community strings off
of outbound updates.
So ironically enough, router 7 is configured properly
to put the community string onto the update.
But as soon as it sends it to the route reflector,
it's then stripping off the community.
We have to actually configure this to send the community
to the route reflector.
So let's go ahead and put that fix in place.
So we'll simply go into configuration mode
in the router_bgp 100.
And then for the neighbor 10.11.11.11, we have to say,
send-community.
And then of course, you have a choice here.
You can do both extended or standard.
We only really need standard.
However, I usually just turn on both
if we're turning on the feature anyway.
So let's go ahead and do that.
We'll exit configuration.
And we'll do an outbound soft clear
to push these new changes up to the other devices.
So that said, let's go take a look at the route reflector
and see if it has the community string now.
So we'll simply look at our same command again.
And now we see right here that the community is set to 100:10
as it's supposed to be.
So this looks good.
Let's go see if it showed up on router 8 now.
So we can even see here on the debug, which we still
had running, that we've now received
the update for 100.7.7.0.
We can see right here where the community is now set to 100:10.
And we see right here where it's actually installed that route
into the routing table.
So let's go ahead and turn off our debugging.
Let's do a show ip bgp for that update.
And we do, in fact, see here that the community is set
and we're getting the binding SID based on our traffic
engineering tunnel.
If we do a show ip route for the update,
we see that it's in our routing table as well.
So let's see if our tunnel is up now.
So we see that Tunnel1000, with the destination of 10.7.7.7,
is, in fact, admin up, operational up,
the path is valid, the signaling is connected,
and it's using path option 1--
segment routing with PCE.
So this looks like everything is operational.
Let's go ahead and test our original ticket.
Let's do our trace to 100.7.7.7, sourcing it from our loopback
100 interface.
So interestingly, based on this trace, it's still not working.
Now, keep in mind, this traffic has
to be able to go both directions.
We've done all of our verifications
so far on router 8 and made sure the router 8
tunnel is up and so on.
But these are unidirectional tunnels.
We need a tunnel on the other direction as well.
So since everything appears to be OK here,
and that doesn't necessarily mean that it is.
There could still be other problems.
But I think the next logical step
would be to check the path for the return traffic.
That seems to be the most logical thing to be wrong here.
So let's go over to router 7 and take a look
at that return tunnel.
So if we do our show mpls traffic tunnel,
well, there we have it.
There's no tunnel on this side either.
Well, let's go through the routine again.
So let's do our show ip bgp for the 100.8.8.0.
And again, the network's not in the table.
So we've sort of seen this already.
Let's just verify that it's the same problem.
If we do a show run section bgp, once again,
we see we have a route map applied inbound.
If we just do a show route map, we
see that that inbound route map is
matching on the community list.
If we do a show ip community list,
we see that, again, it's permitting that same community
string.
So this appears to be the same issue.
We'll verify it again real quickly on the route reflector.
So this time we'll look at the 8.8.0.
Once again, no community string.
So let's go back to router 8.
We'll do a show run section bgp.
And no big surprise, this router is also not
configured to send the community.
So let's go ahead and fix that.
We'll clear our outbound updates.
Since we're pretty confident that this is the same problem,
we'll skip all the other verification in the middle.
Let's just go right back to router 7.
Look at the BGP update.
We see that it has the community string here
and, more importantly, that we have the update.
Let's verify our tunnel.
We see that, just like router 8, this tunnel
is up and operational.
So now let's try our original ticket once again.
Maybe now it actually works.
So back here on router 8, let's do our trace again
and hope for better luck.
So as we can see from this update, now it's working.
We have reachability to 100.7.7.7 from router 8
as we're supposed to.
Therefore, I would consider this to be trouble ticket 5 solved.
So in this video, we saw the result of routers
not configured to send the BGP community string.
Since we were using the community string for route
filtering, if it doesn't get sent,
that means all the routes are going
to get filtered out or, at least,
not being used for traffic engineering tunnels.
Now, the use of community strings
is technically optional.
But we don't generally want traffic engineering tunnels
built for every single BGP prefix.
We want to be able to control that,
and that's why we use the community strings.
We just have to make sure on iOS XE
that we configure it to then send those communities.
Because as you saw, it will strip off
even the ones that that router itself put on the update.
But once we configured it to send the community up
to the route reflector, then everything
started working and everything came backup.
Of course, we had to do it on both sides.
But regardless, we got this up and operational.
I hope this has been informative for you.
And I'd like to thank you for viewing.