Output Varies from Show Access-List Command

2600 with C2600-IK9O3S-M, Version 12.3(26)

Access-list 102 is applied to the outside interface incoming. When I type, "show access-list 102" I get varying output.

I always get the numbered ACEs from the config. For example: 10 permit tcp any host 192.168.0.20 eq smtp (1912 matches) 20 permit tcp any host 192.168.0.20 eq www (41 matches)

Most of the time there are a varying number of statements BEFORE the first numbered ACE in the output. These statements are NOT in the config. For example: permit icmp any host 192.168.0.30 time-exceeded (1179 matches) permit icmp any host 192.168.0.30 unreachable (5342 matches) permit icmp any host 192.168.0.30 timestamp-reply permit icmp any host 192.168.0.30 echo-reply (5304 matches)

Has anyone seen this behavior before? Why are these statements present in the "show access-list" command output?

Reply to
Bob Simon
Loading thread data ...

You are probably using ICMP inspection on one of the interfaces (e.g.: inbound on the LAN interface). Inspection creates dynamic ACEs in the return path so that you don't need to specifically configure static ACEs to accommodate return traffic.

These entries will timeout according to inspection policy configured for the specific protocol (e.g.: ICMP).

Authentication proxy (when implemented) also creates dynamic entries that are placed above those configured in you interface ACLs. Auth-proxy ACEs are typically downloaded from a RADIUS or TACACS+ server.

Best Regards, News Reader

Reply to
News Reader

Given the large number of matches with each ACE, you might want to confirm whether ICMP inspection is configured, and more importantly, what timeout interval has been configured.

The ICMP timeout should be short. You don't want the dynamic holes in the return path to exist for any longer than necessary.

e.g.:

ip inspect name icmp timeout 10

Reply to
News Reader

Thanks! You are correct. The config includes these: ip inspect name FW ftp ip inspect name FW icmp ip inspect name FW smtp ip inspect name FW tcp ip inspect name FW udp

int F0/1 ip inspect FW out

Reply to
Bob Simon

Although I know that inspection opens holes in the return path, I am not seeing entries such as those you've described when I use the show access-list command while inspected sessions are active. This leads me to believe the ACEs you are seeing may be attributable to another feature.

Are you using authentication proxy or some other feature that downloads ACLs from an access control server?

Have you seen the ICMP ACEs timeout?

Are you generating enough outbound ICMP traffic to prevent them from timing out?

Best Regards, News Reader

Reply to
News Reader

I opened a TAC case and the engineer says he's never seen this behavior before. Since I've already uploaded a new IOS image, I'm betting there is a hardware error - possibly bad memory. This is an interesting problem. I'll let you know how it turns out. Bob

Reply to
Bob Simon

This sort of behaviour does occur with reflexive ACLs.

You don't have any

permit ...... reflect 102 ! if I recall correctly

statements anywhere do you?

Reply to
Bod43

There are no reflexive ACL statements.

Late last night, the TAC engineer called me back. He had consulted with someone in the security group who stated that this behavior is normal with inspection. Apparently the original engineer was as unfamiliar with this feature as I was.

Immediately after we applied the ACL to the interface with an access-group statement, we observed many many un-numbered ACEs ahead of the sequenced (expected) ACEs in response to "show access-list

102". There may have been hundreds of these (mostly) ICMP entries.

To News Reader: I have no idea why you did not see this behavior when you looked for it in your router. Thanks for checking but I'm told that it's normal in spite of the fact that it looks very odd.

Reply to
Bob Simon

I am pretty sure that Cisco re-implemented a lot of the inspect stuff in 12.3T sort of time. If I recall correctly early 837s were "old" and about 4 years ago there were "new" ones.

Maybe the two of you are using different code?

Reply to
Bod43

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.