in terms of CPU consumption and possible traffic disruption, what should I generally expect when I run the command:

Switch#debug ip packet

on a Cisco device in a large ISP network?

Cisco devices in question:

  • Catalyst 3750 Series
  • Catalyst 6500 Series
  • Catalyst 4500 series
  • Cisco 7600 Series Routers

These device are usually processing no less than 8 Gbps of traffic.


The platforms you mention are all hardware forwarding devices. What debug ip packet does is to show packets going to / from the switch's CPU (either punted, locally-sourced, or control-plane).

You should only see control plane packets here or packets being punted due to a feature being misconfigured or not supported.

People sometimes turn off CEF to debug but this is not recommended and not even supported on some of the platforms such as 3750.

The impact depends on how much traffic you have going to the CPU but it's a risky command to run.

Why do you want to run it? What are you looking for? Have you considered using other methods such as Netflow, SPAN, ERSPAN?

If you really want to debug then log to a buffer, turn off terminal monitoring and combine debug ip packet with an ACL to define which traffic you are interested in. Do so at your own risk though.

  • I'm trying to use this command to see the destination I.P address of traffic going out a certain interface. What other methods should I use? – user5029 Apr 1 '14 at 10:52
  • 3
    @Faisal, for the platforms in your question, connect a sniffer to the switch and use SPAN – Mike Pennington Apr 1 '14 at 10:56

When Cisco says "these commands may adversely affect device performance", they aren't kidding.

On the types of devices with the traffic load you describe, this command will likely result in 100% CPU consumption, halting of device functionality and major disruption of your network.

Don't do it.


Had to do this troubleshooting just a few days ago on a 6500 that is in a remote part of the country. To drive there would have taken 3 days...

To do it safely without further issues and crashing the router: 1. create an access list that specifies what you want to troubleshoot (i.e icmp) conf t access-list 101 permit icmp host a.b.c.d any exit 2. in exec mode debug ip packet 101 detail

Don't forget to check your router sh ip access-list 101 sh proc cpu history sh proc cpu sorted 1m

More information on this page 388 out of the "Troubleshooting IP Routing Protocols" book: http://books.google.com.au/books?id=acUH-XvDFKMC&pg=PA388&lpg=PA388&dq=debug+ip+packet+101&source=bl&ots=9wwu2yf0Bv&sig=yDpMcEcTgkszQD5GuxGCtQDDD-s&hl=en&sa=X&ei=ymE8U-LVMJHMlAWC8YG4CA&ved=0CG8Q6AEwCQ#v=onepage&q=debug%20ip%20packet%20101&f=false


Use the debug ip packet command to monitor packets that are processed by the routers routing engine and are not fast switched.

This command generates an output for every single packet, therefore it should be used with great caution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy