VMware ESXi and vSphere Cluster Management
Cisco IOS Extended Ping: Testing Reachability, Source Paths, MTU, and Packet Behavior
Learn how to use Cisco IOS extended ping to select source addresses, test return routes, investigate MTU and DF behavior, inspect loss and latency, and validate packet handling.
What Cisco IOS Extended Ping Tests
Ping uses an ICMP Echo Request and waits for an ICMP Echo Reply. A reply shows that a packet reached the destination and that return traffic came back under the conditions of the test.
Ordinary ping uses mostly default values and specifies the destination on the command line:
Router# ping 10.0.0.2Extended ping is Cisco IOS's interactive ping mode. Start it from privileged EXEC mode by entering ping without a destination:
Router# pingThe dialog lets you change packet and test characteristics, such as the source address, repeat count, datagram size, timeout, service marking, Don't Fragment behavior, and data pattern. Prompt order and available options vary by IOS release, platform, protocol, and IPv4 or IPv6 mode.
Basic Extended-Ping Workflow
- Enter privileged EXEC mode, normally identified by a prompt ending in
#. - Enter
pingwithout a destination. - Select the protocol.
ipis normally the relevant choice for IPv4 troubleshooting. - Enter the destination IP address or a resolvable hostname.
- Accept or change the repeat count, datagram size, and timeout.
- Choose whether to use extended commands.
- If enabled, answer the additional prompts, such as source address, service value, DF behavior, data validation, or packet-size sweep.
- Review the success indicators, success rate, and round-trip-time summary.
Use context-sensitive help and the prompts displayed by the device rather than assuming that every IOS version presents the same questions.
Protocol Selection
IP is the standard selection for modern IPv4-network troubleshooting. Some IOS versions or platforms historically present additional protocol choices. Those legacy choices are platform-dependent and generally do not apply to current IPv4 or IPv6 networks.
Ordinary Ping Versus Interactive Extended Ping
| Capability | Ordinary ping | Interactive extended ping | Diagnostic value |
|---|---|---|---|
| Destination test | Yes, supplied on the command line | Yes, supplied during prompts | Tests basic ICMP reachability |
| Source selection | Usually uses the normal routed source | Can select an interface or IPv4 address | Tests return routing to a particular source subnet |
| Probe count | Uses command defaults or limited syntax | Can change repeat count | Helps reveal intermittent loss |
| Payload size | Uses a default | Can change datagram size | Supports MTU investigation |
| Timeout | Uses a default | Can change the wait time | Useful on slow or high-delay paths |
| DF and MTU testing | Not normally exposed interactively | Available where supported | Tests fragmentation and path-MTU limits |
| QoS marking | Usually uses the default marking | Can expose a Type of Service prompt | Helps verify classification policies |
| Data-pattern testing | Uses ordinary defaults | Can expose pattern and validation controls | Supports specialized link troubleshooting |
Core Ping Parameters
| IOS prompt or parameter | Typical default | What it changes | When to modify it | Operational cautions |
|---|---|---|---|---|
| Protocol | ip | Selects the protocol used by the test | Use IP for normal IPv4 diagnostics | Choices differ by platform and release |
| Target address | None | Destination IP address or resolvable hostname | Test a router interface, host, or service-side address | Name resolution can introduce a separate DNS dependency |
| Repeat count | Often 5, but verify locally | Number of Echo Requests sent | Increase it when investigating intermittent loss | More probes create more traffic and take longer |
| Datagram size | Often 100, but verify locally | Configured test data size presented by IOS | Test fragmentation, MTU limits, or link behavior | Do not confuse the configured size with total on-wire size |
| Timeout | Often 2 seconds, but verify locally | Maximum wait for each reply | Increase it for high-delay paths | A long timeout can make a large test slow to complete |
| Extended commands | Usually no | Exposes advanced prompts | Choose yes for source, DF, QoS, or specialized tests | Prompt wording and options vary |
| Source address or interface | Routing-selected source | Sets the source field of the Echo Request | Test reachability from a particular interface or subnet | The destination must have a return route to that source |
| Type of Service | Platform default | Sets a service-field value where supported | Check QoS classification or policy behavior | Values and wording differ; confirm the platform's interpretation |
| DF bit | Usually disabled | Prevents IPv4 fragmentation when enabled | Find a path-MTU limit | Control messages may be filtered, obscuring the reason for failure |
| Validate reply data | Usually disabled | Checks whether returned data matches sent data | Investigate suspected corruption | Supported behavior is platform-dependent |
| Data pattern | Implementation-specific hexadecimal default | Changes the contents of the test data | Investigate framing, CRC, clocking, or corruption symptoms | Verify the actual default on the device |
| IP header options | Usually none | May request source routing, record route, timestamps, or verbose details | Use only for specialized diagnostics | Options may be unsupported, filtered, deprecated, or unsafe in production |
| Size sweep | Usually disabled | Sends probes over a range of packet sizes | Find where loss or fragmentation-related failure begins | Prompt behavior is IOS- and platform-dependent |
Launching a Baseline Extended Ping
First establish a simple comparison result:
Router# ping 10.0.0.2Then launch the interactive form. The following values are illustrative; actual defaults must be read from the device:
Router# ping
Protocol [ip]: ip
Target IP address: 10.0.0.2
Repeat count [5]: 5
Datagram size [100]: 100
Timeout in seconds [2]: 2
Extended commands [n]: nPress Enter to accept a displayed default. A baseline test normally keeps the default packet size, timeout, source behavior, and non-extended settings. This makes later tests easier to compare.
Selecting a Source Interface or Address
The source address is the IPv4 address placed in the source field of the Echo Request. A source interface is an interface selected to supply that address. The egress interface is the outbound interface chosen by routing for the destination.
By default, IOS generally selects an address associated with the egress interface. This is convenient for ordinary reachability testing, but it may not test every local interface or subnet.
With extended ping, select a source address or, on supported platforms, an interface:
Router# ping
Protocol [ip]: ip
Target IP address: 10.0.0.2
Repeat count [5]: 5
Datagram size [100]: 100
Timeout in seconds [2]: 2
Extended commands [n]: y
Source address or interface: 192.168.5.1Choosing an alternate source turns the test into a routing test in both directions. The local router must have a usable forward route to the destination, and the destination or an upstream router must have a return path to the selected source address. A return path is the route used by replies to travel back to the ping source.
Two-Router Source-Address Example
Consider this topology:
- R2 Fa0/1:
10.0.0.1/24 - R1 Fa0/0:
10.0.0.2/24 - R2 Fa0/0:
192.168.5.1/24 - R1 needs a route to
192.168.5.0/24through R2.
A normal ping from R2 to 10.0.0.2 will likely use 10.0.0.1 as its source because that is the address on the interface toward R1. Now repeat the test while selecting 192.168.5.1 or R2 Fa0/0:
R2# ping
Protocol [ip]: ip
Target IP address: 10.0.0.2
Repeat count [5]: 5
Datagram size [100]: 100
Timeout in seconds [2]: 2
Extended commands [n]: y
Source address or interface: 192.168.5.1If replies arrive, R1 or the routed network beyond it can return traffic toward 192.168.5.0/24. If the default test succeeds but this test times out, inspect the route from R1 toward 192.168.5.0/24. Also check ACLs, NAT, VRF boundaries, interface state, and source-address correctness before concluding that the forward link is broken.
Reading IOS Ping Output
IOS commonly displays one symbol per probe and then summarizes the result. A success symbol such as ! indicates a reply. A timeout symbol such as . indicates that no reply was received before the timeout. An unreachable indicator such as U indicates that an ICMP Unreachable message was received. Exact symbols can vary by protocol and platform.
The success rate compares replies received with probes sent. For example, 80 percent means that four of five probes received replies. The RTT summary reports delay, often as minimum, average, and maximum values. RTT can reveal delay and variation, but ping alone does not prove application performance.
| Observed result | Likely meaning | Initial checks | What the result does not prove |
|---|---|---|---|
| All replies succeed | ICMP reached the destination and replies returned | Check RTT, route, ACLs, and the intended source | Does not validate TCP or UDP ports, DNS, or application health |
| All probes time out | No reply arrived before the timeout | Check source and destination interfaces, routes, ACLs, firewall policy, and ICMP filtering | Does not prove that all IP or application traffic fails |
| Partial success | Loss, congestion, unstable paths, rate limiting, or inconsistent forwarding may exist | Increase repeat count; inspect drops, errors, CPU, QoS, and ECMP paths | Does not identify the failing layer by itself |
| Unreachable response | A device reported that delivery or the route was unavailable | Identify the responding hop and inspect routing and interface state | Does not always identify the original cause of the unreachable condition |
| High or variable RTT | Delay, queuing, congestion, or a slow control plane may be present | Compare repeated runs and inspect utilization and QoS | Does not directly measure application latency |
| Failure only with an alternate source | The selected source's return path or policy is broken | Check the remote route to the source subnet, ACLs, NAT, VRF, and interface state | Does not necessarily indicate a forward-path failure |
| Failure only at larger DF-set sizes | A path MTU limit, tunnel overhead, or blocked fragmentation-needed message may exist | Reduce size, calculate packet overhead, and inspect MTU settings | Does not by itself identify which hop has the lower MTU |
Type of Service, DSCP, and QoS Testing
Type of Service (ToS) is a historical description of service-handling information in the IP header. Modern networks commonly interpret the service field using DSCP, or Differentiated Services Code Point, for QoS marking.
Where IOS supports the relevant prompt, marking an extended-ping packet can help test whether a classifier recognizes the expected value. Inspect policy counters or capture the packet to verify classification. A successful Echo Reply only proves that the packet was returned; it does not prove that every intended QoS action, queue, or priority treatment was applied.
Prompt wording, numeric values, and supported meanings differ across IOS releases. Use the device's displayed options and QoS documentation.
Don't Fragment and Path MTU Testing
The IPv4 Don't Fragment (DF) bit tells a router not to fragment the packet. If a DF-set packet is larger than an interface or path can carry, the packet cannot be fragmented and should fail at the limiting point. A router may send an ICMP fragmentation-needed message, but filtering that message can make the symptom look like a timeout.
MTU, or Maximum Transmission Unit, is the largest packet size an interface can carry without required fragmentation. The path MTU is the smallest effective MTU across the entire route. Tunnels, VPNs, WAN encapsulation, and other overhead can reduce it.
- Begin with a known working, conservative size.
- Enable extended commands and set DF according to the platform's prompt.
- Increase the datagram size in controlled steps.
- Record the largest successful size and the first failing size.
- Inspect interface, tunnel, and encapsulation MTUs and check filtering of ICMP control messages.
The size shown by an IOS prompt may represent the ICMP data or datagram test size rather than the complete on-wire IP packet. Total IPv4 packet size includes the configured data plus the IP header and ICMP header. For a basic IPv4 Echo packet with no IP options, the common calculation is:
total IP packet size = ICMP data size + 20-byte IPv4 header + 8-byte ICMP headerTherefore, do not compare a prompt value directly with an interface MTU without accounting for header overhead and any tunnel or WAN encapsulation.
Packet-Size Sweeps
A size sweep sends multiple probes over a specified range of sizes. It can show where loss or fragmentation-related failure begins and is useful for estimating a limiting path MTU. Sweep prompts and syntax are IOS- and platform-dependent, so use only the parameters offered by the device.
Payload Validation and Data Patterns
Payload validation checks whether returned Echo data matches the data that was sent. If the platform supports this option, it can help detect data alteration rather than merely checking that an Echo Reply arrived.
A data pattern is a chosen bit pattern placed in the test data. Nondefault patterns can help investigate suspected corruption, framing errors, or clocking problems, especially on serial or legacy WAN links. The default hexadecimal pattern is an implementation default; verify it on the actual device instead of assuming it is universal.
Ping results are not sufficient to confirm a physical or data-link fault. Correlate the test with show interfaces, physical diagnostics, CRC and framing counters, clocking information, circuit-provider data, and error logs.
IP Header Options
Some IOS versions expose specialized IP options:
- Loose source route: requests that traffic pass through specified routers, while allowing other hops between them.
- Strict source route: requests that traffic follow specified routers directly and in the specified order.
- Record route: asks routers to record addresses encountered along the path.
- Timestamp: requests timing information from participating devices.
- Verbose-related options: provide additional diagnostic output where supported.
These features are not routine connectivity tests. They may be unsupported, filtered by security devices, deprecated, or unsuitable for production traffic. Use them only when the platform and network policy explicitly support the test.
Practical Diagnostic Examples
Investigate Intermittent Loss
Increase the repeat count and use a timeout appropriate for the path. Compare the success percentage and RTT range across multiple runs. Then correlate the result with interface drops and errors, congestion, CPU utilization, QoS policing, and ICMP rate limiting. Partial success can also result from ECMP paths with different reachability or MTU characteristics.
Verify a QoS Marking
Set a supported ToS or DSCP-related value in the extended dialog. Inspect policy counters or capture the packet to confirm the mark and classification. Do not infer that a reply proves all QoS actions were applied.
Investigate Serial-Link Corruption
Select a supported alternate data pattern and enable reply-data validation if available. Send enough probes to make the symptom reproducible. Confirm the finding with interface CRC, framing, input-error, and clocking counters plus physical-circuit diagnostics.
Troubleshooting Checklist
Alternate Source Fails but Default Ping Works
- Verify that the selected source address belongs to an up/up interface and is correctly configured.
- Check the local route toward the destination.
- Check the remote or upstream route toward the selected source subnet.
- Review ACLs, firewall rules, NAT, VRF boundaries, and control-plane policies in both directions.
- Retest after correcting the return route or policy.
Small Packets Work but Large DF-Set Packets Fail
- Reduce the size until DF-set probes succeed.
- Calculate total packet size, including IP and ICMP headers.
- Inspect interface and tunnel MTUs and encapsulation overhead.
- Check whether ICMP fragmentation-needed messages are filtered.
Useful Verification Commands
Router# show ip route
Router# show ip interface brief
Router# show interfaces
Router# show access-lists
Router# traceroute 10.0.0.2Use the routing table to inspect the destination route and the expected return route. Use interface output to check administrative state, line protocol state, addresses, errors, and drops. Traceroute investigates the forward path, but its source-selection syntax and capabilities are platform-dependent.
Limits of Ping
A successful ping verifies only that ICMP traffic was returned under the tested conditions. It does not independently validate TCP or UDP ports, DNS name resolution, application health, authentication, or every possible path.
Ping can fail while an application works because a firewall or ACL filters ICMP, a device rate-limits or deprioritizes ICMP, or the application uses a permitted TCP or UDP flow. When this occurs, review ICMP policy and test the actual application port with an appropriate tool.
If an option described in a guide is absent, the IOS version, feature set, platform, protocol, or address family may differ. Use CLI help and device documentation, and record the software and platform when comparing behavior.
Continue with the focused guide: Use Extended Ping.