Can you try again. It should be permitted. With regards Kings
On Tue, Apr 17, 2012 at 11:30 AM, Eugene Pefti <[email protected]>wrote: > 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]> > Date: Tue, 17 Apr 2012 10:32:14 +0530 > To: Eugene Pefti <[email protected]> > Cc: "[email protected]" <[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]>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 >> >> Are you a CCNP or CCIE and looking for a job? Check out >> 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
