# Unicast Reverse Path Forwarding (uRPF)

**URL:** https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031
**Category:** Lessons Discussion
**Created:** [December 26, 2016, 6:38pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031 "2016-12-26T18:38:00Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [December 26, 2016, 6:38pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/1 "2016-12-26T18:38:00Z")

</div>

This topic is to discuss the following lesson:

[https://networklessons.com/cisco/ccie-enterprise-infrastructureunicast-reverse-path-forwarding-urpf/](https://networklessons.com/cisco/ccie-enterprise-infrastructureunicast-reverse-path-forwarding-urpf/)

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [May 20, 2013, 9:18pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/2 "2013-05-20T21:18:20Z")

</div>

First step to protect against DoS and DDoS attacks.

Further ones may include RTBH, prefix-lists denying the bogon and spoofed prefixes, CoPP on the backplane and rate-limiters.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [June 10, 2013, 7:09am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/3 "2013-06-10T07:09:57Z")

</div>

Due to architectural differences, Nexus 7k uses the “allow default” option implicitly, while the 5k doesn’t.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [September 26, 2013, 4:37pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/4 "2013-09-26T16:37:46Z")

</div>

the ONLY uRPF tutorial on internet that actually makes sense, thanks very much Rene.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [October 2, 2013, 4:12am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/5 "2013-10-02T04:12:49Z")

</div>

Thanks a million Rene. Well done, well written, it simply goes straight to the point. Perfect!

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [October 6, 2013, 8:21am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/6 "2013-10-06T08:21:29Z")

</div>

hiii Rene,

Can you please explain the diff between verification drops and suppressed verification drops.

---

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [October 6, 2013, 3:15pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/7 "2013-10-06T15:15:47Z")

</div>

When you configure uRPF you can attach an ACL to it. The verification drops are packets that have been dropped, the suppressed verification drops are packets that would have been dropped by uRPF but were saved because of the ACL.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [January 17, 2014, 2:35pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/8 "2014-01-17T14:35:07Z")

</div>

This would not be possible when using policy-based routing correct? I mean unless you placed every PBR address in the acl for uRPF.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [January 21, 2014, 4:28pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/9 "2014-01-21T16:28:22Z")

</div>

great explanation mate!

---

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [January 23, 2014, 9:13pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/10 "2014-01-23T21:13:08Z")

</div>

Hmm what exactly did you have in mind Craig? uRPF is used to check incoming IP packets. PBR is used to change the destination for certain IP packets, you can apply it to inbound interfaces but that doesn’t change the check for uRPF.

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [February 24, 2014, 6:06am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/11 "2014-02-24T06:06:07Z")

</div>

A nutless monkey would understand this 🙂  
Simple and to-the-point explanation.  
Keep up the good work!!

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [May 26, 2014, 10:20am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/12 "2014-05-26T10:20:32Z")

</div>

Beautiful !!!

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [August 22, 2014, 11:56am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/13 "2014-08-22T11:56:40Z")

</div>

Really nice Rene !!!

Simple… Easy …And straightforward explanation !!!

---

<div class="post-metadata">

### Author: ![system](https://cdn-forum.networklessons.com/uploads/default/original/1X/1d2ef66728c7fbac8377748594345a3f474fce5f.png) [@system](https://forum.networklessons.com/u/system)
#### Post date: [September 7, 2014, 6:41am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/14 "2014-09-07T06:41:22Z")

</div>

Rene, it was so simple and easy approach thank you very much for helping me to understand this, Great Work!!

---

<div class="post-metadata">

### Author: ![johnfrades](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/j/e0b2c6/32.png) [@johnfrades](https://forum.networklessons.com/u/johnfrades)
#### Post date: [August 9, 2015, 8:04am UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/15 "2015-08-09T08:04:43Z")

</div>

cool lesson, one thing i have in mind is the uRPF loose mode, what i dont get is the purpose on this one.

“Since it has an entry for this source in its routing table it will accept both packets. It doesn’t care where it came from, as long as there is an entry in the routing table.”

i think this is also the normal behavior of router when no uRPF Loose mode is configured right?  
if theres a route in 2.2.2.2, R1 will accept the packets that has a source of 2.2.2.2.  
i see no difference in uRPF loose mode vs no uRPF config.

on your example, it only have a route going to R2, so the R3’s ping source loopback0 will not a reply. i simulate this one, yes it did suppressed the R3’s ping but i also have a “debug ip packet” enabled on R2 and it seems like when R1 receives the ping from R3 source loopback 0, it forwards the packet to R2. is this the behavior of uRPF loose mode?

here’s R2 debug:

```
*Aug 9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, input feature, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Aug 9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, rcvd 2
*Aug 9 14:02:16.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, stop process pak for forus packet
R2#
*Aug 9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, input feature, MCI Check(92), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Aug 9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, rcvd 2
*Aug 9 14:02:18.311: IP: s=20.0.0.1 (FastEthernet0/0), d=2.2.2.2, len 100, stop process pak for forus packet

```

the 20.0.0.1 is the interface of R1 going to R3

---

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [August 9, 2015, 2:13pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/16 "2015-08-09T14:13:05Z")

</div>

Hi John,

The difference is that normally a router will accept any packet from any source, it doesn’t matter what it has in its routing table…it’s only used for forwarding decisions.

With uRPF loose mode, the router will not accept any packets unless it has an entry for the source in its routing table.

Rene

---

<div class="post-metadata">

### Author: ![hvasudeva](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/h/6de8d8/32.png) [@hvasudeva](https://forum.networklessons.com/u/hvasudeva)
#### Post date: [October 31, 2015, 12:28pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/17 "2015-10-31T12:28:49Z")

</div>

Hi Rene,

In loose mode pings from R3 didn’t work because on R1 we have static route pointing to R2 , Correct ? This got me thinking whats the use of loose mode when pings didn’t work from R3 ? So basically in loose mode packets do get forwarded as long as we have a routing entry ( minus routing entry facing a Null0).

How does default route come in picture here ? Normally I have seen we only gets defaults from ISPs unless we have some webservers@site.

BTW - Nice tutorial!!

Cheers,

HSV

---

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [November 1, 2015, 1:55pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/18 "2015-11-01T13:55:33Z")

</div>

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 connection. When R1 sends a packet to a destination (let’s say 2.2.2.2). then we will forward it to ISP1. It’s possible however that the return traffic will come through ISP2. In this case, strict mode would drop the packet while loose mode will accept it.

Normally you only use default routes for links connecting to ISPs or on “stub” networks where you only have one exit point.

Rene

---

<div class="post-metadata">

### Author: ![hvasudeva](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/h/6de8d8/32.png) [@hvasudeva](https://forum.networklessons.com/u/hvasudeva)
#### Post date: [November 1, 2015, 10:04pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/19 "2015-11-01T22:04:42Z")

</div>

Hi Rene,

Thanks for your email. I didn’t phase my question properly. My question around default was will this criterion (below) be met in loose mode, if I have a default route ?

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

But after looking at syntax, I guess we will still have to explicitly mention that?
```
ip verify unicast source reachable-via {rx | any}**[allow-default]**[allow-self-ping] [_list_]
```
Thanks.

---

<div class="post-metadata">

### Author: ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [November 4, 2015, 10:20pm UTC](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031/20 "2015-11-04T22:20:53Z")

</div>

Hi Harmit,

It will meet your criteria if you have a default route but yes, you need to add that “allow-default” parameter. Otherwise it will drop the packet even if you have a default route.

Rene

[Next page](https://forum.networklessons.com/t/unicast-reverse-path-forwarding-urpf/1031.md?page=2)
