How to debug on a router?

[dan_track]

Hi

I have 3640 cisco router. I'm getting some weird traffic problesm to certain servers, where momentarily I lose connection. When running traceroute I see the last path is the router.

What I'd like to do is monitor the packets going through the router to a particualr server. How can I do this on the router using cisco commands?

Thanks

Dan

[spremkumar]

Hi

There are lots of possiblities involved here for the disconnects.

Few things i would suggest here is to check the switch ports where both the router and the servers are connected.

Check the cpu of the switch which interfaces both the router and the servers.

also make sure that the speed and duplex settings are hardcoded(std config full duplex , 100Mbps)

if you are running any monitoring softwares like MRTG you can check the traffic rate on both router and the switch during disconnection period.

you can also enable netflow and check the traffic pattern in your network which will help you to identify whether you need to patch ur devices for the worms/viruses.

regds

[dan_track]

Hi

Thanks for the reply. Basically I'm having network problesm when changing the pix firewall rules. Although they shouldn't affect any of the network they apparently are, but only to some servers, which is peculiar as those servers are on the same subnet as other servers that are fine.

I'd like to see what happens on the router if possible, is there something like packet logging?

Thanks

Dan

[stephtchoko · Accepted solution]

Good day,

I 'll give you an example

If the ip address of this servers is

:10.1.1.1, 10.1.1.2., 10.1.1.3

you can try this configuration:

1-

access-list 101 permit ip host 10.1.1.1 any

access-list 101 permit ip host 10.1.1.2 any

access-list 101 permit ip host 10.1.1.3 any

2-

debug ip packet 101

Please try this configuration and send us feedback about the log message (if you are in telet mode, please don't forget to use "terminal monitor" )

Your router 'll tell you where packet comme from 10.1.1.1, 10.1.1.2 and 10.1.1.3 are sent.

Don't forget to rate this post.

Regards.

[Richard Burts · Accepted solution]

If you do not have the ability to do packet captures with a Sniffer (or something equivalent) then debug ip packet is the alternative to consider.

Many of us have learned to be cautious about running debug on production routers because of their potential impact. As Stephane points out there are some things we can do to minimize the impact of running debug like configuring access lists and limiting the debug output with the access list. (as a side note, the access list suggested will report traffic from the servers. if you also want to see traffic to the servers add these lines to the access list:

access-list 101 permit ip any host 10.1.1.1

access-list 101 permit ip any host 10.1.1.2

access-list 101 permit ip any host 10.1.1.3)

Another suggestion to limit the impact of debug is to make sure that logging to the console does not include debug messages. By default logging to the console does include debug, so you may want to configure logging console information.

Another point is that packets that are fast switched (or cef switched) will not be reported by debug. debug can only report what the processor sees. So you may want to configure no ip route-cache on the interface where the servers are connected. This will also impact performance of the router. And you want to be sure to restore whatever switching method was originally configured when you finish with debug.

HTH

Rick

[dan_track]

Hi

Thanks for the reply. It was helpful.

Could you please elaborate on what are the potential pitfalls with adding debug? If there are pitfalls then why did cisco include debug commands?

Thanks again

Dan

[stephtchoko]

Hi Dan,

You forget to rate the differents post.

Regards.

[Richard Burts]

Dan

The pitfalls of running debug are that debug can be very processor intensive - depending on what you are debugging. If you debug too much it can bog down the router and impact its performance. If the router processor gets too busy processing debug activity it can get to a situation where it does not have enough resources to process normal data packets, or routing updates. There have been situations where people turned on a very active debug and the router got so busy processing debug that it was difficult to get the commands in to turn off debug. In extreme cases people who have started over-active debug have power cycled the router to stop debug and restore normal functioning (it happened to me once).

Your question about why Cisco included debug if there are pitfalls is sort of interesting. My answer is that debug is a very powerful tool and sometimes when there are problems debug is the very best (and sometimes the only) way to find the problem. But powerful tools can be dangerous when they are used but not carefully. I suggest an analogy with XRAY. For certain medical conditions an XRAY is a necessary and beneficial diagnostic tool. But if done too much or done carelessly the XRAY is damaging. If you use debug carefully and correctly it can do very good things for you. But if you run debug unwisely or carelessly it can do damage. Debug is a good and powerful diagnostic. Use it carefully.

HTH

Rick