I have modified you config as follows:
on R2 moved the config from lo100 to Fa1/0
changed the static routes from lo100 to Fa1/0
so now Fa1/0 is having ip 10.100.100.100/24
I added router R3 with Fa0/0 connected to R2 new interface Fa1/0
on R3 i have:
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 (every reply will go back to R2)
interface FastEthernet0/0
ip address 10.100.100.10 255.255.255.0 (I'm able to ping this ip from R1)
on R2 i have debug ip packet
Now we can test again your setup, pinging R2 Fa1/0 ip addres:
R2#clear access-list counters
R2#sh ip access-lists
Extended IP access list blackhole
10 permit icmp any any log
20 deny icmp any any log
R2#
R1#ping 10.100.100.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.100.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/134/156 ms
R1#
R2#sh ip access-lists
Extended IP access list blackhole
10 permit icmp any any log
20 deny icmp any any log
R2#
NO MATCHES !
Now, if I ping from R1 the ip 10.100.100.10 situated on new R3, we will have
a surprise:
R1#ping 10.100.100.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.100.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 208/242/292 ms
R1#
R2#sh ip access-lists
Extended IP access list blackhole
10 permit icmp any any log (10 matches) (here are 10 matches because my
config is with IN and OUT on the interface)
20 deny icmp any any log
R2#
we have 5 matches when packets leaving interface Fa1/0 and 5 matches when
reply packets coming back from R3 and enter R2.
The difference now is that the ip packets are leaving R2. From what I
understood from my CCNA studies, one year ago, out topology (simplified) is
like this:
R1 --> R2 --> IP (10.100.100.100) --> ACL blackhoul --> physical cable -->
IP (10.100.100.10) --> R3
When we are going from R1 to IP 10.100.100.100 we are not reaching ACL, when
going from R1 to R3, we are traversing ACL.
Maybe I'm wrong, again, I'm only a CCNA. But I'm curios about this.
--
*Simionov Daniel Adrian*
Network Engineer @ Pacris SRL
Phone: +4 0733 673 147
Email: [email protected]
<http://ro.linkedin.com/in/adriansimionov> xsimio xsimio *Please don't
print this e-mail unless you really need to!*
On Sun, Jun 13, 2010 at 3:50 AM, Jason Leblanc <[email protected]>wrote:
> This may have a ridiculous answer but I have been working on it for a while
> so I am asking for help :) I got asked why the following
> scenario isn't working and I am failing to figure out why:
>
>
> R1 -> default gateway is R2
> R2 statically routes all RFC1918 addresses to Loopback100
> Loopback100 should be able to use an ACL to permit or deny ICMP and log
>
> If I do this scenario from the ingress physical port on R2 everything works
> great. When repeated with lo100 it fails:
>
> CONFIG:
>
> R1
> conf t
> int f0/0
> ip address 192.168.1.1 255.255.255.0
> no shut
> exit
>
> ip route 0.0.0.0 0.0.0.0 192.168.1.2
>
>
> R2
> ip route 10.0.0.0 255.0.0.0 lo100
> ip route 172.16.0.0 255.240.0.0 lo100
> ip route 192.168.0.0 255.255.0.0 lo100
>
>
> ip access-list extended blackhole
> permit icmp any any log
> deny icmp any any log
>
> int lo100
> ip address 10.100.100.100 255.255.255.255
> ip access-group blackhole in
> no shut
>
>
> TEST:
> R1#ping 10.100.100.100
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 10.100.100.100, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
>
>
> DEBUG FROM R2:
> Jun 12 16:43:21.943: ICMP: echo reply sent, src 10.100.100.100, dst
> 192.168.1.1
> Jun 12 16:43:21.955: ICMP: echo reply sent, src 10.100.100.100, dst
> 192.168.1.1
> Jun 12 16:43:21.959: ICMP: echo reply sent, src 10.100.100.100, dst
> 192.168.1.1
> Jun 12 16:43:21.963: ICMP: echo reply sent, src 10.100.100.100, dst
> 192.168.1.1
> Jun 12 16:43:21.967: ICMP: echo reply sent, src 10.100.100.100, dst
> 192.168.1.1
>
> NO HITS ON ACL
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
