• PTP might get stuck in a Acquiring state.

user@QFX> show ptp lock-status detail

Lock Status:

Lock State : 3 (ACQUIRING)

Phase offset : -0.001777120 sec

State since : 2024-04-12 00:03:43 UTC (01:52:37 ago)

1) PTP might get stuck in Acquiring state:

labroot> show ptp lock-status detail

Lock Status:

Lock State : 3 (ACQUIRING)

Phase offset : -0.001777120 sec

State since : 2024-04-12 00:03:43 UTC (01:52:37 ago)

2)Below FPGA Errors were generated in Syslog:

> show log messages | match FPGA

fpc0 PTP FPGA: FPGA RX Error(512)

fpc0 PTP FPGA: FPGA RX Error - bad start of packet - resetting rx fifo 0x01000001, len 65, ppe_pflag 0xa40b023d

3)Sxe interface flaps might be seen:

>show log messages | match sxe

SNMP_TRAP_LINK_DOWN: ifIndex 516, ifAdminStatus up(1), ifOperStatus down(2), ifName sxe-0/0/1

SNMP_TRAP_LINK_UP: ifIndex 516, ifAdminStatus up(1), ifOperStatus up(1), ifName sxe-0/0/1

SNMP_TRAP_LINK_DOWN: ifIndex 516, ifAdminStatus up(1), ifOperStatus down(2), ifName sxe-0/0/1

SNMP_TRAP_LINK_UP: ifIndex 516, ifAdminStatus up(1), ifOperStatus up(1), ifName sxe-0/0/1

• ACQUIRING state means that the device started negotiation with Grand Master (GM), and exchange messages with the GM to determine the delay induced by the network and try to sync with the GM clock.
• If the device is unable to receive some information that it needs from GM, it gets stuck in Acquiring State.

• This issue is seen when FPGA (hardware component inside FPC that takes care of the PTP communication) is unable to receive some info that it needs from GM.
• Since this is an hardware error, it is most likely to get fixed with replacement of the unit.

Workaround:-

• Perform a Power cycle of the device in MW.
• After the Power cycle verify ptp lock-status detail and then check for the FPGA error logs.
• If you still see the error logs and PTP is still in Acquiring state, it indicates a Hardware issue. Replace the box.