access-list matches are 3 times as much as packets received, why?

[CSCO10892433]

Ping frome r1:

r1#ping 10.100.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.100.12.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms

r1#

and show access-list on r2:

r2#sh access-lists | i match

470 permit ip any any dscp ef (15 matches)

Anybody can give me a good explaination for this? And what is the exact debug command that I can use to see the packet-matching events happening on the router?

TIA

SSLIN

[Kevin Dorrell]

Is R1 pinging its own address on a point-to-point link by any chance?

Try disabling all your fast switching and do a debug ip icmp packets. You may find there is more going on than just a simple ping.

Kevin Dorrell

Luxembourg

[CSCO10892433]

Hi, kevin

Thank you for the reply.

They are the fastethernet interfaces in the same vlan. R1 has address 10.100.12.1 assigned to fa0/0 and r2 has address 10.100.12.2 assigned to fa0/0. I also apply the access-group inbound on r2's fa0/0 interface.

I redo the lab per your suggestion: enable debug ip packet, disable cef switching. For clarity, I ping only one packet this time and the result indeed reduce one packet. But I still don't get it from the debug output. Why does CEF have to do with this? What does the other one more packet come from. (I expect 1 packet but there are 2 matches even after I disbale the cef; What other feature should I disable further?)

BR

SSLIN

[Kevin Dorrell]

Sorry, maybe I wasn't clear about the CEF. We switched it off just so that we could see all the packets in the debug. If CEF is active, then packets can miss the debug. It shouldn't make any difference to the packet count on the access-list, although in this case I am surprised to see that it seems to have done so.

Have you used this access-list in two different places, for example both on input and output? Or maybe in the service policy as well? If so, it will count a packet once for each time it goes through the access-list.

Is it possible your echo-reply is hitting the access-list as well as the original echo request? You could detect this by splitting up the access-list:

10 permit icmp any any echo

20 permit icmp any any echo-reply

30 permit ip any any

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

I believe that your question whether the access list might be applied in more than one place is a good question. I believe that there is another possibility to consider as an explanation. Access lists accumulate the hit count from the time the router booted or from when the access list counters were cleared. Is it possible that there had been some traffic hitting the access list before the test began.

HTH

Rick

[CSCO10892433]

Hi, kevin, rick

Thank both of you for the concerns about this topic.

Here is the result of acl-lab-round-3 (see attachment)and it is same as before. I also attach the running-config that I don't see any other place the ACL is applied. Please check it for me , maybe I'm missing something on somewhere.

BR

SSLIN

[Richard Burts]

SSLIN

Thank you for posting the additional information and especially for posting the configuration. Based on this I believe that I can explain at least 10 of the 15 matches in the access list. I will start by pointing out 2 significant things. 1) The serial interface with address 10.100.120.2 appears to be a normal point to point serial interface. 2) The ping is for your own address. In a previous post you say that you are pinging the Fastethernet interface. But clearly this test is with serial point to point.

What happens when you ping your own address on a point to point serial interface is that the router forwards the ping (echo-request) out the point to point interface to the neighbor, the neighbor receives the ping requests and forwards them over the point to point back to you (here are the first 5 matches). Then the router generates the ping response (echo-reply) and forwards them out the point to point interface to the neighbor, the neighbor receives them and forwards them back to you (here are the next 5 matches).

The test you posted was with access list 101 which just has a single line which matches any IP packet. I believe that if you do the test with access list 102 which has separate lines for echo-request, echo-reply, and other IP that you will see 5 echo-request, 5 echo-reply, and perhaps 5 others. If you add the log parameter to the last line so that it has permit ip any any log, then you will get some indication what the other packets are.

It might be helpful to see the configuration of the router on the other end of the point to point serial (we assume that its address is probably 10.100.120.1).

HTH

Rick

[CSCO10892433]

Hi, Rick

Sorry for the inconsistency among the several labs I did. I change the routers and the interfaces because I want to see if there is any difference. I'm sure I was pinging from the other router, not my own router. I will do the lab this night again with "ping 10.100.120.2 source 10.100.120.1" to make sure I'm pinging from different router. I will let you know.

BR

SSLIN

[CSCO10892433]

Hi, Rick

I just finish the lab round 4, but I found more wierd thing: if I add the log keyword to the and of each acl entry, I got only 5 matches!!!Without the log keyword, I got 15 matches as usual. How do you explain this?

BR

SSLIN

PS: This time I'm very sure I'm not pinging the same router. All pings are from BB1 to BB3.

[Richard Burts]

SSLIN

What you had posted before indicated that the ping was to the routers own interface. What you have posted this time is clear that the ping was to the remote router interface. I am puzzled by the result showing 15 hits in the access list and even more puzzled that the results show only 5 hits when the log key word is added.

HTH

Rick

[sandeepkhera]

Hi guys,

Today I also noticed the same thing at my LAB. and during googling thie cause i found this forum only and unfortunately with no specific answer.

Does any one of you found the reason why it is happening. If yes then please post it here.

Regards:

SK

[paolo bevilacqua]

Cisco IOS often have bugs, this can be one.

If it is important to you, change image.

[paolo bevilacqua]

I challenge the person that low rated my post above to come forward and give an explanation about.

What I have stated is 100% true, the fact that "you" did not liked my answer does not change your position of great ignorance and rudeness.

.

[sandeepkhera]

But this I have observed on different routers with differnt IOSs.

So Its not possible that there is BUG in all.

Regards

SK

[sandeepkhera]

Any finding guys???