In the previous video and lab, we
implemented policy based routing.
We told R4, hey, if traffic matches a certain pattern,
go ahead and forward it directly over to R3,
instead of going around the gigabit path with gig 2--
with R2 and then R1 and so forth.
So when we left the video and the lab,
it was still not trace routing through the right path.
And so I asked in the last video, what is the problem?
How do we troubleshoot this?
This would be a good practice exercise
in troubleshooting PBR when it doesn't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in troubleshooting PBR when it doesn't
go how you thought it would.
So let's go back to the topology,
along with the existing lab that we
left from the previous video, and see
if we can troubleshoot why the trace route is still not
using the correct path through the network.
So here's the play by play.
Went on R8.
When we did the ping and we sourced it from this interface.
And it went to this interface.
It actually went up, up, up in R4, based on the debugs.
It did policy based routing.
Sends it directly over here, and then went down.
But when we did a trace route from R8, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But when we did a trace route from R8,
even if we sourced it from gig 00,
and we destined it for this IP address-- this range here--
the trace route went this way.
I'll put it in a different color.
It went this way instead of the shortcut way with the PBR.
So we have PBR implemented on serial 3 slash 1.
Now, why is that?
And the thing that is important to consider
is, we need to realize what the PBR is matching on.
And in the case of pings-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in the case of pings--
ping uses ICMP all day and all night--
ICMP.
And if we are on a Windows device, that Windows device--
if we're using trace route--
it also uses ICMP.
So a Windows computer generating that traffic
would be a match, because it's using ICMP.
However, what isn't a match would
be a trace route implemented by a Cisco router or a Linux
device.
They're using UDP.
So when that traffic is being seen at R4,
it checks out the access control list that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it checks out the access control list that's
being used in the route map as part of the PBR, and says,
hey, this doesn't match.
I'll just route this normally, which is going up to R2.
So we have a couple ways we can solve this.
This is good practice.
We could modify the access list that
is currently being looked at.
Or we can make an additional access list,
and we could go ahead and add that to our route map
as part of its matching statement.
So match ACL 1 and then space, match ACL 2 on that same line.
Because then it's an or.
It can match this traffic or that traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It can match this traffic or that traffic.
And it will be go ahead-- it'll go ahead and be a match.
And it can set the next hop.
So let's go to the lab environment.
And you're welcome to do this either way that you want.
I'll make a decision here in a moment about which way
we'll do it for the demonstration.
But either way we want to correct this,
the key is we need to get in the match statement UDP traffic
from those two different network segments from source
and destination, if we want trace route from a Cisco
device also to be policy based routed from R4 over to R3.
Let's go to the interface.
So back at R4 with the debug. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So back at R4 with the debug.
The trace-- let's go back into the trace one more time.
View the trace, including the correct source interface.
And it is not being policy based routing.
That's because UDP.
So let's modify our policy on R4.
And I'll just show IP.
We already know the policy where it's applied.
Let's do a show route map.
What we could do is we could add another access control list,
and have it match ACL-1 and ACL-2.
Also, this is important. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also, this is important.
Let's imagine you have a route map with 20 sequences in it.
If you want to delete just one line,
make sure you add the correct sequence number, because it's
easy to delete the entire route map accidentally
when you only intended to delete one sequence somewhere.
So be very careful, especially on a live gear,
because if you delete a pulse--
a route map that has lots of entries--
that's gone once you hit enter, if you delete it accidentally.
So we just have one sequence-- one ACL.
I would say for this scenario, we can just modify the ACL. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I would say for this scenario, we can just modify the ACL.
That'd probably be the easiest.
So we'll do a show access list.
There it is.
Config t IP access list.
And we'll just extend it.
And the name is ACL--
we use the same, exact name.
So it becomes part of that.
And this is just going to automatically add
a new sequence, number of 20 inside the ACL.
And we'll say permit UDP and traffic that is sourced from--
I'll going to copy this right here.
Boom.
And also, we do have matches from earlier.
Those matches also caused the PBR to happen. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Those matches also caused the PBR to happen.
So now we're including UDP.
We'll do do show access list and just make sure.
Yeah.
So now it's including UDP, as well.
And if we do a show route map, it
should show us that it's matching on this ACL.
We do the show ACL.
It's matching on those two sets of protocols, ICMP and UDP
based on the source and destination.
Now, if we go to R8, and on R8, if we do a same trace route-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, if we go to R8, and on R8, if we do a same trace route--
my eye hands will never leave my arms.
So let's hit the up arrow key.
Trace route from 10, 1, 77.
Sources gig 0, 0.
And that's the IP address of 192.168.1.8.
So it's sourced from the 192.168.1 network.
And we'll press enter.
And sure enough, that's--
I was crossing my fingers.
We're going to-- from R8 to R6 to R4,
then straight over to R3.
There's the PBR happening, and then onto R5 and onto R7.
And here on R4, because we still have debug-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here on R4, because we still have debug--
let's do a show debug.
We still have IP policy debugging enabled.
It's showing us those PBR decisions, too, for that packet
with the next hop over to R3.
So thanks for helping me troubleshoot the problem
with why trace route wasn't being policy based routed.
It's because the instructions said, hey,
we're not matching on that type of traffic.
So we fixed that.
So in the next video, here's what I'd love to do.
We've focused so far with policy based routing,
and applied it with the policy on an inbound interface.
Traffic comes in, it's evaluated, and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Traffic comes in, it's evaluated, and then
routed normally.
Or if it matches the policy, it's
policy based routed based on the instructions.
So that's for routed traffic.
Now we can also tell the router--
R4 any other router-- hey, listen.
For traffic you generate-- what you mean me?
Like you're sending a message to an EIGRP or OSPF neighbor,
or you're responding to an SSH session.
You're generating traffic.
You're sending SNMP alerts.
You're sending whatever it is you're sending.
We can also have policies applied to locally router
generated traffic, as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
generated traffic, as well.
And that's the technique I'd like
to share with you regarding PBR in the very next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.