Hi folks,
Can you please enlighten me on the idea of using an ACL with a strict "ip
verify unicast source reachable-via rx XXX" ?
The theory says:
uRPF has an option of violation logging. With this feature, you may specify a
standard or extended access-list as follows:
ip verify unicast source reachable-via {rx|any} <ACL-NUM>. The uRPF feature
consults this access-list for packets
violating the uRPF condition. If the ACL permits a packet, it is allowed to
pass through. If the ACL denies the packet, the router drops it. You may use
the log
keyword to log the packets allowed or denied by the uRPF access-list
Here are my tests that made me ask this question:
I have the setup:
R1 ----136.1.13.0 ---- R3 --- 136.1.23.0 ---- R2
1) On R3 I configured uRPF:
interface FastEthernet 0/1.23
ip verify unicast source reachable-via rx
On R2 I configure a loopback interface and DO NOT advertize it into a IGP.
Pinging R1 from R2 across R3 sourcing it from this loopback interface produces
uRPF drops:
R2:
interface Loopback1
ip address 150.2.2.2 255.255.255.0
R2#ping 136.1.13.1 source loopback 1 repeat 10
R3#show ip int Fa0/1.23
<snip>
IP verify source reachable-via RX
10 verification drops
0 suppressed verification drops
It's totally OK because the packet is dropped on the interface without making
the router consult its routing table.
2) Now I add an ACL on R3 and match it in uRPF statement
R3:
access-list 100 deny ip any any log-input
ip access-list log-update threshold 1
interface FastEthernet 0/1.23
ip verify unicast source reachable-via rx 100
Sending the same ping from R2 which is unsuccessful and produces more drops on
R3 interface:
R2#ping 136.1.13.1 source loopback 1 repeat 10
Here I would expect denies on R3 console but they don't show. Still seeing
verification drops (20 now) which confirms the concept of uRPF but questions
ACL logging.
R3#show ip int Fa0/1.23
<snip>
IP verify source reachable-via RX, ACL 100
20 verification drops
0 suppressed verification drops
3) This time the ACL is permissive which means that uRPF should stop
verifying incoming packets against the interface it came from.
R3:
access-list 100 permit ip any any log-input
interface FastEthernet 0/1.23
ip verify unicast source reachable-via rx 100
Sending the same ping from R2 makes verification drops counters on R3 increment
(check the counter - 30)
R2#ping 136.1.13.1 source loopback 1 repeat 10
R3#show ip int Fa0/1.23
<snip>
IP verify source reachable-via RX, ACL 100
30 verification drops
0 suppressed verification drops
Here comes the gist of this question. What's the point of this ACL ? The
incoming packet is dropped regardless of its presence and use in uRPF statement.
Eugene
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
