The debug command is a great troubleshooting or learning tool because it provides invaluable, real-time information about network conditions. However, before we go any further, use the debug commands with caution. Enabling debugging can disrupt the operation of the device and the connection can freeze as soon as the console is overloaded with log messages. By default, logging on the console is enabled. Hence, the console port always processes debug output even if some other port or method (such as aux, vty or buffer) to capture the output is used and the device automatically prioritizes console output ahead of other functions. Because of this, it is recommended that, under normal operating conditions, the no logging console command is enabled at all times. To log messages to an internal buffer instead of the console, use the logging buffered command.
Back to business... The debug command has so many options, see here. We'll focus on the debug ip packet command in this post. The debug ip packet command displays general IP debugging information. The debug ip packet command is useful for analyzing the messages sent between the local and remote hosts. Note: The IP packet debugging captures only packets that are process switched, so fast switching and CEF switching must be disabled. Again, the debug ip packet command can generate a substantial amount of output and consume a big chunk of system resources, so use it with caution in production networks. Example:
Router#debug ip packet
IP packet debugging is on
Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
The output is rather self-explanatory but, briefly, IP indicates an IP packet, s=12.0.0.1 (Serial0) indicates the source address of the packet and the name of the interface that received the packet, d=34.0.0.4 (Serial0) indicates the destination address of the packet and the name of the interface through which the packet is being sent out on the network, len 100 indicates the size of the packet, and sending/rcvd indicates whether the packet is sent or received.
The debug ip packet command can accept an access-list to narrow down the command output and display only information that matches specific parameters. If the packet is not permitted by the access-list, the related debugging output is suppressed. Both standard and extended range access-lists can be used. For example, if you want to see only the received packets from the previous example, you would apply the following access-list.
Router(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router#debug ip packet 150
IP packet debugging is on for access list 150
Jan 20 16:55:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
The debug ip packet command also has a detail option, which displays detailed IP packet debugging information. This information includes the packet types and codes as well as source and destination port numbers. Example:
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
!--- ICMP Time Exceeded messages from Router 2.
Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.615: UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.639: ICMP type=11, code=0
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.647: UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.671: ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.679: UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.703: ICMP type=11, code=0
!--- ICMP Time Exceeded messages from Router 3.
Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.711: UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.747: ICMP type=11, code=0
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.755: UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.791: ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.799: UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.831: ICMP type=11, code=0
!--- Port Unreachable messages from Router 4.
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:48.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.947: ICMP type=3, code=3
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Here is the network topology diagram to help decode the above debug output.
If you remember from yesterday's post, the traceroute command sends three probes at each TTL level, which is why you see three "packet pairs" for each hop. Let's look at the first exchange between Router 1 and Router 2 in more detail. The section highlighted in blue indicates that Router 1 (s=12.0.0.1) sent a packet to Router 4 (d=34.0.0.4) from UDP source port 39911 to UDP destination port 33434. The section highlighted in red indicates that Router 2 (s=12.0.0.2) sent an ICMP Time Exceeded message (ICMP type=11, code=0) to Router 1 (d=12.0.0.1). This is due to the first probes being sent with a TTL=1 so they expire at Router 2.
The IP debugging can be stopped using the no debug ip packet command. The no debug all or undebug all (u all for short) commands would disable all debugging.
This is the final post in the Cisco Command Christmas Calendar series. Thank you for reading! Happy Holidays to 'u all'!
Back to business... The debug command has so many options, see here. We'll focus on the debug ip packet command in this post. The debug ip packet command displays general IP debugging information. The debug ip packet command is useful for analyzing the messages sent between the local and remote hosts. Note: The IP packet debugging captures only packets that are process switched, so fast switching and CEF switching must be disabled. Again, the debug ip packet command can generate a substantial amount of output and consume a big chunk of system resources, so use it with caution in production networks. Example:
Router#debug ip packet
IP packet debugging is on
Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
sending
The output is rather self-explanatory but, briefly, IP indicates an IP packet, s=12.0.0.1 (Serial0) indicates the source address of the packet and the name of the interface that received the packet, d=34.0.0.4 (Serial0) indicates the destination address of the packet and the name of the interface through which the packet is being sent out on the network, len 100 indicates the size of the packet, and sending/rcvd indicates whether the packet is sent or received.
The debug ip packet command can accept an access-list to narrow down the command output and display only information that matches specific parameters. If the packet is not permitted by the access-list, the related debugging output is suppressed. Both standard and extended range access-lists can be used. For example, if you want to see only the received packets from the previous example, you would apply the following access-list.
Router(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router#debug ip packet 150
IP packet debugging is on for access list 150
Jan 20 16:55:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
Jan 20 16:55:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
rcvd 3
The debug ip packet command also has a detail option, which displays detailed IP packet debugging information. This information includes the packet types and codes as well as source and destination port numbers. Example:
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
!--- ICMP Time Exceeded messages from Router 2.
Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.615: UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.639: ICMP type=11, code=0
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.647: UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.671: ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.679: UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.703: ICMP type=11, code=0
!--- ICMP Time Exceeded messages from Router 3.
Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.711: UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.747: ICMP type=11, code=0
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.755: UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.791: ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.799: UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.831: ICMP type=11, code=0
!--- Port Unreachable messages from Router 4.
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:48.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.947: ICMP type=3, code=3
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Here is the network topology diagram to help decode the above debug output.
If you remember from yesterday's post, the traceroute command sends three probes at each TTL level, which is why you see three "packet pairs" for each hop. Let's look at the first exchange between Router 1 and Router 2 in more detail. The section highlighted in blue indicates that Router 1 (s=12.0.0.1) sent a packet to Router 4 (d=34.0.0.4) from UDP source port 39911 to UDP destination port 33434. The section highlighted in red indicates that Router 2 (s=12.0.0.2) sent an ICMP Time Exceeded message (ICMP type=11, code=0) to Router 1 (d=12.0.0.1). This is due to the first probes being sent with a TTL=1 so they expire at Router 2.
The IP debugging can be stopped using the no debug ip packet command. The no debug all or undebug all (u all for short) commands would disable all debugging.
This is the final post in the Cisco Command Christmas Calendar series. Thank you for reading! Happy Holidays to 'u all'!
Cisco documentation: debug ip packet and Understanding the ping and traceroute Commands
Comments
Post a Comment