debug ip packet detailed gives no output

[r.schwindt]

Hi Folks !

We try to monitor traffic on a 2621 with the attached configuration.

We do a "term mon" and a "debug ip packet detailed 199".

After that we open an SSH-Connection from 10.85.0.15 to 192.168.55.15.

The debug should show this, but there's no output.

Why not ?

Any ideas ?

Regards,

Ralph

[spremkumar]

Hi

Ideally it should log the info but you arent doing ssh to router inturn making a passthru via the router to some servers i feel which mite be there in ur local lan..

instead of doing debugs and making the work intensive to the hardware resources there in ur router i would suggest to key in log keyword in the end of the ACL 199 which can also log u details about the connectivity..

regds

[r.schwindt]

Hi !

Thanks first for Your answer.

But what do You mean by "ideally" ?

Or is there a different way to monitor traffic

going THROUGH the router limited by a specific destination IP ?

Regards,

Ralph

[Richard Burts · Accepted solution]

Ralph

I have looked at the configuration that you posted and believe that I may have an explanation for your symptoms. Debug works in the router CPU and it can only report on packets that the router CPU processes. If I understand your config correctly the station which is initiatnig the SSH is connected on interface FastEthernet0/0 and the destination address (target of the SSH) is connected on interface FastEthernet0/1. So the traffic is certainly passing through the router. And you would expect debug to report it. But I believe that the traffic is being fast switched. If it is fast switched it does not hit the router CPU and debug can not report on it.

If you really want the debug to see the traffic you can force the router to process switch all the traffic on the interface by entering no ip route-cache command in interface configuration mode. Be aware that this will impact performance of the router.

Perhaps if we understood what you are attempting to accomplish we might suggest some less intrusive way to accomplish it.

HTH

Rick

[r.schwindt]

Hi Rick !

Thanks a lot. This was exactly what we were looking for.

Since this is only for short debugging purposes,

we can re-enable ip route-cache after debugging

without rebooting the router, right ?

Regards,

Ralph

[Richard Burts]

Ralph

Yes you can - and SHOULD - re-enable fast switching when you finish debugging. No reboot needed.

I have an additional thought: the access list you are using will show traffic from the source to the target, but will not show any responses. Depending on what you are investigating, is one way traffic good enough, or do you need to see two way traffic? Right now your access list has a single line which permits ip from any to the specific network. If you want to see two way traffic you should add a second line to the access list which permits ip from the specific network to any.

HTH

Rick

[r.schwindt]

Rick,

thanks a lot again for Your real fast reply !

It's right, we need only monitor the traffic to the destination.

What we want to find out is, who of our users generates lots of traffic to the destinations at daytimes, when users shouldn't do that, e.g.

starting FTP transfers, which are only allowed at nighttimes.

Best regards,

Ralph

[Richard Burts · Accepted solution]

Ralph

I am glad that you have found my answers helpful.

Based on your explanation of what you are trying to accomplish I have a suggestion of an alternative approach. It may give you the information that you need, be more available, and impose less burden on the router.

My suggestion is to construct an access list using the log option. If you were to configure an access list that looks something like this:

access-list 101 permit ip any 192.168.55.0 0.0.0.255 log

access-list 101 permit ip any any

and if you were to apply this access inbound on interface FastEthernet0/0 it would let all of the traffic go through and it would create log entries for any traffic originated in the subnet of FastEthernet0/0 and destination in 192.168.55.0 (the same traffic you are now seeing in debug). You could see those log records in the logging buffer (assuming that logging buffered continues to be enabled) and if you enabled logging to a syslog server you would be able to see the log records there.

Processing the access list would be less work for the router than running debug. It would not require disabling fast switching, and it would run all the time so you would not have to worry about starting debug.

The access list as I gave it would provide only source and destination addresses. If you also want it to provide port numbers so that you can see what applications people are running then use somthing like this:

access-list 101 permit tcp any range 0 65535 192.168.55.0 0.0.0.255 range 0 65535 log

access-list 101 permit udp any range 0 65535 192.168.55.0 0.0.0.255 range 0 65535 log

access-list 101 permit ip any 192.168.55.0 0.0.0.255 log

access-list 101 permit ip any any

HTH

Rick

[r.schwindt]

Rick,

that hits the old spot.

Very good approach, we'll do that with

a syslog server.

thx again

Ralph