Unicast Reverse Path Forwarding (uRPF)

Hi Laz

Thanks for the info, but I think your second statement is incorrect. According to this page:

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). Regardless of whether the packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

So it seems that permitting traffic through an ACL doesn’t bypass the URPF check, but does in effect override it.


Hello Paul

Yes I stand corrected. So first the uRPF is checked regardless of the access list, and if and only if uRPF cannot find a reverse path for the packet, then it is either dropped or forwarded based on the ACL that has been specified using the ip verify unicast source reachable via command.

Thanks for the clarification!


Hi Rene,

I have couple of questions.

  1. Can i enable uRPF on both ingress & egress interface?
  2. I read somewhere that uRPF rely on CEF table. So we should enable CEF as well to work with uRPF?
  3. How uRPF work with equal & unequal cost load balancing? Like OSPF & EIGRP?


1 Like

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 and thus any uRPF operation cannot be applied to them.

Yes this is correct. According to Cisco:

An important consideration for deployment is that Cisco Express Forwarding switching must be enabled for Unicast RPF to function. This command has been enabled by default as of IOS version 12.2. If it is not enabled, administrators can enable it with the following global configuration command: ip cef

CEF is enabled by default on most routers so it is not so much of a concern. However, you must confirm that CEF is enabled for uRPF to operate.

uRPF is not actually a routing operation. It essentially checks certain conditions and if those conditions are met, the packet can then be routed normally. It doesn’t come into play at all in load balancing or routing protocol path manipulation. In this sense, it functions more like an access list than a routing protocol. Once the conditions are met (either in loose or strict mode) the packet can then be routed normally using whatever routing protocol and whatever load balancing functionality has been configured. If they are not met, the packet is dropped before it even gets to the routing table lookup.

I hope this has been helpful!


May I know more Detail about Self-pinging.
I confuse about that

Hello NyiNyi

When you enable uRPF, it checks to see that the source of the packet is in the routing table. However, whenever a router (or any network device) pings itself, the packet flow is emulated, because the packets are actually sourced from the CPU and enter the interface buffer from inside the router itself. The return path to the router’s own CPU doesn’t go via an interface, therefore it will not be routed, therefore, the source address will not be checked against the routing table and will be dropped.

By configuring allow-self-ping, you are telling the router to modify that default behaviour of uRPF, and process a self ping as a special case, so that such pings will be successful.

I hope this has been helpful!


Can you explain more the difference between verification drops and suppressed verification drops?

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:

I hope this has been helpful!


1 Like

Hello @lagapides

In the lesson example, we didn’t create any ACL but we got some suppressed drops;

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

Hello sales2161

Hmm, that’s interesting, not sure why that is happening. As Rene states in his lesson, it is possible to have an access-list added that will specify exemptions to the uRPF rule. It is these exceptions that the suppressed verification drops should count. Cisco’s documentation states that as well. I’ll ask Rene to take a look and see if he has any more insight.



Just to be sure, I just did this lab again.

The Cisco documentation states:

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. Using the drop count and suppressed drop count statistics, a network administrator can takes steps to isolate the attack at a specific interface.

Which leads to belief an ACL is required to see suppressed drops. However in loose mode, when there is no matching route, the packets are counted towards the suppressed drops. I can’t find anything in the documentation about this but that’s what happens :slight_smile:


Hello Rene & Lagapides. I just read your lesson on uRPF. I came across this question and i needed some help in understanding the answer that was chosen.

Based on the access list, once traffic from the network gets to the router, uRPF is going to check the routing table against that network and forward the traffic if it finds a match. Since that network is allowed, how is that bypassing uRPF checks for that network. Even if that network is not in the routing table, you will still get verification drops.
Maybe i am not understanding the question. Help please.


Hello Cecil

When the ip verify unicast reverse-path command is used, the feature checks to determine whether any packet received at the router interface arrives on one of the best return paths to the source of the packet. It checks this be examining the source IP address, comparing it to the routing table, and making sure that the interface it came in on matches with the interface associated with the source address in the routing table. If this is the case, the packet will be accepted and routed correctly. In such a case, the access list created in the above configuration actually does nothing.

However, if the source IP address fails this check, that is, if the source IP should not be seen on the interface the packet came in on, it will be dropped unless there is an ACL specified in the command. If there is, and the source IP address matches that in the ACL permit statement, then the check is bypassed. What this means is that the packet is successfully routed.

Note however, that regardless of whether the packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for uRPF drops, and in the interface statistics for uRPF.

I hope this has been helpful!


Thanks for your answer lagapides. I just dont see why this was the best answer to the question.

Hi Cecil

Looking at the two possible answers in your previous post, the first defines an access list and permits the subnet. Then in the interface configuration, the command ip verify unicast reverse-path is issued. This configuration simply enables uRPF on that interface, and all traffic will go through the uRPF checks, including the subnet. If fails the check, it too will be dropped. This is because the access list that was created is not actually applied anywhere. ACL 150 has simply been defined, but not applied.

In the second case, the command includes the application of the ACL like so: ip verify unicast reverse-path list 150. This means that all the uRPF checks will still be applied except for any exception referenced in the ACL. In this case, the subnet will still be forwarded even if it fails the uRPF checks, simply because ACL 150 has been applied to the reverse-path command.

I hope this has been helpful!


Hi Laz,
You said that the uRPF checks will still be applied except for any refererence in the ACL. But if the subnet is still forwarded even if it fails the uRPF checks, wont you see suppressed verification drops when you run the command, show ip interface Gig 0/0 | include drops?


Hello Cecil

Yes, you will see those as drops. As Cisco’s documentation states:

Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.

Let me rephrase the statement like so. uRPF checks will always take place. However, if there is a reference in a configured ACL, then even if a check fails, if it matches the permit statement in that ACL, the packet is forwarded, but a drop is recorded.

I hope this has been helpful!


Hell Laz,
Thanks for replying, I understand the point you made, but going back to the original question for a second, "you need to bypass uRPF checks for the network", if you are recording packets, weather they are dropped of being forwarded, to me that means you are not bypassing uRPF checks. How is that accomplished? Maybe I am not understanding the question. I did lab the lesson and i saw the drops and the supressed verification drops that was demonstrated.

Thanks for your patience with this.

Hi Cecil

I agree that the question is not a very fair one. It should be rephrased to more correctly reflect the functionality of the ACL option for uRPF. Is this a question from the practice tests found on Networklessons? I tried to search for it originally, but was unable to find it. If so, please let me know so I can make the appropriate changes.

Thanks for pointing this out, it’s much appreciated!


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

Thanks again,

1 Like