Procedure https://cll-ng.cisco.

com/content/xtrac/2

Discovery 23: Troubleshoot Connectivity and Analyze Traffic with Ping, Traceroute, and Debug
Task 1: Troubleshoot with PING
Activity
Using the Ping Command

The ping command is a very common method for troubleshooting the accessibility of devices. It uses a series of Internet Control Message Protocol (ICMP) Echo messages to determine:

whether a remote host is active or inactive.

the round-trip delay in communicating with the host.
packet loss.

The ping command first sends an echo request packet to an address, then waits for a reply. The ping is successful only if:

the echo request gets to the destination.

the destination is able to get an echo reply to the source within a predetermined time called a timeout. The default value of this timeout is two seconds on Cisco routers.

The possible responses when conducting a ping test include:

Character Description
! Each exclamation point indicates receipt of a reply.
. Each period indicates the network server timed out while waiting for a reply.
U A destination unreachable error PDU was received.
Q Source quench (destination too busy).
M Could not fragment.
? Unknown packet type.
& Packet lifetime exceeded.
Note
When pinging, processing delays can be significant, because the router considers that responding to a ping is a low-priority task.
Step 1: From PC1, ping its local host address of 10.10.10.1.
Ping PC1’s local address:
PC1# ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms
PC1#
If the ping to the local host address is successful, your NIC is functioning. If it fails, there is a problem with the NIC. If the ping is successful, it does not mean that a cable is plugged into the NIC, but only that the IP protocol stack on the host can communicate to the NIC
(via the LAN driver).
Note
Even before you ping a PC’s local host address, you may want to ping its loopback address, any address in the 127.0.0.0 network--for example, 127.0.0.1. This address is the diagnostic or loopback address. If you get a successful ping, your IP stack is considered to be
initialized. If it fails, you have an IP stack failure, and you need to reinstall TCP/IP on the host. The loopback addresses of the 127.0.0.0 network are not accessible on some IOS routers, even those acting as PCs as they are in this lab.
Step 2: From PC1, ping its default gateway, R1, 10.10.10.2.
Ping PC1’s default gateway:
PC1# ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/201/1003 ms
PC1#
If the ping succeeds, it means that the NIC is plugged into the network and can communicate on the local network. If it fails, you have a local physical network problem that could be anywhere from the NIC to the router.
Step 3: From PC1 test end-to-end connectivity by pinging PC2, 10.10.50.2.
PC1# ping 10.10.50.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.50.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
PC1 does not have Layer 3 connectivity to PC2.
Usually, you will not have the luxury to test connectivity from an end user's device, or even if you do, testing from the end user's device is not really convenient. Another way to test if the end-user device has connectivity is to ping from the end-user device’s first hop device
and specify the LAN interface of the end-user device as the source interface for ping operation.
Note
By default, the source IP address in the IP header is the IP address of the outgoing interface.
Step 4: This time, from R1 privileged EXEC mode, ping PC2, 10.10.50.2, sourcing the ping from R1’s LAN interface where PC1 resides.
R1> enable
R1# ping 10.10.50.2 source ethernet 0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.50.2, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.2
.....
Success rate is 0 percent (0/5)
Similarly to when you performed a ping from PC1, the network on which PC1 resides does not have Layer 3 connectivity to PC2.
Step 5: From R1, ping PC2, 10.10.50.2.
R1# ping 10.10.50.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.50.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Why is the ping from PC1’s default gateway, R1, to PC2 successful, yet the ping from PC1 to PC2 is not?
The source address of the ping from PC1 is 10.10.10.1/24. The source address of the ping from the router (without changing the source) is the interface from which the packets leave, 10.10.20.1/24. Therefore, PC2 or the routers along the path to PC1 have a route back to
R1’s network, 10.10.20.0/24, but do not have a route back to PC1’s network, 10.10.10.0/24.

Task 2: Troubleshoot with Traceroute

Activity
Using Traceroute
The traceroute tool is very useful if you want to determine the specific path that a frame takes to its destination. If there is an unreachable destination, you can determine where on the path the issue lies.

