ping [ip]
Tests basic network connectivity to a remote host by sending ICMP echo requests and waiting for replies.
Overview
The ping command is a fundamental network diagnostic tool used to test reachability and measure round-trip time between a source and destination IP address. It operates by sending Internet Control Message Protocol (ICMP) Echo Request packets to the target host, which then responds with ICMP Echo Reply packets if reachable. The command is essential for verifying basic IP connectivity, identifying packet loss, and assessing latency in a network.
In Cisco NX-OS (Nexus switches), ping is available in EXEC mode and supports various options to tailor the test. By default, it sends five ICMP echo requests with 56 bytes of data (64 bytes total ICMP packet). The output provides per-packet details and a summary with statistics. NX-OS also supports pinging over specific VRFs (Virtual Routing and Forwarding) using the 'vrf' keyword, which is crucial in multi-VRF environments like data centers. Additionally, the 'source' option allows specifying a particular interface or IP address as the source, which is useful for testing policy-based routing or verifying source-based forwarding.
Ping is typically the first step in troubleshooting connectivity issues. A successful ping confirms that the network layer (IP) is working between the two hosts, but it does not guarantee higher-layer services (e.g., TCP ports). When ping fails, it indicates a problem at Layer 3 or below, such as a missing route, incorrect subnet mask, firewall blocking ICMP, or a physical issue. On NX-OS, ping can also be used to test the management interface by specifying 'vrf management'. Understanding how to interpret ping output and use its options is critical for network engineers, especially in CCNP Data Center exams where Nexus platforms are featured.
ping [ip] [vrf <vrf-name>] [count <number>] [size <bytes>] [source <ip-address>] [timeout <seconds>] [df-bit] [validate] [verbose]When to Use This Command
- Verify reachability to a default gateway after configuring an interface.
- Check connectivity to a remote server across a WAN link.
- Test DNS resolution by pinging a hostname (if DNS configured).
- Isolate packet loss issues by varying packet size or count.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| ip | ip-address | hostname | The destination IP address or hostname to ping. If a hostname is used, DNS resolution must be configured. For IPv6, use 'ping ipv6' command. |
| vrf | vrf <vrf-name> | Specifies the VRF instance to use for the ping. This is essential in multi-VRF environments to ensure the ping uses the correct routing table. Default is the global VRF. |
| count | count <number> | Number of ICMP echo requests to send. Default is 5. Increasing count helps in assessing packet loss over time. |
| size | size <bytes> | Size of the ICMP data portion in bytes. Default is 56. Larger sizes can test fragmentation or MTU issues. Maximum is typically 9216 bytes (jumbo frames). |
| source | source <ip-address> | Specifies the source IP address for the ping. Useful when the device has multiple interfaces and you want to test connectivity from a specific IP. |
| timeout | timeout <seconds> | Time in seconds to wait for each reply. Default is 2 seconds. Increase for high-latency links. |
| df-bit | df-bit | Sets the Don't Fragment (DF) bit in the IP header. Used to test Path MTU Discovery. If a packet exceeds the MTU along the path, it will be dropped and an ICMP Fragmentation Needed message may be returned. |
| validate | validate | Validates that the reply packet matches the request (e.g., checksum, data). Useful for detecting data corruption. |
| verbose | verbose | Displays additional details for each reply, such as TTL and timing information. Already included in default output but may show extra fields. |
Command Examples
Basic ping to default gateway
ping 192.168.1.1PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.567 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.489 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.512 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.478 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=0.501 ms --- 192.168.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0.00% packet loss round-trip min/avg/max = 0.478/0.509/0.567 ms
Each line shows a successful reply: bytes received, source IP, sequence number, TTL (255 indicates directly connected), and round-trip time in milliseconds. Summary shows 0% loss and min/avg/max RTT.
Ping with extended parameters
ping 10.10.10.1 count 10 size 1500 source 192.168.1.100 timeout 2PING 10.10.10.1 (10.10.10.1) from 192.168.1.100: 1500 data bytes 1508 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=1.234 ms 1508 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=1.198 ms ... 1508 bytes from 10.10.10.1: icmp_seq=9 ttl=64 time=1.211 ms --- 10.10.10.1 ping statistics --- 10 packets transmitted, 10 packets received, 0.00% packet loss round-trip min/avg/max = 1.198/1.215/1.234 ms
Sends 10 packets of 1500 bytes (plus 8-byte ICMP header) from source IP 192.168.1.100 with 2-second timeout. TTL=64 suggests the target is a router or Linux host. All packets received with low latency.
Understanding the Output
The ping output begins with a header showing the destination IP and data size. Each successful reply line displays: the number of bytes received (including IP and ICMP headers), the source IP of the reply, the ICMP sequence number (starting at 0), the Time-to-Live (TTL) value, and the round-trip time (RTT) in milliseconds. The TTL indicates how many hops the packet traversed; a TTL of 255 suggests directly connected, 128 is typical for Windows, 64 for Linux/Cisco IOS. The RTT is a key performance indicator: values under 1 ms indicate excellent connectivity, while values over 100 ms may indicate high latency or congestion. The summary section shows total packets transmitted and received, packet loss percentage, and min/avg/max RTT. 0% loss is healthy; any loss suggests network issues such as congestion, faulty hardware, or routing problems. High RTT variance (jitter) can indicate intermittent problems. If no replies are received, the command will display 'Request timeouts' or '100% packet loss', indicating a connectivity failure that may be due to incorrect IP, no route, firewall blocking, or the destination being down.
Configuration Scenarios
Ping from Management VRF
A Nexus switch has a management interface in VRF management. You need to test connectivity to a management server.
Topology
Nexus (mgmt0: 192.168.1.100/24) --- Management Network --- Server (192.168.1.200)Steps
- 1.Access the switch CLI in EXEC mode.
- 2.Use the ping command with vrf management to specify the management VRF.
- 3.Observe the output for success or failure.
! No configuration needed; command is run in EXEC mode. ping 192.168.1.200 vrf management count 3
Verify: Check that the ping succeeds with 0% loss. If it fails, verify management interface status and default route in VRF management.
Watch out: If you omit 'vrf management', the ping uses the default VRF (data plane) and may fail if the management network is not reachable via that VRF.
Ping with Source IP to Test Policy-Based Routing
You have configured policy-based routing (PBR) that forwards traffic based on source IP. You need to verify that traffic from a specific source IP takes the correct path.
Topology
Nexus (Eth1/1: 10.0.0.1/24, Eth1/2: 20.0.0.1/24) --- Router (10.0.0.2/24, 20.0.0.2/24)Steps
- 1.Determine the source IP to test (e.g., 10.0.0.100, which is a loopback or secondary IP).
- 2.Use ping with source option to send packets from that IP.
- 3.Observe the path using traceroute or check counters.
! No configuration needed. ping 20.0.0.2 source 10.0.0.100 count 1
Verify: If PBR is working, the ping should succeed. Use 'show ip route' to verify the routing table for the source IP.
Watch out: The source IP must exist on the switch (e.g., as a secondary IP on an interface). Otherwise, the ping will fail with 'Invalid source address'.
Troubleshooting with This Command
When troubleshooting connectivity issues with ping on Cisco NX-OS, start with a basic ping to the destination IP. If it fails, check the following:
1. **Verify IP configuration**: Ensure the source interface has a correct IP address and subnet mask. Use 'show ip interface brief' to confirm. 2. **Check routing**: Use 'show ip route <destination>' to see if a route exists. If not, add a static route or check dynamic routing protocols. 3. **VRF mismatch**: If the destination is in a different VRF, specify the correct VRF with 'vrf <name>'. Use 'show vrf' to list VRFs. 4. **Firewall/ACL**: ICMP may be blocked by access-lists or firewall policies. Check with 'show ip access-lists' and 'show running-config | include icmp'. 5. **ARP resolution**: If the destination is on the same subnet, ensure ARP is resolved. Use 'show ip arp <ip>' to verify. 6. **MTU issues**: If large pings fail but small ones succeed, there may be an MTU problem. Use the 'size' option with increasing sizes and 'df-bit' to test Path MTU. 7. **Packet loss**: If intermittent loss occurs, use 'count' with a high number (e.g., 100) to assess loss percentage. Also check interface errors with 'show interface counters errors'. 8. **High latency**: Use 'timeout' to adjust wait time. High RTT may indicate congestion or long-distance links. Use 'traceroute' to identify hops with high delay.
For advanced troubleshooting, consider using 'ping ipv6' for IPv6 networks, or 'ping vrf management' for out-of-band management. Always correlate ping results with other diagnostics like 'show logging', 'show system health', and 'ethernet' or 'fiber' checks.
CCNA Exam Tips
Remember that NX-OS ping uses 5 packets by default; IOS uses 5 as well but NX-OS may require 'count' for more.
Know that 'ping vrf management' is commonly used to test the management interface separately.
Be aware that NX-OS supports 'ping ipv6' for IPv6 connectivity tests.
Common Mistakes
Forgetting to specify VRF when pinging from a non-default VRF, causing failure.
Using 'ping' without source IP when multiple interfaces exist, leading to unexpected source selection.
Assuming ping success means full application connectivity; firewalls may allow ICMP but block TCP/UDP.
Platform Notes
Cisco NX-OS ping behavior is similar to Cisco IOS but with some differences. In NX-OS, the default count is 5 packets, same as IOS. However, NX-OS requires the 'vrf' keyword to specify a non-default VRF, whereas IOS uses 'vrf' as well but sometimes 'ping vrf' syntax differs. NX-OS also supports 'ping ipv6' as a separate command, while IOS uses 'ping ipv6' or 'ping' with IPv6 address. The 'df-bit' option is available in both, but NX-OS may have additional options like 'validate' and 'verbose'.
On Nexus platforms, the management interface (mgmt0) is in a separate VRF called 'management' by default. To ping from the management interface, you must use 'ping <ip> vrf management'. This is a common source of confusion for engineers migrating from IOS where the management interface is often in the global routing table.
In NX-OS, the ping command does not support interactive mode (extended ping) like IOS; all parameters must be specified on the command line. However, you can achieve similar functionality by using the options described. Also, NX-OS supports 'ping' with hostnames if DNS is configured, but it's recommended to use IP addresses for reliability.
Version differences: In older NX-OS versions (e.g., 5.x), the ping output may differ slightly. Newer versions (7.x, 9.x) have consistent output. Always check the documentation for your specific NX-OS release.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with hundreds of CCNA practice questions covering all exam domains.
Practice CCNA Questions