Why does an ACL on R1 prevent R2 from pinging itself?

Hello community,

This is disturbing my mind in that I do not understand the operation behind this behavior. I have a simple configuration here:

R1 s0/0-----------s0/0 R2

R1(config)#do sh ip int b | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  192.168.1.1     YES manual up                    up
Loopback0                  1.1.1.1         YES manual up                    up
R1(config)#do sh run | s router
router eigrp 90
 network 0.0.0.0
 auto-summary
R1(config)#do sh ip eigrp neigh
IP-EIGRP neighbors for process 90
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.1.2             Se0/0             11 00:04:07   82   492  0  3
R1(config)#do sh access-l
Extended IP access list 100
    10 permit eigrp any any (45 matches)
R1(config)#do sh run int s0/0
Building configuration...

Current configuration : 111 bytes
!
interface Serial0/0
 ip address 192.168.1.1 255.255.255.252
 ip access-group 100 in
 clock rate 2000000
end
R1(config)#do ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1(config)#do ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R1(config)#do ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

 

R2(config)#do sh ip int b | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  192.168.1.2     YES manual up                    up
Loopback0                  2.2.2.2         YES manual up                    up
R2(config)#do sh run | s router
router eigrp 90
 network 0.0.0.0
 auto-summary
R2(config)#do sh ip eigrp neigh
IP-EIGRP neighbors for process 90
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.1.1             Se0/0             11 00:06:14  100   900  0  3
R2(config)#do ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
R2(config)#do ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
R2(config)#do ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

 

  1. Is R1 pinging its s0/0 IP address considered inbound so the ACL denies it? I totally understand pinging 192.168.1.2 from R1 won't work because the response is being denied
  2. Why can R2 not ping its s0/0 IP address if the ACL is applied inbound on R1? Do serial connections act like mapping a router's own IP address to a DLCI so the packet goes to the neighbor first and then back in?

This behavior is not seen on ethernet:

R1(config)#int f0/0
R1(config-if)#ip add 192.168.2.1 255.255.255.252
R1(config-if)#no shut
R1(config-if)#
*Mar  1 00:11:49.319: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:11:50.319: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 00:12:04.595: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 90: Neighbor 192.168.2.2 (FastEthernet0/0) is up: new adjacency
R1(config-if)#do ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/28/56 ms
R1(config-if)#ip access-g 100 i
R1(config-if)#do ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

 

R2(config)#int f0/0
R2(config-if)#ip add 192.168.2.2 255.255.255.252
R2(config-if)#no shut
R2(config-if)#
*Mar  1 00:12:04.011: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
R2(config-if)#
*Mar  1 00:12:04.839: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 90: Neighbor 192.168.2.1 (FastEthernet0/0) is up: new adjacency
*Mar  1 00:12:05.011: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

Before applying ACL 100 inbound on R1's f0/0
R2(config-if)#do ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/72 ms

After applying ACL 100 inbound on R1's f0/0
R2(config-if)#do ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Thanks in advance

