Unicast Reverse Path Forwarding (uRPF)

Normally 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.

When you use multicast, checking the source of multicast IP packets is a very important topic. Right now I’m only talking about unicast IP packets.

uRPF is a security feature that prevents these spoofing attacks. Whenever your router receives an IP packet it will check if it has a matching entry in the routing table for the source IP address. If it doesn’t match, the packet will be discarded. uRPF has two modes:

  • Strict mode
  • Loose mode

Let’s take a look at the difference between both modes and how to configure them.

Strict Mode

Strict mode means that that router will perform two checks for all incoming packets on a certain interface:

  • Do I have a matching entry for the source in the routing table?
  • Do I use the same interface to reach this source as where I received this packet on?

When the incoming IP packets passes both checks, it will be permitted. Otherwise it will be dropped. This is perfectly fine for  IGP routing protocols since they use the shortest path to the source of IP packets. The interface that you use to reach the source will be the same as the interface where you will receive the packets on. Here’s an illustration to demonstrate this:

URPF Strict

R1 has installed network 2.2.2.0 /24 in its routing table and in order to reach this network it will use the FastEthernet 0/0 interface. Suddenly this router receives an IP packet with source IP address 2.2.2.2 on both of its interfaces. The one it receives on the FastEthernet 0/0 will be accepted but the packet on the FastEthernet 0/1 interface will be dropped because this is not the interface we use to reach this source.

Let’s configure the example above to see how it works. I’ll use the following topology:

urpf demo topology

We will configure R1 with a static route so it can reach the loopback0 interface of R2:

R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2

This is what the routing table looks like now:

R1#show ip route   

C    192.168.12.0/24 is directly connected, FastEthernet0/0
C    192.168.13.0/24 is directly connected, FastEthernet0/1
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 192.168.12.2

Now we’ll configure uRPF strict mode on both interfaces:

R1(config)#interface fastEthernet 0/0
R1(config-if)#ip verify unicast source reachable-via rx

R1(config)#interface fastEthernet 0/1
R1(config-if)#ip verify unicast source reachable-via rx

You can verify that it has been enabled on the interface like this:

R1#show ip interface fastEthernet 0/0 | include verify
  IP verify source reachable-via RX

R1#show ip interface fastEthernet 0/1 | include verify
  IP verify source reachable-via RX

To test uRPF we’ll send some pings from R2 first, these should be accepted:

R2#ping 192.168.12.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

As expected this ping works. Now I’ll create a new loopback interface on R3 with the 2.2.2.2 IP address on it so that we can spoof this IP address:

R3(config)#interface loopback 0
R3(config-if)#ip address 2.2.2.2 255.255.255.255

Now we’ll send some pings from this loopback:

R3#ping 192.168.13.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
.....
Success rate is 0 percent (0/5)

The packets will make it to R1 but they will be dropped there, we can verify this as following:

R1#show ip interface fastEthernet 0/0 | include drops
  0 verification drops
  0 suppressed verification drops
R1#show ip interface fastEthernet 0/1 | include drops
  5 verification drops
  0 suppressed verification drops

Above you see that the spoofed packets on the FastEthernet 0/1 interface have been dropped.

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

R1

hostname R1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip verify unicast source reachable-via rx
!
interface FastEthernet0/1
 ip address 192.168.13.1 255.255.255.0
 ip verify unicast source reachable-via rx
!
ip route 2.2.2.2 255.255.255.255 192.168.12.2
!
end

R2

hostname R2
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
end

R3

hostname R3
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.13.3 255.255.255.0
!
end


Now let’s take a look at loose mode…

Loose Mode

Loose mode means that the router will perform only a single check when it receives an IP packet on an interface:

  • Do I have a matching entry for the source in the routing table?

When it passed this check, the packet is permitted. It doesn’t matter if we use this interface to reach the source or not. Loose mode is useful when you are connected to more than one ISP and you use asymmetric routing.The only exception is the null0 interface, if you have any sources with the null0 interface as the outgoing interface then the packets will be dropped. Take a look at this illustration:

URPF Loose

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

510 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi HSV,

    That’s right, the pings won’t work since R1 will forward traffic for 2.2.2.2 to R2. In this example I just used this to demonstrate that RPF wasn’t dropping the packets. When you use loose mode, RPF will accepts packets as long as there is an entry in the routing table, it doesn’t matter where it points to.

    Let me give you an example where you could use loose mode:

    Let’s say that R1, R2 and R3 are running BGP. R1 is a customer router, R2 belongs to ISP1 and R3 belongs to ISP2.

    On R1 we have installed a route for 2.2.2.0/24 towards ISP1, our primary conn

    ... Continue reading in our forum

  2. Hello Paul

    It really depends on the platform you are using. Higher end platforms (6500/6800 with the appropriate supervisor as well as Nexus platforms for example) will support uRFP occurring in hardware thus providing for fast checking and no taxing of other resources.

    ... Continue reading in our forum

  3. Hello Ajay

    uRPF is a feature that checks the source address on a packet and compares it to the routing table. This means that by definition, uRPF will ONLY function on incoming packets. It can be enabled on any interface, but it will only operate on incoming packets on that interface. Packets that are exiting an interface have already gone through the routing table lookup a

    ... Continue reading in our forum

  4. Hello sales2161

    According to Cisco:

    The Unicast RPF drop count tracks the number of drops at the interface. The Unicast RPF suppressed drop count tracks the number of packets that failed the Unicast RPF check but were forwarded because of the permit permission set up in the ACL.

    So the suppressed drop count iterates by one whenever the uRPF condition is not met, but the packet is forwarded anyway because of a permit entry in the ACL.

    This has been taken from the following Cisco documentation:

    ... Continue reading in our forum

  5. Good morning Laz,
    Thanks for the update. I saw this on another source that i use for studying.

    Thanks again,
    Cecil

44 more replies! Ask a question or join the discussion by visiting our Community Forum