Unicast Reverse Path Forwarding (uRPF)

Lessons Discussion
1

This topic is to discuss the following lesson:

2

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.

3

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

4

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

5

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

6

hiii Rene,

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

7

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.

8

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

9

great explanation mate!

10

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.

11

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

12

Beautiful !!!

13

Really nice Rene !!!

Simple… Easy …And straightforward explanation !!!

14

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

15

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

16

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

17

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

18

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

19

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

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

1 Like