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.

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

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

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