Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Reflexive ACL behaviour

Hi friends,

A basic doubt.

I am checking REFLEXIVE ACLs. During Lab i found this behaviour. (R1)-----(R2)

where is untrusted & is trusted.

Reflexive ACLs are configured and working perfectly as expected. When I

initiated ICMP ping from it is creating Reflexive ACL in R2 as


permit icmp host host (10 matches) (time left 76)

I thought after this temperory ACL creation, I should be able to ping from to But it failed to ping even though I am able to

ping from

Is this a normal behaviour?

Thanks for valuable answers


Cisco Employee

Re: Reflexive ACL behaviour

Hi Sairam,

It depends on how you set up both the pair of ACLs. Can you post the configuration of the router that contains the reflexive ACL?

Best regards,


New Member

Re: Reflexive ACL behaviour

Hi Peter,

Configuration is done on R2

ip access-list TRUSTED-UNTRUSTED

permit ip any any reflect SAIRAM

ip access-list UNTRUSTED-TRUSTED

evaluate SAIRAM

interface ser 0/0

des #### UNTRUSTED #####

ip access-group UNTRUSTED-TRUSTED in

interface fa 0/0

des ##### TRUSTED #####

ip access-group TRUSTED-UNTRUSTED in

Peter, this is the snapshot of the configuration made on R2

Hope this is sufficient to help me


Cisco Employee

Re: Reflexive ACL behaviour

Hello Sairam,

Your config is OK. I believe that the reason that it does not work lies in the fact that despite the "show access-list" command shows only the hosts and protocol in your reflexive ACL, internally the reflexive ACL holds more information about how the return packet should look like. I suspect that for ICMP, when you ping from inside to outside, the reflexive ACL will match for an ICMP echo-reply message. This would also explain why pinging from outside to inside does not work: the packets are of the type ICMP echo, not echo-request as the reflexive ACL entry expects.

Maybe you should try testing this with a real equipment and some packet generator that is able to generate a packet from an arbitrary port - the "netcat" utility for Linux can be used for that. I suggest using UDP packets as they have no state information in their header.

Best regards,


CreatePlease to create content