Traceroute works by sending the remote host a sequence of three UDP datagrams with a TTL of 1 in the IP header and the destination ports 33434 (first packet), 33435 (second packet), and 33436 (third packet). The TTL of 1 causes the datagram to "timeout" when it hits
the first router in the path. The router responds with an ICMP "time exceeded" message, meaning the datagram has expired.
The next three UDP datagrams are sent with TTL of 2 to destination ports 33437, 33438 and 33439.
After passing through the first router which decrements the TTL to 1, the datagram arrives at the ingress interface of the second router. The second router drops the TTL to 0 and responds with an ICMP "time exceeded" message.
This process continues until the packet reaches the final destination and the ICMP "time exceeded," messages are sent by all the routers along the path.
When the packet reaches the final destination, the device responds with an ICMP "port unreachable."

The possible responses when conducting a traceroute include:

Character Description
nn msec For each node, the round-trip time in milliseconds for the specified number of probes
* The probe timed out
A Administratively prohibited (example, access-list)
Q Source quench (destination too busy)
I User interrupted test
U Port unreachable
H Host unreachable

1 din 4 27.05.2020, 09:26

Procedure https://cll-ng.cisco.com/content/xtrac/2

Character Description
N Network unreachable
P Protocol unreachable
T Timeout
? Unknown packet type
Step 1: From PC2, perform a traceroute to its default gateway, R4, 10.10.50.1.
Perform a trace to PC2’s default gateway:
PC2# traceroute 10.10.50.1
Type escape sequence to abort.
Tracing the route to 10.10.50.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.50.1 1 msec * 1 msec
PC2#
PC2 is able to reach its first hop, its default gateway, R4.
Step 2: From PC2, perform a traceroute to R1’s E0/1 interface, 10.10.20.1.
Perform a trace to R1’s E0/1 interface:
PC2# traceroute 10.10.20.1
Type escape sequence to abort.
Tracing the route to 10.10.20.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.50.1 1 msec 0 msec 1 msec
2 10.10.40.1 0 msec 0 msec 1 msec
3 10.10.30.1 1 msec 0 msec 1 msec
4 10.10.20.1 1 msec * 2 msec
PC2#

PC2 is able to reach R1’s E0/1 interface through the routers of:

10.10.50.1, R4
10.10.40.1, R3
10.10.30.1, R2

Step 3: From PC2, perform a traceroute to PC1, 10.10.10.1.

Perform a trace to PC1:
PC2# traceroute 10.10.10.1
Type escape sequence to abort.
Tracing the route to 10.10.10.1
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
4 * * *
--- output omitted ---
No routers along the path are being displayed, indicating that even PC2’s default gateway, R4, does not have a route to PC1’s network of 10.10.10.0/24.
Note
To interrupt the traceroute command operation, use Ctrl-Shift-6 combination and then press the X button on your keyboard.
Step 4: On R4, verify that it does not have the PC1 network in its routing table by issuing the show ip route command.
Verify R4’s routing table:
R4# show ip route 10.10.10.1
% Subnet not in table
Step 5: To fix the issue, on R1, configure OSPF to advertise the 10.10.10.0/24 network.
On R1, advertise the 10.10.10.0/24 network:
R1(config)# router ospf 1
R1(config-router)# network 10.10.10.0 0.0.0.255 area 0
You can issue show ip protocols on R1 to verify that R1 is now advertising the network, and show ip route on R4 to verify that R4 has learned about the 10.10.10.0/24 subnet.
Step 6: Perform another traceroute from PC2 to PC1, 10.10.10.1.
PC2# traceroute 10.10.10.1
Type escape sequence to abort.
Tracing the route to 10.10.10.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.50.1 1002 msec 1 msec 0 msec
2 10.10.40.1 0 msec 1 msec 1 msec
3 10.10.30.1 1 msec 0 msec 1 msec
4 10.10.20.1 1 msec 0 msec 1 msec
5 10.10.10.1 0 msec * 1 msec
PC2#

End to end connectivity between PC2 and PC1 now works through the routers of:

10.10.50.1, R4
10.10.40.1, R3
10.10.30.1, R2
10.10.20.1, R1

The Extended Ping

