So let's dive into a discussion on policy-based routing. PBR for short. Policy-based routing. How
many of you are doing policy-based routing? Anybody here? Anybody using policy-based routing at all?
And if you are, what's the reason for you using policy-based routing? Because the whole purpose
of policy-based routing is to override the default behavior of our routers. That's right.
So in order to fully understand policy-based routing, we have to understand what the default
behavior is of our routers. The default behavior of our router is to do what? Forward based on
the destination IP address. Forward based on the destination IP address. So a packet comes in,
we look at the destination IP address, we find the entry in the routing table that matches,
and then we send it out the exiting interface associated with that.
So policy-based routing means that we get to forward based on policies that we have defined.
Meaning we don't, we get to override the default behavior of the routing table,
or the default behavior of the router. So instead of forwarding based on just the destination IP
address, I can forward based on anything I want. Well, sort of. I can forward based on anything
I can define in an access control list. So for example, I could forward based on the source IP.
So if the traffic matches this source IP address, then forward it this way. But wait,
the routing table says that way. It doesn't matter. I say based on the policy-based routing
to go that way. So my router has to do that. What if the source or destination port is a
certain value or a range of values? I can forward based on that if I want to. Protocols,
quality of service markings, and a whole lot more.
So this is going to be used anytime you want to influence a certain set of traffic to go a
certain way, which is different than what the normal traffic in your environment would follow.
So essentially, let's say that all traffic in your environment took a certain path,
but you wanted to make sure management traffic took a different path.
Well, you could use policy-based routing for that management traffic.
So that way there, if it comes from this management IP addressing space,
and it's related to this type of management traffic using these port numbers and protocols
and whatever, then I want my router to route it this way instead of using the normal
behavior of the routing table. So to create or to implement policy-based routing,
one, we need access control lists for identification purposes. We then need route
maps to define what happens. So match these access control list entries and then set
the next hop IP address to a certain value.
So that way there, I can route it a different way.
And then we can apply it either to our interfaces, and we always apply policy-based routing
on the inbound interface. What does that mean? It means that if I have a router
and traffic is flowing this way, I have to apply it to the interface when the traffic comes in.
I can't apply to the interface that traffic is leaving because by then it's too late.
Because by that point, we'd have already routed and it's over.
Whereas we want to policy-based route before the routing table is checked.
So you apply it on the inbound interface for the arriving packets. So you go to the interface and
use the IP policy route map command. It's that simple. We can also perform policy-based routing
on the control plate. Now, what is a control plate? It's a virtual interface on your router
that controls the traffic that is being punted to the CPU.
In session number eight, we're going to talk about control plane policing
as a way that we can protect our control plane. So, what we have here is we have a virtual interface
called the control plane interface.
And any control traffic gets punted to the control plane. So, with policy-based routing,
we could apply
policy-based routing to that control plane interface. There it is.
That would be for traffic generated by the router. So, in that case, instead of it applying to the
traffic that is being punted, it's for the traffic that is being sent out of the control plane
interface. Pardon me. I misspoke when I did that diagram drawing. Let's go back to that just to
make sure we've got that clear. So, when we get to control plane policing, we'll show you how to
protect the packets that are being punted, right? But in this case, we're protecting, so virtual,
virtual interface. With control plane policing, we're going to protect traffic being punted this
way. But with our policy-based routing, I'm going to be able to control which way it goes,
whether it's this way or this way, as it leaves that interface, so traffic that is generated by
the router. So, if I generate a ping packet on the router, then what will happen is that that
traffic is leaving that virtual interface, then when it decides how to route it, it's the policy
that will be applied for routing as opposed to the routing table. So, for example, when you ping from
the router, the exiting interface based on the routing table information is what's going to be
used. But if I policy-based route, then I can basically choose what interface I want to use
in order to send that traffic based on the next hop IP address. So, that's what we're doing here
in both these scenarios. So, as traffic's arriving inbound, I can tell my router to route that
traffic a certain way without using the routing table. And then for packets that are generated
by the router, it doesn't matter whether it's OSPF or BGP packets or ping packets or trace
telnet pass, anything like that, I can control which interface they leave. SNMP packets, I can
control NTP packets. You can control anything that is locally generated by the router and control
which interface it goes out of. Why? Because anything you can imagine in ACL is what can be
used here. All right. So, what are we going to do here? We are going to do a little silly, little
tiny scenario. That's what we're going to do. And this scenario is going to be based on the fact
that we are going to have traffic that starts here. It's going to end up getting to R2.
And then that traffic normally goes like this up to the internet.
So, in order for us to test this, let's go to our PC and let's see if our PC is even able to
get to those networks right now because we've done a lot of crazy stuff. Oh, and by the way,
I have removed BGP on all my routers. So, BGP is not even running anymore. So,
that way we don't end up with BGP right now because we've done so much with BGP, it's a mess.
So, I just got rid of BGP on all the routers. And so, right now, what do we have? We essentially
have just OSPF running like this. So, this is all OSPF. And this is going to be our default
routing out to the internet. So, our internet's here. And we're not running BGP anymore. So,
let's do a trace to 8.8.8.8 and just see which way it's going.
So, it looks like it followed this path. Looks like it followed that path perfectly.
What about the other option that I want to do a test with?
So,
wait a second. No, it didn't. I'm looking at that right now knowing, wait a second. No, no. The
first one actually went this way, folks. The first one actually went this way.
The second one went this way. That's what happened to us right there.
And the reason why is because right now we're learning about the default route from R1
from our OSPF environment that we created a while back. So, in order for me to do my
demonstration that I want to do, we got to get that out of here. I want everything to be going
through R2 right now just for this discussion. So, let's do do show IP route. You'll see we're
load balancing. Yep, there you go. We're load balancing. So, that's why 23.1 was actually R1.
So, anyway, I was looking at the output of PC1. That's R1. That's R1. That one's R2. So,
let's go ahead and just simply go to R1 and remove the default information originate
command right now. So, I don't want that interfering with my demo.
So, now that I've removed that, we should see that DSW1 only has one way to go.
And now if we trace route on my client, both of them should be going to R2. And that's what I want
for this demonstration right now. I mean, there's other ways we could have manipulated this, other
things we could have done. But for right now, just to keep things simple, we'll just do it this way
to make sure that we have the traffic going towards R2 for both of them. All right, good.
So, now we're set up for the demonstration. Let's go ahead and policy-based route
this traffic here. So, all the traffic going to 8.8.8.8.
What I want to do is I want to force it to instead, and we're just going to force it to go this way.
Now, I don't have a connection here right now. That's okay.
The goal is to see how it's being forced to go that way. Even though it's not going to be
successful at reaching the destination, the goal is, hey, as long as we policy-based route,
our demo is exactly as we wanted it to be, just to show you the difference in traffic,
how we can manipulate it. So, let's go to R2 right now.
And over on R2, the first thing we're going to have to do is indicate the type of traffic that
we want to match in this case. So, it's going to be all traffic coming from our PC at 10.0.0.10
going to 8.8.8.8. So, we're going to type in IP access list. Oops. IP access list. There we go.
We'll do an extended access control list. We'll call it access control list for our
policy-based routing discussion. Now, what we're going to do is we're going to match,
so we're going to permit, because we want to match the traffic that is ICMP-based.
So, I'm pretty sure if I recall correctly, trace route traffic from a Windows PC is using ICMP and
not UDP. So, ICMP coming from 10. or host, so specifically host, 10.0.0. let's say 10,
going to host 8.8.8.8. So, that way there, in my example, I'm only affecting that very specific
type of traffic from that source to that destination. If it's coming from any other
source, it's not going to be affected. If it's going to any other destination, it's not going
to be affected. That's just my goal in this particular example. So, just think about the
fact that you could match TCP traffic related to port 443 and send it a certain way. You can match
TCP traffic related to SSH and send it a different way. You could match what? You could match QoS
markings in traffic and say, hey, if it's QoS 0, send it this way. If it's QoS 5, quality service
marking of 5, let's say, then send it this way. You have so many different options because access
control lists are so flexible, so versatile. So, whatever combination of ports and protocols and
sources and destinations and QoS markings or anything else you can put in ACL, you can policy
based route traffic based on that. Now, we need a route map because the route map is going to
define what actually happens. So, we're going to create a route map. We'll call this our route
map for policy based routing. And this is going to be a permit sequence because when it comes to
our route maps for policy based routing, whenever you put a permit, it means I want this traffic to
be policy based routed. That's what it means. Remember when we had our BGP discussion recently
and I was showing you how to do route maps and I say, okay, permit because I want to
learn this traffic, right? So, permit for that scenario meant I want to learn that traffic.
I want to learn it from the neighbor or I want to share it with the neighbor.
Whereas when I'm using a permit with policy based routing, it means I want to
policy base the traffic that matches, right? So, what do I want to match?
I want to match this access control list. So, IP address, ACL PBR.
And then I want to do what? I want to set, in our case, I want to set the next top IP address this
way. So, normally the next top IP address would be this way, but now we're going to make it go
this way. So, set IP next top and we're going to put 10.45.33.2 as the next top IP address.
Now, what about all the rest of the traffic?
Well, you have to remember that when you create route maps, do show route hyphen map.
How many do we have here? We have three different ones. So, let me clean this up so we can see just
the one we want, route map underscore PBR. So, what I want you to realize is that when you create
So, what I want you to realize is that there is another entry that you cannot see here.
It's the implicit deny all. The implicit deny all. So, it's like sequence number infinity.
Think of it that way. And the implicit deny all states for policy based routing,
whatever matches, the deny sequence gets routed normally. Notice I didn't say dropped.
Routed normally. So, what does that mean? It means sequence number 10 here matches this access
control list. And if you match this access control list, you will be sent to the next top IP address
this way. Everything else, all other traffic will match the invisible deny sequence. The implicit
deny sequence that you can't see. And therefore, all the rest of the traffic gets automatically
routed normally. How it works. Whereas with our BGP discussion, if I said deny, it means I would
not learn that prefix, or I would not share that prefix that matched whatever was in that route
map, deny sequence. So, you see how route maps would permit and deny me the access control list
So, you see how route maps, what permit and deny means,
is going to be highly dependent upon what you're using it for.
And when it comes to redistribution, permit and deny means something different as well. Like permit
means I want to redistribute this traffic, whereas deny means I don't want to redistribute. I said
traffic, I meant route. So, permit means I want to redistribute this route, but deny means I do
not want to redistribute this route. All that we get deeper into, because we'll look at all those
scenarios in the advanced routing course called NRC for a 300-410 certification exam. And that
route maps will be very, very important for that certification exam. If you can't read route maps
or use route maps, you don't sit for that exam. So, now that we've created the route map,
and we've created the ACL, now we need to apply it to our interface. So, in this case, we want
to apply it to traffic coming in, gigabit 00 and gigabit 01, both of those interfaces inbound.
So, we'll type in interface gigabit ethernet zero slash zero, and the command is IP
policy route map, and then the name of our route map, route map PBR.
And in this case, I don't even get to specify the directionality, because it's automatically
applied inbound, no matter what. Then interface gigabit ethernet zero slash one, same command.
So, it's applied to both those interfaces inbound now. So, let's go take a peek at our route map
again, and now you'll see that our route map, did it change anything? Let me just double check that.
Nope, it's the same in that case, but if we type in do show IP policy,
there you go. You'll see that it tells us what interfaces the route map is applied to for the
policy. Right now, what I want to do is I want to show you the actual
routing with the policy, and the best way to do that is debug IP policy. So, that way we can see
it in action. All right, so let's go to our PC right now, and if we go to our PC, let's trace
route one, two, three, one, two, three, one, two, three, one, two, three. Now, based on our
configuration, folks, is that going to be routed normally, or is it going to be policy-based
routed, based on what we just configured? Do you remember? Is that going to be routed normally,
or policy-based routed? Well, if you remember our access control list,
the access control list was matching a destination of 8888. So, that was the only one that would be
policy-based routed. So, this one, yes, Conrad, routed normally. Great job. So, let's go ahead
and hit enter here, and what we're going to see, when we go back to R2 now, is that
we've got a bunch of debugs. And so, you'll see here that we have traffic
that is coming from 10.0.0.10, going to one, two, three, one, two, three, one, two, three,
going to one, two, three, one, two, three, one, two, three, one, two, three.
Notice what it says, policy rejected, normal forwarding. Policy rejected, normal forwarding.
And it's saying that over and over and over again for each and every single one of them.
No match. Now, that is a good thing, right? And this one is for that, the other, what are these?
This one here is, what traffic's that? Coming from 240.23.2.
I don't even know what that's for. I'm going to have to look into that after. It's interesting.
Somebody's hacked my router. But the key here is to recognize that this traffic does not match
that access control list. Therefore, since it doesn't match the access control list,
it doesn't match sequence number 10. And what it matches is sequence number 20 of the route map.
So, since it matches, not 20, sorry, it matches the implicit deny in this case.
Entry of that route map. And so, that implicit deny is a deny meaning route normally,
normal forwarding. So, even though it says policy rejected, that's not a bad thing. That's actually
a good thing in this case. It means we're not policy-based routing. We're routing normally.
And so, routing normally means what? It means show IP route. It means we're going to send
our traffic to where? We're going to send our traffic using the default route in this case
out to the internet. So, we should be able to see that here that we went
from 10 to 001 over to R2 and then out to the internet.
Right. Now, let's go ahead and trace 8.8.8.8 because 8.8.8.8 is
actually going to then get routed this way. And so, we should see that happen now. We should see
that we'll have the hop for here. Now, it's going to fail on us, okay, because I don't have
everything set up properly to go out. I don't believe I do. I do. Oh, my gosh. Okay. So,
I am set up to make it work. I was surprised. I didn't think we had it set up properly.
But anyways, in the end, you can see that we went from where?
Actually, no, loop. We routed loop. We did a loop here. That's a routing loop. So,
it did not work properly. That's a routing loop. But it shows that policy-based routing worked.
So, 10.0.0.1, out to R2, over to branch A, back to R2, then out to the internet. Why? Because if
we go to branch A, its default route right now is pointing back to R2. That's why. But it shows
that policy-based routing worked at least. But as I said, I wasn't expecting us to be able to
get out that way because this is not set up properly. And so, we just routed right back
because of default routing. But that's okay. The idea here is that we were successful at
showing how the policy-based routing worked. But let's take a look at what our router actually
tells us about this. If we go over to R2, we'll see there's a whole bunch of messages
about policy-based routing that happened right here. So, you'll see here, let's go back up to
the very beginning of it. Where are you? There it is. So, source IP 10.0.0.10 arrived on gigabit
ethernet 060, going to a destination of 8.8.8.8. Policy match. We matched the route map called PVR,
or route map underscore PVR. We matched sequence number 10. You see that? We matched sequence
number 10. And it is a permit sequence, which means we must policy route it. So, now,
10.0.0.10 as the source going to this destination has to be sent out this interface
because that's how we get to the next top IP address of 10.45.33.2. So, therefore, we policy
routed it. And then, the next trace packet that came in, same thing, over and over and over again
for every single one of those. So, we policy routed those ones over to the other next hop.
And if we look at the outputs, I'm going to type in do you all.
If we look at the output of show IP or show route map,
the route map underscore PVR, you'll see here that it tells us that we policy routed 12 packets.
We policy routed 12 packets
in total. So, that means 12 packets have matched this access control list.
So, how do you verify if your policy is actually working or verify the number of packets
that have been successfully policy-based routed? Just look at your route map. That's how you do it.
Remember that if you type in show IP policy, it just shows you the – if you type in show IP
policy, it just shows you the interfaces that are participating in policy-based routing and the
route map that's applied. So, if you want to verify if packets are actually matching and being policy
routed, then you type in show route map and the name of that route map, and it'll tell you at the
bottom the number of packets that have matched that particular sequence. So, let's see what
happened in this case if we did something very specific. Let's try this. We have the time.
So, if we type in IP access hyphen list extended, can we do this all in the same sequence?
Not – yeah, we should be able to. So, let's go – no, I don't want to do that. No. Okay. Let's
create another one. Let's call it ACL underscore PBR2. And then I'm going to say I want to, in this
case, permit – and we're going to permit our ICMP traffic from our host, our host being who?
Our host being 10.0.0.0.10 going to host 123.123.123.123. Okay. So, this is that other
traffic that we were not policy-based routing. But what I want to show you is that we're going
to create now another route map. So, we're going to create a route map for this, but I'm going to
say deny, and let's do sequence number 20. And now I want to match this access control list.
And we are not going to provide any set. And why is that? Because it's a deny. Once you deny,
you can't really set anything. You can't really do anything. I mean, you could technically,
you know, do some things, but the key here is to realize that if you deny, what does that mean?
Deny means route normally. That's what it means. That's what I'm trying to show you right now.
So, when we look at this now, do show route-map. If you were looking at this on the exam,
okay, if you were looking at this on the exam, then you would say, okay, so this right here,
we are going to policy-based route because it says permit. And we'll policy-based route
any traffic that matches this, and we'll set it to the next hop of this. Now, if you look at this
one here, this is denied. Deny means do not policy-based route. It means route normally,
folks. Keep that in mind. Route normally. So, anything that matches this ACL gets routed
normally. So, this is what we call an explicit deny. Now, I don't really need this, right,
because there is another deny sequence after the fact. And what is that deny sequence after
the fact? It's the implicit deny that matches everything else anyways. But I'm just trying
to show you that when it comes to the policy-based routing, what does deny actually mean? Deny
actually means route normally. So, debug IP policy. Let's go ahead now to our PC,
and let's trace to 1, 2, 3, 1, 2, 3, 1, 2, 3. And as long as I configured everything properly,
we should see that we are routing normally, and we should get some output on our device about that,
right? So, routed normally, it should be. There you go. So, as you can see,
we're going from here to here. It's a policy match now. It's a policy match this time. Remember
before, it didn't say policy match. Before, what did it say for that one? Please still be there.
Please still be there. There it is. Okay. It just simply said policy rejected normal forwarding.
Policy rejected normal forwarding, right? Okay. But if we go down now, because I have an explicit
deny, the explicit deny says, ooh, we match the policy route map. Ooh, it's a deny. Okay. What
does deny mean? It means reject the policy and route normally. Policy rejected route normally.
All right. So, even though it's a policy match, the question now is, is it permit or deny? In
this case, it's deny, meaning route normally. You see that? There it is. The proof right there
that you can see. Now, if we look at the route map, is that going to actually show us that we
have matches? No. You see, the packets are still zero. The packets are still zero because we didn't
actually policy route anything, right? We just simply said, oh, you match a deny sequence,
you're denied. So, you're not going to be able to do what? You're not going to be able to
keep track of the packets that were routed normally based on that route map,
but you can definitely keep track of the packets that matched the permits in those route maps.
Policy-based routing, folks, simple example. So, think about it for the exam.
You can get any scenario thrown at you on the exam about policy-based routing.
It could be a troubleshooting scenario, it could be a configuration scenario,
it could be just multiple choice questions based on information they provide to you,
but the key here is to recognize what? One, what policy-based routing is for.
So, we've covered that. Two, what interface you apply it to. Make sure it's applied to the right
interface. Make sure the ACL is correct. Make sure the route map is correct. And the most important
thing about that ACL is make sure the right protocol is being used, the right port number
is being used, the right source of destination is being used. So, pay attention to the scenarios.
The last thing you want to do is have a policy-based routing question that you are
troubleshooting, you're configuring, you're verifying whatever it is. And in the end,
the only thing that was wrong with the whole thing is that the access control list was using,
let's say, UDP instead of TCP for port 443, right? The rest of it was all perfect. There
was nothing wrong with it. Everything was good. But what they were doing was maybe testing you
on an access control list in that case. So, be mindful that when you take this exam,
you're going to get some pretty interesting questions that you may think are related to
things like BGP or related to policy-based routing or related to OSPF. But in the end,
after you verify everything, it could be something as simple as, oh, the ACL wasn't
configured correctly or, oh, this wasn't done correctly or, oh, the interface was down.
Why? Because they're testing you on the strange things that can happen to you in an environment
to really test you. Do you really understand how everything works now as a cohesive,
holistic situation and scenario? Now, you'll still get a lot of questions that are independent.
What does this do? What does that do? How does this work? How does that work? Fine.
But it's those other ones that are now trying to get you to put multiple things together,
like was the route not configured properly? Was the ACL configured properly? Was it applied to
the right interface? These are the ones that get a little bit more challenging.
And so, before we put a bow on policy-based routing for the day,
I want to look at these default keywords here right now.
So, this is the one I gave you as a demonstration. Set IP next hop and then the next hop IP address.
So, what is the next hop router along the path that you want to policy-based route the traffic to?
So, in this case, the behavior is do exactly what this states. If traffic matches,
then set the next hop to this value and route the packet that way.
This is a little confusing at first until you wrap your head around what it really means.
I struggled with this one in the beginning. I really had a hard time getting my head around
what it does. And then all of a sudden, one day, I'm like, ah, yeah, it makes so much sense now.
Notice what it says. Set IP default, next hop, next hop IP. The only difference is this keyword
here. The default keyword. You see that? Default keyword. That's the only difference.
What, though, does this change? What does it do? It really changes the entire behavior a lot.
What it does is it says, only policy-based route. If you look in the routing table and do not find
an explicit route for the destination, and you have to use the default route,
that's when you policy-based route. All right, pause. And you're like, what?
What did you just say? Okay, let's rewind. Let's rewind. Set IP default, next hop,
next hop IP. What does that mean? This tells the router, only policy-based route
if there is no explicit route for the destination IP address of the packet in the routing table,
and you have to use the default route. If that is the case,
and you have to use the default route, then policy-based route to this next hop IP address.
Basically, what it allows you to do is only policy-based route if it's going to be the
default route that's going to end up being used. If not, then you route normally. So,
route normally based on the routing table, unless it's the default route that's going
to be used to forward the traffic. Crazy, isn't it? But that's what it means. That's
what I want you to know. I'll repeat it one more time. Only policy-based routing if there is no
explicit route in the routing table for the destination of that packet, and you have to
use the default route. So, if you have to use the default route, then you're going to policy-based
route. If you don't have to use the default route, then you don't policy-based route.
So, think about how you would craft that. You would craft that in a way that you have your
access control list matching your traffic, and then you have your route map, and your route map
would be what? Your route map would be a permit matching the access control list, and then you
would say, set IP default next hop, next hop IP. Meaning that you're only going to do this
if you've checked the routing table first, and no explicit route exists for the destination IP,
and the default route's going to be used. Now that the default route's going to be used, now I do this.
If the default route's not going to be used, then I don't do this, and I just use whatever's
in the routing table. Like, I mean, really, it takes a while to get your head wrapped around
that concept. All right, the other item we have here is CC set interface. So, same idea as this,
and this is the same idea as this, but instead of setting the next hop IP address,
you simply set the exiting interface. Now, is that actually a good idea, folks?
Is that actually a good idea to set the exiting interface instead of the next hop IP address?
Okay, the answer to that is no. If the interface is an Ethernet interface,
if it's a serial interface that's point-to-point protocol, or a serial interface that is running
HDLC, then that is okay. If it's a PPPoE interface, point-to-point protocol over Ethernet,
that's okay as well. But if it's a Ethernet interface, a pure Ethernet interface not
running PPPoE or anything like that, then you should never use this.
And it's for the exact same reason why you should never do something like this.
So, you see here how what I've done with my default route on Router2, I said I want you to
use the exiting interface FASTX and a 0SI0SI0, this one right here, which is fine until you read
this. Default route without gateway, if not a point-to-point interface, may impact performance.
That same, same issue that I have here is the same issue I get in this scenario right here,
using the exit interface, using the exit interface. What is the problem that I run
into in these scenarios? So, the problem we run into in these scenarios is related to
address resolution protocol. That's right. Let's take a look at this right now. Do
show IP route. So, notice, folks, how when I typed in this command here,
it even gave me a warning. Look at the entry in the routing table. Just read that for a second.
And I want you to answer this question. Is this actually true? 0, 0, 0, 0 is directly
connected. Is that true? Nope, not at all. Why? Because the only thing that's directly connected
to me on FastEthernet 0SI0SI0SI0 is this network right here. Everything else is beyond that,
right? Everything else is beyond that on the internet. So, this is a lie. And what does that
cause? It causes excessive ARPs. Why is that? Because any time your router sees directly
connected in the routing table, what does it do when it has to forward the packet? Well,
it has to create a frame, if you recall. And the frame needs a source and destination MAC address.
So, the source MAC address is the MAC address of the exiting interface. So, FastEthernet 0, 0, 0.
But the destination MAC address in this case, it says it's directly connected.
It says it's directly connected. So, what does that mean? It means I will ARP for the MAC address
of the IP address that's in the packet. So, for example, if PC1 right now,
for example, if PC1 right now is going source 10.0.0.10, destination 8.8.8.8,
then when this router needs to send it out this interface, it ARPs for MAC of 8.8.8.8.
Now, pretend 8.8.8.8.8 is out here somewhere. Will I get the MAC address back for 8.8.8.8.8?
No, because 8.8.8.8 doesn't live on this directly connected network.
So, I'm not going to get the MAC address back. However, we do have a feature enabled on Cisco
devices called ProxyARP. And so, ProxyARP is enabled here, for example, by default.
And what ProxyARP does is if the router receives an ARP request that doesn't make sense for that
broadcast domain, but the router has an entry in its routing table to get there,
then it will respond back with its own MAC address. So, now when I ARP for 8.8.8.8,
I get this router's MAC address back. When I ARP for 8.8.8.8.9, I get this router's MAC
address back. When I ARP for 8.8.8.8.10, I get this route. Every single packet, I'm going to
have to ARP for the MAC address of, and this router is going to respond back with its MAC
address each and every single time, over and over and over and over. Again, nonstop with ProxyARP
enabled. So, for example, if we do something like, let's see if I can just kind of demo this.
Let's see. We'll go 8.8.8.8. We'll just do 1. So, minus N1. Okay. And then let's do 9. Okay.
That should fail. And that's fine. I want it to fail because it doesn't really exist. Okay. 10.
But what you're going to see here is as we now go, if this demo works for me like I want it to,
if I look at the ARP cache on router number two,
what? Every single entry is showing up. So, in this case, you see how it's incomplete.
It's incomplete in these cases because that router is not able to respond to those messages because
it doesn't actually have a route to get to those particular networks. That's why. But if it had a
route to get to those particular networks, then it would respond back. So, what does that mean?
It means that if you have users in your environment and they're all going out to the internet,
and let's say they go to a million different places that day, a million different IPs,
then your router would have a million different ARP entries, but they would all point to the same
next hop MAC address. Same, same, same, same. That's all really excessive. You see, remember
that when we have our routers, when we specify the what? When we specify instead of the next hop,
or sorry, instead of specifying the exiting interface, when we specify the next hop IP
address instead, like 203.0.113.89 as the next hop, then what happens in those scenarios
is that you only have to ARP for the MAC address of this because the frame goes from my router to
your router, my router to your router. And when you look at the routing table, do show IP route
now, it doesn't say directly connected. It says via this next hop. So, it changes the behavior of
the router. So, now that the router has 203.0.113.89 as the next hop, that is going to be the destination
MAC address for the frames. Source frame here, destination frame there. I don't have to ARP for
the destination. I don't have to ARP for the MAC address of every single destination IP in the
packet because they're not directly connected to me. I have to go to the next hop address.
So, that's why we don't specify the exiting interface on ethernet, on static routes that
go out ethernet interfaces or default routes that go out of ethernet interfaces. And if you do,
it's not a good thing. It could actually degrade the performance of your router and fill up the
ARP cache and cause problems. So, we always use the next hop IP address. So, the same philosophy
applies in this scenario as well. If you use the exit interface, what's going to happen now when
you policy-based route to the exit interface? You think you're directly connected. So, now you have
to ARP for the MAC address of the destination IP in the packet, which it's not going to be there.
And so, since it's not going to be there, it's going to be incomplete. Or proxy ARP's enabled,
then you're going to get a response back. But that means the ARP cache on the router is going to fill
up and fill up and fill up and fill up and fill up for every single packet that you policy-based
route. And you don't want that. You don't want that. So, if it's an ethernet interface, this
is the path you want to take. If it is a serial point-to-point protocol interface, which probably
none of you have anymore, HDLC serial interface, again, point-to-point, a pure point-to-point
interface, or PPPoE interface, then you can go ahead and use these. So, most modern-day
static routing is not going to use the exiting interface anymore. We used it back in the day
on PPP interfaces. We used it back in the day on HDLC interfaces. We used it back in the day on
PPPoE interfaces, right? Same thing with this. If the exiting interface is one of those, no problem
with policy-based routing. But ethernet interfaces don't use this in the real world. Stick with this
for all those different types of scenarios that use ethernet interface. All right. That's the
moral of that story, so you understand the differences between those for the certification
exam and why one is more important than the other. All right. And there you go, folks. Policy-based
routing, make sure you know it for the certification.