Support Support Downloads Knowledge Base Case Manager My Juniper 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

'Invalid client recv timestamp' counters increment when RPM is configured in a directly connected LAG between two MX routers

0

0

Article ID: KB31511 KB Last Updated: 30 Mar 2017Version: 1.0
Summary:

This article explains why 'Invalid client recv timestamp' counters increment when RPM is configured in a directly connected LAG between two MX routers. It also shows how to resolve the issue.

Symptoms:

When two routers are directly connected over a link aggregation group (LAG) consisting of two or more members on different PFEs, and when RPM with hardware time stamps configured over them, the 'Invalid client recv timestamp' counters increment in the 'show services rpm probe-results owner <probe-owner> test <probe-test-name>'.

Example:

lab@labrouter> show services rpm probe-results owner UDP-PROBE-Best_Effort test labrouter | match "Invalid client recv timestamp"
Invalid client recv timestamp: 94213, Invalid server send timestamp: 21

Cause:

The counters increment because the UDP probes are sent out and received on different members of the LAG. More specifically, the time stamp of the probe sent by client (t1) is greater than the time stamp of probe received by the same client. Ideally t1 should never be greater than t4.

Since 'hardware-timestamps' is used, the PFE time is used to log the time tamps of the probes. If the clocks of the PFEs in different FPCs are not in sync, then in the LAG scenario, the timestamp of the probe sent by one LAG member (t1) can be greater than timestamp of probe received by the other LAG member (t4). 

Solution:

One solution is to ensure that all LAG members are in the same PFE. This way, the time of the same PFE is used to log the outgoing and incoming time stamps. Hence, the errors will not increment.

Another solution is to delete the 'hardware-timestamps'. This will cause the RE/kernel to log the timestamp.

lab@labrouter> delete services rpm probe owner test test-name hardware-timestamp

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