The extended ping is used to perform a more advanced check of host reachability and network connectivity. The options in an extended ping include the following:

Field Description
Protocol [ip]: Prompts for a supported protocol. Enter appletalk, CLNS, ip, novell, apollo, vines, decnet, or XNS. The default is ip.
Target IP address: Prompts for the IP address or host name of the destination node you plan to ping. If you have specified a supported protocol other than IP, enter an appropriate address for that protocol here. The default is none.
Repeat count [5]: Number of ping packets that are sent to the destination address. The default is 5.
Datagram size [100]: Size of the ping packet (in bytes). Default: 100 bytes.
Timeout in seconds [2]: Timeout interval. Default: 2 (seconds). The ping is declared successful only if the ECHO REPLY packet is received before this time interval.
Extended commands [n]: Specifies whether a series of additional commands appears. The default is no.
Source address or The interface or IP address of the router to use as a source address for the probes. The router normally picks the IP address of the outbound interface to use. The interface can also be mentioned, but with the correct syntax as shown here:
interface:
Source address or interface: Ethernet 0

Note: This is a partial output of the extended ping command. The interface cannot be written as e0.
Type of service [0]: Specifies the Type of Service (ToS). The requested ToS is placed in each probe, but there is no guarantee that all routers process the ToS. It is the Internet service's quality selection. The default is 0.
Set DF bit in IP header? Specifies whether the Don't Fragment (DF) bit is to be set on the ping packet. If yes is specified, the Don't Fragment option does not allow this packet to be fragmented when it has to go through a segment with a smaller maximum transmission
[no]: unit (MTU), and you will receive an error message from the device that wanted to fragment the packet. This is useful for determining the smallest MTU in the path to a destination. The default is no.
Validate reply data? [no]: Specifies whether to validate the reply data. The default is no.
Data pattern [0xABCD] Specifies the data pattern. Different data patterns are used to troubleshoot framing errors and clocking problems on serial lines. The default is [0xABCD].
Loose, Strict, Record, IP header options. This prompt offers more than one option to be selected. They are:
Timestamp, Verbose[none]:
Verbose is automatically selected along with any other option.

Record is a very useful option because it displays the address(es) of the hops (up to nine) the packet goes through.

Loose allows you to influence the path by specifying the address(es) of the hop(s) you want the packet to go through.

Strict is used to specify the hop(s) that you want the packet to go through, but no other hop(s) are allowed to be visited.

Timestamp is used to measure round-trip time to particular hosts.

The difference between using the Record option of this command and using the traceroute command is that, the Record option of this command not only informs you of the hops that the echo request (ping) went through to get to the destination,
but it also informs you of the hops it visited on the return path. With the traceroute command, you do not get information about the path that the echo reply takes. The traceroute command issues prompt for the required fields. Note that the
traceroute command places the requested options in each probe. However, there is no guarantee that all routers (or end nodes) process the options. The default is none.
Sweep range of sizes [n]: Allows you to vary the sizes of the echo packets that are sent. This is used to determine the minimum sizes of the MTUs configured on the nodes along the path to the destination address. Performance problems caused by packet fragmentation are
thus reduced. The default is no.
!!!!! Each exclamation point (!) denotes receipt of a reply. A period (.) denotes that the network server timed out while waiting for a reply. Refer to ping characters for a description of the remaining characters.
Success rate is 100 percent Percentage of packets successfully echoed back to the router. Anything less than 80 percent is usually considered problematic.
round-trip min/avg/max = Round-trip travel time intervals for the protocol echo packets, including minimum/average/maximum (in milliseconds).
1/2/4 ms
Note

2 din 4 27.05.2020, 09:26

Procedure https://cll-ng.cisco.com/content/xtrac/2

The extended ping command works only at the privileged EXEC command line.

Task 3: Use an Extended Ping to Test MTU Size