Comments

  • can I see routing table ?

  • Routing table? hmmm not sure what's the relation but since I no longer have that setup from R2's perspective it should have loocked like this:

    1.1.1.1/32 via EIGRP
    192.168.1.0/30 Directly Connected
    192.168.1.2/32 Local
    192.168.2.0/30 Directly Connected
    192.168.2.2/32 Local

    From R1's perspective pretty much the opposite:

    2.2.2.2/32 via EIGRP
    192.168.1.0/30 Directly Connected
    192.168.1.1/32 Local
    192.168.2.0/30 Directly Connected
    192.168.2.1/32 Local

    I mean, there's nothing complicated here... it's just R1 and R2 connected via s0/0 and f0/0 as EIGRP neighbors and R1 with an inbound ACL on both interface allowing EIGRP traffic only

  • This is a characteristic of serial interfaces.

    "Do serial connections act like mapping a router's own IP address to a DLCI so the packet goes to the neighbor first and then back in?"

    You hit the nail on the head.  This happens regardless of layer 2 protocol (HDLC, PPP, FR, etc.) Try debug ip packet on R2 or add the log keyword to the ACL deny entry to see if you can see the packet.

    If anybody can find documentation explaing this general behavior when using serial interaces I'd be interested to read it.  The specific solution of "frame-relay map ip <localaddress> <dlci>" when using FR is well known, but I only recently found out that this behaviour is related to the physical medium itself.

  • Here... I was doing something else so I had EIGRP setup before but just take this very simple scenario:

    R1 s0/0---------s0/0 R2

    R1= 192.168.1.1/30
    R2 = 192.168.1.2/30

    R1(config)#int s0/0
    R1(config-if)# ip add 192.168.1.1 255.255.255.252
    R1(config-if)# no shut

     

    R2(config)#int s0/0
    R2(config-if)# ip add 192.168.1.2 255.255.255.252
    R2(config-if)# no shut
    R2(config-if)#do ping 192.168.1.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/15/48 ms
    R2(config-if)#do ping 192.168.1.2

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

    !!!!!


    R1(config)#access-l 100 deny ip any any
    R1(config)#int s0/0
    R1(config-if)# ip access-g 100 i

     

    R2(config-if)#do ping 192.168.1.2

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
    UUUUU
    Success rate is 0 percent (0/5)

  • Oh great Chris818... I really wanted to make sure this wasn't an issue with GNS3 since I don't have real gear to test it on.

    Thanks a bunch :)

  • Thanks a bunch for confirming my thoughts Cris818, I thought this might have been an issue with virtual environments only but yeah, debug output does show exactly what is going on:

    R2(config-if)#do ping 192.168.1.2

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
    UUUUU
    Success rate is 0 percent (0/5)
    R2(config-if)#
    *Mar  1 00:16:57.679: ICMP: dst (192.168.1.2) administratively prohibited unreachable rcv from 192.168.1.1
    *Mar  1 00:16:57.723: ICMP: dst (192.168.1.2) administratively prohibited unreachable rcv from 192.168.1.1
    *Mar  1 00:16:57.735: ICMP: dst (192.168.1.2) administratively prohibited unreachable rcv from 192.168.1.1
    *Mar  1 00:16:57.735: ICMP: dst (192.168.1.2) administratively prohibited unreachable rcv from 192.168.1.1
    *Mar  1 00:16:57.739: ICMP: dst (192.168.1.2) administratively prohibited unreachable rcv from 192.168.1.1

     

    R1(config-if)#
    *Mar  1 00:16:57.287: ICMP: dst (192.168.1.2) administratively prohibited unreachable sent to 192.168.1.2
    *Mar  1 00:16:57.355: ICMP: dst (192.168.1.2) administratively prohibited unreachable sent to 192.168.1.2
    *Mar  1 00:16:57.371: ICMP: dst (192.168.1.2) administratively prohibited unreachable sent to 192.168.1.2
    *Mar  1 00:16:57.375: ICMP: dst (192.168.1.2) administratively prohibited unreachable sent to 192.168.1.2
    *Mar  1 00:16:57.375: ICMP: dst (192.168.1.2) administratively prohibited unreachable sent to 192.168.1.2

  • interesting indeed; maybe it has something to do with the fact that serial connections are true point to point and that u can use /31 on them, unlike Ethernet.

  • sorry MartinLosik but that is not true, you can indeed use /31 on ethernet... the reason for R2 not to be able to ping itself when an ACL is applied on R1 inbound has to do with how serial connections behave as opposed to ethernet. In serial the packet first goes to the neighbor and then back to the source even though R2 is pinging itself whereas in ethernet the packet would just go directly to itself...

    R1 s0/0--------s0/0 R2
    R2 pinging IP of its s0/0 interface: packet first goes to R1 and then back to R2's s0/0, thus an inbound ACL denying traffic on R1 would drop the packet

    R1 f0/0--------f0/0 R2
    R2 pinging IP of its f0/0 interface: packet goes directly to R2's f0/0, thus an inbound ACL denying traffic on R1 would not interfere with this traffic

  • I see, thanks for explanation.

  • On a related note, if you have a serial connection and you are having circuit issues, one of the ways you can test is when there is a loop thrown up at the remote end and you ping yourself. The caveat of this is that if you use PPP, you need to change the encapsulation back to HDLC because the PPP won't form looping back to itself.

Sign In or Register to comment.