The Unicast RPF feature helps mitigate problems caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a verifiable IP source address

So in other words, when you enable ip verify unicast on an interface what it basically does is check if the source address of the packets received on the interface is routable via that same interface, if not it drops the packets.

See below the diagram I used to explain this feature :

To obtain reachebility to the routers loopback interfaces I did :

On R1 :
ip route 2.2.2.2 255.255.255.255 10.10.10.2
ip route 3.3.3.3 255.255.255.255 10.10.10.3
On R2 :
ip route 1.1.1.1 255.255.255.255 10.10.10.1
ip route 3.3.3.3 255.255.255.255 10.10.10.3
On R3 :
ip route 2.2.2.2 255.255.255.255 10.10.10.2
ip route 1.1.1.1 255.255.255.255 10.10.10.1

R1, R2 and R3 have full reachability to each other via the frame-relay cloud. See below :

From R2 to R1’s loopback interface :
R2#ping 10.10.10.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.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 = 16/53/92 ms

From R3 to R1’s loopback interface :
R3#ping 10.10.10.1 source loopback 0

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

As you can see all routers can reach each other’s loopback interface.
Next we’re going to make an access-list which we will use in the ip verify-unicast rule on the serial interface of R1:
R1 :
!
access-list 101 deny ip any any
!
Under the serial interface we’re going to set the verify rule :
!
interface Serial1/0
ip address 10.10.10.1 255.255.255.0
ip verify unicast reverse-path 101
encapsulation frame-relay
serial restart-delay 0
frame-relay map ip 10.10.10.2 102 broadcast
frame-relay map ip 10.10.10.3 103 broadcast
no frame-relay inverse-arp
!
Now let’s ping again.

R2#ping 10.10.10.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.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 = 20/45/96 ms

R3#ping 10.10.10.1 source loopback 0

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

As you can see we still have reachability to the loopback interfaces, this is because the traffic to the loopback interfaces are routed via R1 serial interface and R1 can reach the loopback interface via the interface it is received on.

Now we’re going to change the route to the R2’s loopback interface on R1 via VLAN 20, we will leave the route to R3 loopback interface as is.

On R1 :
ip route 2.2.2.2 255.255.255.255 20.20.20.2

If we ping again to the loopback interfaces of R1 on R2 and R3 you can see that the ping only works on R3 and that on R2 it doesn’t work any longer.

R2#ping 10.10.10.1 source loopback 0

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

R3#ping 10.10.10.1 source loopback 0

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