Description

'Ping overlay' is used to validate the VXLAN tunnels, but the rtt value in its output may not be accurate to determine delay/latency.

Symptoms

The following description is from Juniper's document on ping overlay :

"Ping overlay is a command used to verify the presence of the Virtual Extensible LAN (VXLANPing) tunnel endpoints (VTEPs), which can originate and terminate VXLAN tunnels, and service connectivity within the context of the overlay VXLAN segment. Use ping overlay as a fault detection tool to determine failure within an overlay VXLAN tunnel. Type Ctrl+c to interrupt a ping overlay command."

When this command is used, we see more than 1 msec round trip delay time (rtt) during ping overlay via VXLAN. The rtt value varies quite a bit when the command is issued several times. 

user@router> ping overlay tunnel-src 32.68.230.85 tunnel-dst 32.68.230.83 vni 110091    
ping-overlay protocol vxlan
        vni 110091
        tunnel src ip 32.68.230.85
        tunnel dst ip 32.68.230.83
        mac address 00:00:00:00:00:00
        count 5
        ttl 255
        WARNING: following hash-parameters are missing -
                hash computation may not succeed
                end-host smac
                end-host dmac
                end-host src ip
                end-host dst ip
                end-host input-ifd-idx
                end-host protocol
                end-host l4-src-port
                end-host l4-dst-port
Request for seq 1, to 32.68.230.83, at Mar 07 2019 11:03:44.234 EST Response for seq 1, from 32.68.230.83, at Mar 07 2019 11:03:44.341 EST, rtt 109 msecs
  Overlay-segment present at RVTEP 32.68.230.83
End-System Not Present
Request for seq 2, to 32.68.230.83, at Mar 07 2019 11:03:45.235 EST Response for seq 2, from 32.68.230.83, at Mar 07 2019 11:03:45.241 EST, rtt 17 msecs
  Overlay-segment present at RVTEP 32.68.230.83
End-System Not Present
Request for seq 3, to 32.68.230.83, at Mar 07 2019 11:03:46.236 EST Response for seq 3, from 32.68.230.83, at Mar 07 2019 11:03:46.276 EST, rtt 134 msecs
  Overlay-segment present at RVTEP 32.68.230.83
End-System Not Present
Request for seq 4, to 32.68.230.83, at Mar 07 2019 11:03:47.237 EST Response for seq 4, from 32.68.230.83, at Mar 07 2019 11:03:47.252 EST, rtt 18 msecs
  Overlay-segment present at RVTEP 32.68.230.83
End-System Not Present
Request for seq 5, to 32.68.230.83, at Mar 07 2019 11:03:48.237 EST Response for seq 5, from 32.68.230.83, at Mar 07 2019 11:03:48.263 EST, rtt 74 msecs
  Overlay-segment present at RVTEP 32.68.230.83
End-System Not Present

Solution

This is expected behavior. Ping overlay is a good way to check for link availability. However, it is not the most accurate way to test latency or delay. For example, a more accurate way to test for latency is to simulate data plane traffic using a traffic generator for the transit traffic.

There is some reasoning behind the RTT value for ping and why it may not be accurate. Juniper Networks platform architecture separates the control plane from the data plane. There are various rate-limiting and prioritization functions within the packet forwarding engine (PFE) and the routing engine. When a ping is sent from the routing platform to the end device, it uses the control plane on the local router in order to generate the ICMP request packet. The control plane is used again when the ICMP reply packet is received from the end device.

ICMP messages are considered low priority within JUNOS, so the routing platform will respond to and process other higher priority messages, such as routing updates, before processing the ICMP messages. The microkernel may introduce tens of milliseconds of processing delay to ICMP message handling. The delay is not uniform, meaning that some ICMP messages might be delayed while others may not be delayed.