Activity
You may want to avoid fragmentation of IPv4 packets in your network because it can cause high CPU spikes on the router, increasing the overhead by adding the IP header to each data chunk. For example, if a packet is fragmented into multiple data chunks, and if only one
of those data chunks is lost on its way to the destination, then TCP must resend the whole packet. Furthermore, some applications require a specific MTU size to function properly.
One way to determine the maximum MTU size across the network is to perform an extended ping, setting the packet size, and notifying the routers along the path not to fragment the packets.
Step 1: From R1, issue the ping command to PC2 with the df-bit set and a datagram size of 1476 bytes.
R1# ping 10.10.50.2 size 1476 df-bit
Type escape sequence to abort.
Sending 5, 1476-byte ICMP Echos to 10.10.50.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Since the ping succeeds, all routers along the path must have an MTU size of at least 1476.bytes.
Step 2: From R1, issue the ping command to PC2 with the df-bit set and a datagram size of 1477 bytes.
R1# ping 10.10.50.2 size 1477 df-bit
Type escape sequence to abort.
Sending 5, 1477-byte ICMP Echos to 10.10.50.2, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)
The result code of "M" means that a router along the path could not fragment the packet and dropped it. Since the ping with the df-bit set and a datagram size of 1476 bytes succeeded, but failed at 1477 bytes, the maximum MTU along the path is 1476 bytes.
Note
Sometimes this issue may be caused by the use of GRE tunnels as they have an overhead of 24 bytes.
Manually performing a ping, increasing the datagram size by one each time, could potentially take a long time to determine the maximum MTU size along the network path. A more efficient way is to perform an interactive extended ping with a sweep of packet sizes.
Step 3: Perform an interactive extended ping from R1 to PC2 with the df-bit set and sweeping packets between 1400 bytes and 1500 bytes.
R1# ping
Protocol [ip]:
Target IP address: 10.10.50.2
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]: 1
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1400
Sweep max size [18024]: 1500
Sweep interval [1]:
Type escape sequence to abort.
Sending 101, [1400..1500]-byte ICMP Echos to 10.10.50.2, timeout is 1 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!M.M.M.M.M.M.M.M.M.M.M.M.
Success rate is 76 percent (77/101), round-trip min/avg/max = 1/1/1 ms
The ping succeeds with a datagram size from 1400-1476 bytes and the df-bit set; for the rest of the sweep, the result is that the packets cannot be fragmented.
This outcome can be determined because the sweep started at 1400 bytes, 100 packets were sent, and there was a 76 percent success rate; 1400 + 76 = 1476.
For testing, you can sweep packets at different sizes (minimum, maximum), set the sweeping interval, and determine the MTU by seeing which packets are passing through the links and which packets need to be fragmented since you already have set df-bit for all the
packets.
Using Debug
The output from debug commands provides diagnostic information that includes various internetworking events relating to protocol status and network activity in general.
Use debug commands with caution. In general, it is recommended that these commands only be used when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internetworks are experiencing high load conditions. Hence, if logging
is enabled, the device can intermittently freeze when the console port gets overloaded with log messages.
Before you start a debug command, always consider the output that the debug command will generate and the amount of time this can take. Before debugging, you may want to look at your CPU load with the show processes cpu command. Verify that you have ample CPU
available before you begin the debugs.

Cisco devices can display debug outputs on various interfaces or be configured to capture the debug messages in a log:

Console: By default, logging is enabled on the console port. Hence, the console port always processes debug output even if you are actually using some other port or method (such as aux, vty, or buffer) to capture the output.
Excessive debugs to the console port of a router can cause it to hang. You should consider changing where the debug messages are captured and turn off logging to the console with the no logging console command.
Some debug commands are very verbose and therefore, you cannot easily view any subsequent commands you wish to type while the debug is in process. To remedy the situation, configure logging synchronous on the console line.
AUX and VTY Ports: To receive debug messages when connected to the AUX port or remotely logged into the device via TELNET or SSH through the VTY lines, type the command terminal monitor.
Logs: Like any syslog message, debug messages can also collected in logs. You can use the logging command to configure messages to be captured in an internal device buffer or external syslog server.

