Thanks, Kings, And now we are closer to the point that I brought up. If you take a look at the third step in my long story I have the permissive ACL. How come packets are still dropped by uRPF check ?
Eugene From: Kingsley Charles <[email protected]<mailto:[email protected]>> Date: Tue, 17 Apr 2012 10:32:14 +0530 To: Eugene Pefti <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [OSL | CCIE_Security] uRPF with access-list option The permit ACEs, permit the packet even, if fails uRPF check. The deny ACEs, deny the packet even, if fails uRPF check. The log option with these ACEs tells when they match. With regards Kings On Tue, Apr 17, 2012 at 7:19 AM, Eugene Pefti <[email protected]<mailto:[email protected]>> wrote: 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<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com>
_______________________________________________ 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
