debug ip packet

Sep 01, 2006 10 Replies
debug ip packet open original image

I like to use the debug packet ip detail command to troubleshoot but even when I use it with an access list, the show log command captures everything, not just what I've put in the acess list. Is there a way to get only what I want in the log buffer? This is what I'm doing:



Log onto router - A 3660 running IOS 12.3(6)a


  1. Configure an access list: access-list 150 permit tcp host 10.10.59.59 host 192.168.25.14 eq smtp access-list 150 permit tcp host 192.168.25.14 host 10.10.59.59 established


  1. Turn on debug: debug ip packet detail 150 **(note, I've also tried a variation, debug ip packet 150 detail)

  2. Telnet to port 25 from the host, 10.10.59.59


  1. Run a 'show log' command on the router to look at the log



Instead of just seeing the traffic between the two hosts in the access list, I see a multitude of traffic from other hosts. Am I doing something wrong here? I would love to be able to only see the narrowed down traffic that I've specified in my access list.



Thanks!


would love to

watch the debug in your terminal in exec mode, no need to look at logs - use the "term mon" command . sounds like you have terminal logging on as well

Thanks for the quick reply! I have tried that and I still get all the unwanted traffic showing up on the terminal. Any way to limit the traffic so it doesn't scroll off the screen too quickly when I'm trying to troubleshoot?

I've put in

This is what

would love to

Are you sure there wasn't already an access-list 150? If there was, you just added to the end of it, you didn't replace it. Type

no access-list 150

before configuring the ACL, to ensure that it starts out empty.

I did confirm that there was no other access-list 150 before I created it. A "show run | inc list 150" confirms this for me now also.

Could this be a bug with IOS 12.3(6)a? I'm guess>>

That's a convoluted way to do "show access-list 150", isn't it?

Yes. It always worked for me, but it's been a few years and IOS versions since I worked on Ciscos.

Firstly:-

access-list 150 permit tcp host 10.10.59.59 host 192.168.25.14 eq smtp access-list 150 permit tcp host 192.168.25.14 host 10.10.59.59 established

In a /normal/ access list that was filtering interface traffic the "established" keyword effectively stops TCP sessions from starting by blocking the initial SYN packet which does not have the ACK bit (or RST) bit set.

formatting link
"The established keyword is used only for the TCP protocol to indicate an established connection. A match occurs if the TCP datagram has the ACK or RST bits set, which indicate that the packet belongs to an existing connection."

In a debug ACL it won't block the whole session from the debug processing.

I am not clear what exactly the issue is since you have not given an example of exactly what is getting through that you don't think should be.

Please post an example packet.

I have never seen debug behave in this way.

you can also enable the internal logging buffer

check how much free memory the router has with sh memory command

Router# show memory

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)

Processor B0EE38 5181896 2210036 2971860 2692456

2845368

on most system should be able to spare 20K, so configure:

conf t logging buffer 20000 debugging no logging coneol end

wri mem

after debug, show logging

No it does't. The established keyword doesn't block anything, it just permits the returning packets on a connection that was already allowed to start by some other entry in the ACL.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required