The debug ip packet command helps you to better understand the IP packet forwarding process, however, this command only produces information on packets that are process-switched by the router. Packets generated by a router or destined for a router are process-switched,
and are therefore displayed with the debug ip packet command.
Packets that are forwarded through a router that is configured for fast-switching or CEF are not provided to the processor, and hence the debugging does not show anything. To display packets forwarded through a router with the debug ip packet command, you need to
disable fast-switching on the router with the no ip route-cache command (for unicast packets) or no ip mroute-cache (for multicast packets). This command is configured on the interfaces where the traffic is supposed to flow. You can verify whether fast switching is
enabled with the show ip interface command.
Note
Disabling fast-switching on a router that handles many packets can cause CPU utilization to spike so that the box hangs or loses its connection to its peers.
Note
Do not disable fast-switching on a router running Multiprotocol Label Switching (MPLS). MPLS is used along with CEF. Therefore, disabling fast-switching on the interface can have disastrous effect.

Task 4: Use Debug to Analyze Traffic

Activity
Step 1: On R3, use the debug ip packet command to display all packets inbound and outbound on every interface from every neighbor router.
Note
The debug ip packet command is CPU intensive and can potentially adversely affect a network. As this is a lab environment, there will not be a problem, but it is not recommended to use the debug ip packet command in a production environment unless you have first
set up conditions that limit the information to be displayed.
On R3 issue the following command:
R3# debug ip packet
You will begin to see debug messages; debug messages default to the console line.
Step 2: Verify which debug commands are enabled with the show debug command.
On R3 issue the following command:
R3# show debug
Generic IP:
IP packet debugging is on
Note
The debug ip packet output is verbose, so the output of the show debug command will scroll somewhat quickly.
Step 3: After 45 seconds, turn off the specific debug on R3 with the no debug ip packet command.
On R3 issue the following command:
R3# no debug ip packet
IP packet debugging is off
Step 4: Scroll upwards to analyze the debug output and note the source addresses of the debug messages that were captured and displayed.
The messages that are being displayed in this example are OSPF hello messages being exchanged between R3 and its OSPF neighbors. OSPF hello messages are multicast to the 224.0.0.5 address every 5 seconds. You should notice messages to and from each neighbor.
R3 sending hello to R2:
*Jun 17 22:55:26.471: IP: s=10.10.30.2 (local), d=224.0.0.5 (Ethernet0/0), len 80, sending broad/multicast
*Jun 17 22:55:26.471: IP: s=10.10.30.2 (local), d=224.0.0.5 (Ethernet0/0), len 80, sending full packet
R3 sending hello to R4:
*Jun 17 22:55:27.788: IP: s=10.10.40.1 (local), d=224.0.0.5 (Ethernet0/2), len 80, sending broad/multicast

3 din 4 27.05.2020, 09:26

Procedure https://cll-ng.cisco.com/content/xtrac/2

*Jun 17 22:55:27.788: IP: s=10.10.40.1 (local), d=224.0.0.5 (Ethernet0/2), len 80, sending full packet
R3 receiving hello from R2:
*Jun 17 22:55:28.321: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0
*Jun 17 22:55:28.321: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
R3 receiving hello from R4:
*Jun 17 22:55:28.371: IP: s=10.10.40.2 (Ethernet0/2), d=224.0.0.5, len 80, rcvd 0
*Jun 17 22:55:28.372: IP: s=10.10.40.2 (Ethernet0/2), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
R3 sending hello to R5:
*Jun 17 22:55:30.488: IP: s=10.10.80.2 (local), d=224.0.0.5 (Ethernet0/1), len 80, sending broad/multicast
*Jun 17 22:55:30.488: IP: s=10.10.80.2 (local), d=224.0.0.5 (Ethernet0/1), len 80, sending full packet
R3 receiving hello from R5:
*Jun 17 22:55:35.425: IP: s=10.10.80.1 (Ethernet0/1), d=224.0.0.5, len 80, rcvd 0
*Jun 17 22:55:35.425: IP: s=10.10.80.1 (Ethernet0/1), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
One way of narrowing down the output of a debug command is to create an access list that defines the traffic you would like to display. Then you will reference that access list in the debug command.
Step 5: On R3, create an access list 10 that defines only traffic from the source address of R2’s E0/1 interface, 10.10.30.1/24.
On R3 issue the following command:
R3(config)# access-list 10 permit 10.10.30.1
Step 6: On R3, use the debug ip packet command to display all packets that match the criteria defined in the access-list 10.
On R3 issue the following command:
R3# debug ip packet 10
You will begin to see debug messages; debug messages default to the console line.
Step 7: After 45 seconds, turn off all debugs that may be enabled with the no debug all command.
On R3 issue the following command:
R3# no debug all
All possible debugging has been turned off
Step 8: Analyze the debug output and note the source address of the debug messages that were captured and displayed.
*Jun 18 00:05:49.338: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0
*Jun 18 00:05:49.338: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
R3#
*Jun 18 00:05:58.596: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0
*Jun 18 00:05:58.596: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
The only debug messages displayed are those defined in the access-list 10, those messages with a source address of R2, 10.10.30.1.
The Conditional Debug
Another way of narrowing down the output of a debug command is to use the conditional debug. If any debug condition commands are enabled, output is generated only for packets that contain information specified in the configured condition.
The options available with a conditional debug include:

