CCNA online course

Cisco IOS Extended Ping: Test Reachability, Source Paths, and MTU

Learn how to use Cisco IOS extended ping to select a source address, verify return paths, test MTU, interpret results, and troubleshoot routing and ICMP problems.

Cisco IOS extended ping is an interactive version of ping that lets you control how an ICMP reachability test is sent. Besides choosing a destination, you can select the source interface or IP address, change the number of probes, test packet sizes, set the IPv4 Don't Fragment bit, and expose other diagnostic options.

This lesson assumes that you understand IPv4 addressing, router interfaces, basic routing, and the standard ping command.

What Ping Tests

Ping normally sends an ICMP Echo Request to a destination. A reachable destination returns an ICMP Echo Reply. The test therefore checks two related paths:

• The forward path from the router running ping to the destination.
• The return path from the destination back to the selected source address.

A successful reply proves that an ICMP exchange worked at the time of the test. It does not prove that every application, TCP or UDP port, DNS lookup, or security policy is working.

Basic Ping Versus Extended Ping

Starting Extended Ping in Cisco IOS

Interactive extended ping starts from privileged EXEC mode, identified commonly by a # prompt.

Router> enable
Router# ping

IOS then displays a sequence of prompts. Pressing Enter accepts the value shown in square brackets. A typical IPv4 source-specific test might begin like this:

Router# ping
Protocol [ip]:
Target IP address: 10.0.0.2
Repeat count [5]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.5.1

Extended Ping Prompts and Diagnostic Purpose

Selecting the Source Address

When no source is specified, IOS generally selects an address associated with the outgoing interface chosen by the routing table. This is convenient for a basic test, but it can hide a return-routing problem.

For example, imagine this topology:

• R2 connects to R1 through 10.0.0.0/24.
• R2 uses GigabitEthernet0/1 with address 10.0.0.1 toward R1.
• R2 also uses GigabitEthernet0/0 with address 192.168.5.1 on a local LAN.
• A target such as 10.0.0.2 is reachable through R1.

A default-source ping from R2 may use 10.0.0.1 and succeed. That only proves the destination can return traffic toward the transit network. It does not prove that R1 or the rest of the path has a route back to 192.168.5.0/24.

Run extended ping and select 192.168.5.1 as the source. If the reply succeeds, the forward path works and the remote side can return traffic to that selected source network. If it fails while the default-source test works, a missing route to 192.168.5.0/24 is a strong possibility. Also check ACLs, firewalls, NAT, VRF membership, and whether the source interface is up.

Router# ping
Protocol [ip]:
Target IP address: 10.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.5.1

Reading IOS Ping Output

IOS commonly displays one character for each probe, followed by a success-rate and timing summary. A successful reply is often shown as an exclamation mark, while a timeout is commonly shown as a period. An unreachable response may appear as a different failure indicator or as an explicit message, depending on IOS.

• All probes succeed: Every tested Echo Request received a reply within the timeout. The tested ICMP path is working at that moment.
• All probes time out: No reply arrived within the configured timeout. Possible causes include a missing route, a down target, filtering, an unreachable source, or ICMP rate limiting.
• Some probes succeed: The path is intermittently losing replies, or a policy, load-sharing path, queue, or physical link is behaving inconsistently.
• Unreachable response: A router or host generated an indication that the destination or route was unreachable. Identify which device sent it and verify its routing and policy.

Success Rate and Round-Trip Time

The success rate is the percentage of probes that received replies. A result such as 100 percent indicates no loss during that sample; a lower percentage indicates partial loss. Round-trip timing shows how long replies took to return, including forwarding, queuing, and processing. Compare timing across repeated tests, but do not treat one high value as proof of a particular fault.

Testing Path MTU and Fragmentation

MTU, or Maximum Transmission Unit, is the largest IP packet a link can carry without fragmentation. A tunnel, VPN, PPPoE connection, or WAN segment may have less usable MTU than an ordinary Ethernet segment.

To expose an MTU restriction, send a large echo request with the DF bit enabled. DF means Don't Fragment: routers must not fragment the IPv4 packet. If the packet is too large for a path segment, the test fails rather than allowing fragmentation.

Router# ping
Protocol [ip]:
Target IP address: 198.51.100.10
Repeat count [5]: 5
Datagram size [100]: 1472
Timeout in seconds [2]:
Extended commands [n]: y
Set DF bit in IP header? [no]: yes

The sample value of 1472 is commonly used for a 1500-byte IPv4 path because 20 bytes of IPv4 header and 8 bytes of ICMP header are added. In this example, the approximate full packet size is:

1472 bytes ICMP data
+ 8 bytes ICMP header
+ 20 bytes IPv4 header
= 1500 bytes

Always confirm what the IOS release means by its datagram-size prompt. The entered value is commonly the ICMP data size, not the full on-wire packet size. Additional headers from tunnels or other encapsulation reduce the available payload further.

