debug ip packet

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!

Reply to
J Anderia
Loading thread data ...

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

Reply to
lfnetworking

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

Reply to
J Anderia

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.

Reply to
Barry Margolin

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>>

Reply to
J Anderia

Reply to
J Anderia

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.

Reply to
Barry Margolin

Reply to
J Anderia

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.

Reply to
Bod43

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

Reply to
Merv

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.

Reply to
Barry Margolin

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.