Jak widać na powyższym wyniku prefix 3.3.3.3 jest osiągalny przez interfejs FastEthernet1/0, czyli interfejsu podłączonego do routera R3. Teraz ustawmy uRPF w trybie strict na interfejsach routera R1.

interface FastEthernet0/0
  ip verify unicast source reachable-via rx
!
interface FastEthernet1/0
  ip verify unicast source reachable-via rx

Przetestujmy działanie tego mechanizmu. Z routera R3 spingujmy router R1 i zobaczmy co się stanie.

R3#ping 192.168.13.1 source 3.3.3.3
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 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/46/56 ms

Jak widać wszystko przebiegło bez zarzutów, ponieważ pakiet przyszedł przez interfejs FastEthernet1/0, czyli zgodnie z tablicą CEF FIB:

R1#show ip cef 3.3.3.3
3.3.3.3/32
nexthop 192.168.13.3 FastEthernet1/0

Sprawdzić działanie uRPF możemy wykonując polecenie:

R1#show ip int fa0/0 | in verif
IP verify source reachable-via RX
0 verification drops
0 suppressed verification drops
0 verification drop-rate

Jak widać mechanizm nie odrzucił pakietów, ponieważ założenia trybu ścisłego zostały spełnione.

Teraz spróbujmy wysłać pakiet z adresem źródłowym 3.3.3.3 przez interfejs FastEthernet0/0. Najprościej jest to zrobić z routera R2, w tym celu dodajmy interfejs Loopback0 z adresem 3.3.3.3/32 i wykonajmy polecenie ping:

R2(config)#int Loopback 0
R2(config-if)#ip address 3.3.3.3 255.255.255.255
R2(config-if)#do ping 192.168.12.1 source 3.3.3.3
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 3.3.3.3
.....
Success rate is 0 percent (0/5)

Nie otrzymaliśmy odpowiedzi, sprawdźmy więc czy rzeczywiście mechanizm zadziałał:

R1#show ip int fa0/0 | in verif
IP verify source reachable-via RX
5 verification drops
0 suppressed verification drops
0 verification drop-rate

Teraz sprawdźmy jak działa tryb luźy (loose mode). Zmieńmy konfiguracje intefejsów na R1:

interface FastEthernet0/0
  ip verify unicast source reachable-via any
!
interface FastEthernet1/0
  ip verify unicast source reachable-via any

i spróbujmy wykonać jeszcze raz polecenie ping na routerze R2:

R2#ping 192.168.12.1 source 3.3.3.3
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 3.3.3.3
.....
Success rate is 0 percent (0/5)

Hmm, nie otrzymaliśmy odpowiedzi, czyli wynik jest taki sam jak w przypadku trybu strict, sprawdźmy to dla pewności:

R1#show ip int fa0/0 | in verif
IP verify source reachable-via ANY
5 verification drops
5 suppressed verification drops
0 verification drop-rate

Wynik powyższej komendy jest jednak inny niż w przypadku trybu strict. Sugeruje to, że pakiety nie zostały odrzucone i powinniśmy dostać odpowiedzi, dlaczego więc się tak nie stało ?

Odpowiedź jest bardzo prosta (IP spoofing), ponieważ na R2 sfałszowaliśmy adres źródłowy (3.3.3.3), router R1 odesłał odpowiedzi do tego adresu, zgodnie ze swoją tablicą routingu, czyli do R3. Wykonajmy jeszcze raz to samo polecenie ping, ale włączmy tym razem debugowanie pakietów icmp na routerze R3:

R3#debug ip icmp
R3#
*Jul 29 10:38:02.111: ICMP: echo reply rcvd, src 192.168.12.1, dst 3.3.3.3, topology BASE, dscp 0 topoid 0
R3#
*Jul 29 10:38:04.131: ICMP: echo reply rcvd, src 192.168.12.1, dst 3.3.3.3, topology BASE, dscp 0 topoid 0
R3#
*Jul 29 10:38:06.079: ICMP: echo reply rcvd, src 192.168.12.1, dst 3.3.3.3, topology BASE, dscp 0 topoid 0
R3#
*Jul 29 10:38:07.967: ICMP: echo reply rcvd, src 192.168.12.1, dst 3.3.3.3, topology BASE, dscp 0 topoid 0

Czyli wszystko działa tak jak należy