Finding the Largest Working Size

1. Start with a size that should fit the expected path.
2. Enable DF and send several probes.
3. If the probes fail, reduce the data size and test again.
4. Continue reducing or use a supported size sweep to find the largest successful value.
5. Add the IP and ICMP overhead to relate the successful payload to the effective IP MTU.

A size sweep is a sequence of tests with increasing or otherwise changing sizes. It can efficiently identify a threshold, but exact syntax and whether the displayed size is payload or total packet size vary by platform.

Other Extended Options

Type of Service

The IPv4 Type of Service (ToS) field historically influenced service treatment. It is related conceptually to modern QoS marking. Setting a ToS value can provide a limited diagnostic comparison, but devices may ignore, rewrite, or classify it differently.

Reply Validation and Data Patterns

Reply-data validation checks whether the returned payload matches what was sent. A selectable data pattern changes the bits in the payload. Certain patterns can help reveal transmission, framing, or serial-link corruption. Use interface error counters and physical-layer checks as well; a ping pattern test alone cannot locate every corruption problem.

IP Header Options

Depending on the IOS release, extended ping may expose loose source route, strict source route, record route, timestamp, or verbose output. Loose and strict source routing attempt to influence the path. Record route requests that routers place addresses in the packet. These options are frequently unsupported, filtered, or limited by packet-header space, so they are mainly useful in controlled testing.

A Repeatable Troubleshooting Method

1. Verify local interfaces. Confirm that the relevant interface is up, has the expected address, and is in the correct VRF.
2. Confirm local addressing. Check subnet masks, connected routes, and whether the chosen source address is operational.
3. Test an adjacent device. Ping the next hop or a directly connected router before testing a distant target.
4. Test the destination with the default source. This establishes whether the normal routing path works.
5. Repeat with a chosen source. Select the address of the local subnet whose return route you need to verify.
6. Compare results. A default success and selected-source failure points toward return routing or source-specific policy.
7. Investigate policy and translation. Check ACLs, firewall rules, NAT behavior, ICMP rate limiting, and host-based firewalls.
8. Test packet size if appropriate. Use larger payloads with DF to investigate MTU restrictions.
9. Use traceroute when the failure location is unknown. Traceroute complements ping by showing responding hops and often identifies where replies stop.

Router# show ip interface brief
Router# show ip route 192.168.5.0 255.255.255.0
Router# show access-lists
Router# traceroute 10.0.0.2

Troubleshooting Common Results

Normal Ping Works, LAN-Source Ping Fails

First verify that the LAN interface and source address are up. Then inspect the remote routing table for a route toward the selected LAN prefix. Also check return-path ACLs, firewalls, NAT, and VRF membership. The failure does not automatically mean that the forward route is absent.

All Probes Time Out

Test the next hop first, review local and remote routes, and use traceroute to locate the last responding hop. The target may be down or may disable ICMP. An ACL, firewall, rate limiter, or invalid source address can produce the same symptom.

Some Probes Succeed and Some Fail

Increase the repeat count to characterize the loss pattern. Inspect interface errors, drops, speed and duplex settings, congestion, routing stability, equal-cost paths, MTU differences, and ICMP rate limiting. Compare tests by source, size, and time of day.

Small Packets Work but Large DF Packets Fail

Reduce the payload until replies succeed. Then inspect tunnel, VPN, PPPoE, MPLS, or WAN MTU values and determine whether required ICMP control messages are being filtered.

Ping and Application Results Disagree

ICMP may be filtered even when TCP or UDP is allowed, or the application may use another port, protocol, VRF, DNS name, or security policy. Conversely, a successful ping does not prove that the application service is listening or reachable.

VRF-Aware Testing

A VRF, or Virtual Routing and Forwarding instance, provides a separate routing-table context. A destination reachable in the global table may be unreachable in a management VRF, and the reverse may also be true. Use the VRF-aware form when supported:

Router# ping vrf MANAGEMENT 198.51.100.10

Exact syntax and interactive options vary by IOS family and release. Ensure that the source address and route being tested belong to the same intended routing context.

Exam-Relevant Notes

• Interactive extended ping is launched from privileged EXEC mode, commonly shown as Router#.
• Answering y to Extended commands exposes source selection and other diagnostic controls.
• A source IP determines where the destination sends the Echo Reply, so source selection tests the return path for that address.
• A default-source success does not prove reachability to every local subnet.
• DF prevents fragmentation; large DF pings can reveal a lower path MTU.
• The configured data size commonly excludes the IPv4 and ICMP headers, so account for overhead.
• Partial success means loss occurred during the sample; investigate rather than treating it as a complete failure.
• A failed ping alone does not prove a routing failure because filtering, host policy, NAT, VRFs, rate limiting, and target behavior also affect ICMP.

Further Study

For related routing concepts, review computer network fundamentals, the OSI reference model, and OSPF configuration and verification.