We talked a little bit about reverse path forwarding when we were dealing with multicast. The RPF check was used when forwarding some of the traffic to prevent loops. unicast reverse path forwarding (uRPF) works in a similar manner and it’s actually quite easy to configure. Let’s take a look at a quick example to see how it works…
Imagine a topology like this one. Here we have 4 routers that are using static routes to get to non-directly connected networks. In this case, I made the routing asynchronous by having router1 go through router2 to get to the 10.0.0.8 and 10.0.0.12 networking. Similarly, I made router4 go through router 3 to get to the 10.0.0.4 and the 10.0.0.0 networks.
Let’s do a very basic check to show the basics. Here we will configure the uRPF check on router1’s vlan 20 interface (10.0.0.5)…
This is pretty straight forward. It says to check packets coming this interface with a RPF check. If it fails, drop the packets. We can see the results of applying the check by trying to ping one of router1’s interfaces from router4…
So that’s really the main point of the configuration. The router checks to see if it would use the packets arriving interface as the return interface. If the check fails, the packet get’s dropped. We can see the drops if we look at the fa0/0.20 interface on router1…
So that’s the ‘basic’ way to configure uRPF. Now let’s take a look at some examples of how to configure some of the other options.
uRPF processing works in an order like this…
-Do the RPF check, if it passes forward the packet
-If the check fails, check for associated ACL
-If ACL exists, check to see if packets match ACL
-If ACL match exists, forward packets regardless of uRPF
Note that we specify an ACL here. If you were looking at a router and hit the ‘?’ when configuring the uRPF check the firs time, you would have seen this…
Let’s configure 2 ACLs and see if we can get them to work…
Let’s apply them one at a time to our uRPF check and see what we get…
A quick test from router4 shows that we can ping both of router1’s interfaces…
Looking at the fa0/0.20 interface on router1, we can see that the matches on the interfaces are now showing up as ‘suppressed verification drops’. We can also see that it’s configured to allow access to communication that matches the ‘reachable-via RX’ condition, or that match ACL1…
Let’s clear the counters and configure the extended ACL to see what happens…
Pings from router4 now act differently…
The pings to 10.0.0.5 aren’t working while the pings to 10.0.0.1 are. Looking at our extended ACL, I’d say that would make sense. The ACL allows the traffic from 10.0.0.14 (ICMP source on router4) to connect to 10.0.0.1, NOT 10.0.0.5. A look at the interface counters confirms what we experienced…
So now that we’ve talked about the ‘reverse-path’ configuration, we need to talk about the ‘ip verify source’ configuration. If you noticed, when you type in ‘ip verify unicast?’ on the interface sub configuration you get two options. Source of reverse-path. We just covered the reverse-path option, so let’s talk about the source option.
The truth of the matter is that they sort of do the same thing. The reverse-path command syntax appears to be getting deprecated so we should really be using the ‘source’ option (plus it has more functionality). Using the source syntax, we really have two main configuration options…
The first option is the ‘source reachable-via any’ syntax. This is often referred to as the ‘loose’ mode of operation. The ‘any’ configuration tells the router to pass the uRPF check if the prefix can be reached through ANY interface on the router. Basically, if the prefix exists in the routing table, let it through.
The second option is the ‘source reachable-via rx’ syntax. This is often referred to as the ‘strict’ mode of operation. This is exactly what we saw in the earlier examples. This check to make sure that the router can access the prefix through the SAME interface that it received the traffic on.
The ACL options work in the same manner in which they did in the above examples. If initial uRPF check fails, check the ACL for an exception and then permit. Let’s run through some examples of this quickly just to see the syntax…
This gives us the exact same behavior we saw with this last example…
Now let’s change it up a little and configure loose mode…
Here we see the pings working as expected…
It’s interesting to note here that router1 still treats loose mode as a ‘suppressed verification’…
Now let’s change things up a bit…
If we replace router1’s specific routes with a default route, let’s see what happens to our loose mode of operation…
Doesn’t work any more. If you were to look at the IP interface on router1, you would see the uRPF is failing the checks and dropping the traffic. But why is that? Well, a 0’s route sort of makes a uRPF check invalid. Thinking about it, that makes good sense. If you only have 50 specific routes and then a 0’s route for the internet, there really isn’t a lot to check right? Most routes will be internet facing and just work as expected. To make this work, we need to change the uRPF configuration…
This configuration allows the uRPF check to consider the default route during it’s checks. On the other hand, we could revert the configuration and just add a route like this…
Even though the 10’s route is effectively a summary, it still works…
The default route is the only one you need to watch out for.
So there you have it, a quick look at uRPF check. Hope this was helpful!