top of page

Unicast Reverse Path Forwarding uRPF

 

when your router receives unicast IP packets it only cares about one thing:

 

  • What is the destination IP address of this IP packet so I can forward it?

 

If the IP packet has to be routed it willl check the routing table for the destination IP address, select the correct interface and it will be forwarded. Your router really doesn’t care about source IP addresses as it’s not important for forwarding decisions.

Because the router doesn’t check the source IP address it is possible for attackers to spoof the source IP address and send packets that normally might have been dropped by the firewall or an access-list.

 

This feature has the router verify the source of any IP packets received is reachable via the routing table. uRPF is used to prevent common spoofing attacks and follows RFC 2827 for ingress filtering. The router will actually rely on the CEF table to perform lookups. uRPF works in 2 modes strict mode and loose mode, lets quickly talk about these two modes of operation.

 

  1. Strict Mode: In this mode the router verifies the source of the IP packet arrives on the same interface the router would use to reach that source address. Beware of asymmetric routing.

  2. Loose Mode: In this mode the router simply verifies the source IP can be reached via the CEF table using any interface.

 

Now that we quickly discussed the 2 different modes uRPF operates in, let’s go over a few quick tips:

 

  1. Since uRPF relies on CEF, CEF must be enabled.

  2. uRPF takes into account multiple paths, so if you are doing any equal cost load sharing uRPF will take that into account. uRPF will also take into account any unequal cost load sharing (such as EIGRP variance).

  3. Asymmetric routing is different from (un)equal cost load sharing, and can/will cause issues with uRPF.

  4. uRPF works best at the network edge, and to further specify the network edge not on your access layer the network edge facing the public internet.

  5.  

Let’s now configure uRPF, we are going to start off with the configuration of loose mode:

 

R1 (config -if)# int fa0/0

R1 (config-if)# ip verify source reachable-via any

 

This is a good time to mention uRPF is configured on an interface basis, and it is enabled by a single command. The keyword at the end of the command specifies the mode uRPF operates in, since I am configuring uRPF in loose mode I want to make sure the router can reach the source of any IP packet received on interface fa0/0 using any interface on the router.

Now let’s configure uRPF to operate in strict mode:

 

R1 (config -if)# int fa0/0

R1 (config-if)# ip verify unicast source reachable-via rx

 

You’ll notice this command is very similar to the way enable loose mode, with the exception of the keyword rx at the end of the commend, this tells the router to verify the source of any IP packet received on interface fa0/1 should be reachable via interface fa0/1 and not any other interface on the router. As mentioned previously the router verifies connectivity by looking at the CEF table, if CEF points to an interface that the packet was not received on that packet will get dropped.

Now that we have configured uRPF (simple right?) let’s issue a couple show commands to verify our configuration:

Show ip traffic – This command will tell you how many packets uRPF has dropped.

 

R1# Show ip traffic

 

Under the IP statistics the first Drop section has an entry for unicast RPF this counter keeps track of how many packets uRPF drops which is definitely useful to know. You’ll also notice 12 packets were dropped, which we will discuss later.

Another command is show cef interface %Interfacenum/num% this command will also tell you whether or not uRPF is enabled on the specific interface.

 

R1# show cef interface0/0

 

Let’s also not forget the simplest command of them all: show run interface %interfacenum/num%

 

R1# show run Interface0/0

 

One feature that makes uRPF even more powerful is the fact we can tag on an ACL specifying traffic we want checked or don’t want to be checked. For example I configured uRPF on one my lab routers that had an old DMVPN & BGP configuration running on it, shortly after I configured uRPF I noticed the BGP adjacencies to the spokes go down. After that I configured an ACL so my DMVPN Tunnel traffic was not caught by the uRPF check.

 

R1# show run | in Access-list 151

 

You guys should know by now how much I love named ACL’s but you’ll notice I used an extended numbered ACL, the reason for that on the is simply due to the fact I couldn’t use a named ACL with uRPF.

 

R1 (config)# ip verify unicast source reachable-via any ?

 

No option to use a named ACL only numbered ACLs. There are two other options there allow-default which allows the default router to be used when verifying source addresses, and allow-self-ping which allows the router to ping itself, although allowing self-ping opens the router up to a DoS vulnerability.

 

 

 

bottom of page