CCIE or Null!

My journey to CCIE!

Unicast Reverse Path Forwarding uRPF

with 5 comments

Another great security feature within every Cisco IOS ISR is uRPF, Unicast Reverse Path Forwarding. This nifty little 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.

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

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:

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.

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.

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

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.

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.

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.

You can also read more about uRPF in RFC 3704.

Written by Stephen J. Occhiogrosso

September 10, 2012 at 9:08 AM

5 Responses

Subscribe to comments with RSS.

  1. […] my last post about unicast Reverse Path Forwarding, I made quite a few references to CEF. CEF (known as Cisco Express Forwarding) is a feature built […]

  2. Great post ! This article helped to clarify a few items within in CCDA studies. Keep up the good work !

    EyeSpeakNetworks

    February 5, 2015 at 10:35 AM

  3. ok, I would say the ACL example seems wrong.

    “After that I configured an ACL so my DMVPN Tunnel traffic was not caught by the uRPF check.”

    todo this , You use “deny” for DMVPN traffic. But in cisco document the meaning is opposite.

    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_urpf/configuration/xe-3s/sec-data-urpf-xe-3s-book/urpf-acl-sup.pdf

    Access Control Lists and Logging
    When you configure an access control list (ACL) and a packet fails the Unicast RPF check, the Unicast RPF checks the ACL to see if the packet should be dropped (by using a deny statement in the ACL) or forwarded(by using a permit statement in the ACL).

    jlp999

    August 18, 2015 at 4:05 AM

    • Looks like you are correct. The config guide for 12.4 also says that same thing. It appears I need to re-lab that see what was really going on, along with updating the example in my blog post. I suppose that’s what I get for not cleaning out my configurations.

      Stephen J. Occhiogrosso

      August 18, 2015 at 8:14 PM


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: