Summary
When pinging from a VOS routing instance (VR), the ping may hang indefinitely unless a source IP is explicitly specified. This applies to any VR, transport, LAN, management, or custom whenever the return path is not guaranteed to be symmetric. This article explains why and when this is required.
Symptoms
Ping hangs with no output:
admin@device-cli> ping 1.1.1.1 routing-instance INET-Transport-VR PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. (no replies)
Ping succeeds when a source IP is specified:
admin@device-cli> ping 1.1.1.1 routing-instance INET-Transport-VR source 192.168.1.2 64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=22.4 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=22.7 ms
Root Cause
When VOS generates an ICMP ping from a routing instance, it must stamp a source IP on the outgoing packet. Without an explicit source, VOS picks the egress interface IP automatically based on the routing table lookup.
If the VR has multiple interfaces or paths (WAN, LAN, loopback, etc.), the return path for the ICMP reply is not guaranteed to be symmetric. The reply may arrive on a different interface than the one used for the outgoing packet. When this happens, VOS cannot match the reply to any open ICMP socket and silently drops it.
Pinning a source IP forces both the outbound packet and the expected return socket match to be consistent, the reply is always expected on the interface that owns that IP.
Conditions Requiring an Explicit Source
| Condition | Why It Fails Without Source |
|---|---|
| ECMP / multiple paths in any VR | Kernel picks any egress interface; reply may return on a different path and be dropped |
| SD-WAN transport VR (multiple WAN uplinks) | SD-WAN steering may route the reply on a different uplink than the outbound probe |
| LAN VR with multiple segments | Return traffic may ingress on a different LAN interface; ICMP socket match fails |
| Custom / management VR | Same asymmetric return path issue applies regardless of VR type |
| Unnumbered interfaces | No IP on the egress interface; nothing to source the packet from |
| NAT on return path | Reply arrives post-NAT and fails local socket lookup |
| VRF with asymmetric routing policy | ICMP reply hits the VR but finds no matching local socket; packet dropped silently |
Resolution
Always specify a source IP when pinging from any routing instance where the return path is not guaranteed to be symmetric. This is not limited to transport or WAN VRs, it applies equally to LAN, management, or any custom VR with multiple interfaces or routing paths.
Syntax
ping <destination> routing-instance <VR-name> source <local-IP>
Example
ping 1.1.1.1 routing-instance INET-Transport-VR source 192.168.1.2
Choose a source IP that belongs to an interface within the target routing instance. Use the IP of the interface most likely to receive the return traffic.
Key Takeaway
Always specify source when pinging from any VR with multiple interfaces or where the return path is not symmetric. This is a required operational practice, not a workaround, it applies to transport, LAN, management, and custom routing instances alike.