Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Junos] 'Ping overlay' output rtt value may not be accurate

0

0

Article ID: KB34221 KB Last Updated: 13 May 2019Version: 1.0
Summary:

'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.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search