called dial-string Filters output on the basis of the called party number.
caller dial-string Filters output on the basis of the calling party number.
calling tidi/imsi-string Filters debug messages for General Packet Radio Service (GPRS) tunneling protocol (GTP) processing on the Gateway GPRS Support Node (GGSN) based on the tunnel identifier (TID) or international mobile system identifier (IMSI) in a
Packet Data Protocol (PDP) Context Create Request message.
domain domain-name Filters output on the basis of the specified domain.
interface interface-id Filters output on the basis of the specified interface ID.
ip ip-address Filters output on the basis of the specified IP address.
mac-address hexadecimal-mac- Filters messages on the specified MAC address.
address
portbundleip ip-address Filters output on the basis of the port-bundle host key (PBHK) that uniquely identifies the session.
bundle bundle-number Specifies the port bundle.
session-id session-number Filters output on the specified Intelligent Service Architecture (ISA) session identifier.
username username Filters output on the basis of the specified username.
vcid vc-id Filters output on the basis of the specified VC ID.
vlan vlan-id Filters output on the basis of the specified VLAN ID.
condition-id ID number of the condition to be removed.
all Removes all debugging conditions, and conditions specified by the debugcondition interface command. Use this keyword to disable conditional debugging and re-enable debugging for all interfaces.
Note
If multiple debug condition commands are enabled, output is displayed if at least one condition matches. All the conditions do not need to match.

Task 5: Use a Conditional Debug to Filter Output

Activity
In this task, you will use a conditional debug to filter output on the basis of a specified interface.
Step 1: Create a conditional debug that will only display debug messages for traffic on of R3’s E0/0 interface.
On R3 issue the following command:
R3# debug condition interface e0/0
Condition 1 set
Step 2: Verify which conditional debugs have been configured with the show debug condition command.
On R3 issue the following command:
R3# show debug condition
Condition 1: interface Et0/0 (1 flags triggered)
Flags: Et0/0
Step 3: On R3, type the debug ip packet command.
On R3 issue the following command:
R3# debug ip packet
You will begin to see debug messages; debug messages default to the console line.
Step 4: After 45 seconds, turn off all debugs that may be enabled with the no debug all command.
On R3 issue the following command:
R3# no debug all
All possible debugging has been turned off
Step 5: Analyze the debug output and note the interface of the debug messages that were captured and displayed.
*Jun 18 00:29:42.055: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0
*Jun 18 00:29:42.055: IP: s=10.10.30.1 (Ethernet0/0), d=224.0.0.5, len 80, input feature, packet consumed, MCI Check(82), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
R3#
*Jun 18 00:29:43.280: IP: s=10.10.30.2 (local), d=224.0.0.5 (Ethernet0/0), len 80, sending broad/multicast
*Jun 18 00:29:43.280: IP: s=10.10.30.2 (local), d=224.0.0.5 (Ethernet0/0), len 80, sending full packet
The only debug messages displayed are those defined in the conditional debug, those messages coming in and going out R3’s E0/0 interface.

© 2020 Cisco Systems, Inc.

4 din 4 27.05.2020, 09:26