that this occurs is because of a timing loop affecting the ESMC and SyncE. The fix is to check the topology for any timing loops. One hint would be to reduce the number of frequency inputs to each node to only a single primary and backup interface. Turning on every possible interface as a pos- sible source of SyncE frequency complicates the troubleshooting and can easily cause trouble. Of course, the node can output SyncE on every port if the node supports it, but just be careful to limit the number of inputs, especially in complex topologies. Another common issue is where a clock flaps between the states of FREQUENCY-LOCKED and PHASE-ALIGNED. This is one of the most common problems that the authors see customers run into, and there is really very little that a vendor can do because it is normally the result of a deploy- ment decision (such as the network has excessive PDV). Some of the reasons that this could be hap- pening include the following: There are active timing loops. Go back to the frequency steps to ensure there is not a frequency loop with the SyncE configuration. One (subtle) way you might see a timing loop is where the SyncE from node A is being given to node B and node B is giving PTP (phase) to node A. Be- cause the frequency signal flows into the time clock on node B, this can produce loop-like beha- vior between them. The servo, upon calculating a very high variation in phase (taking the calculated phase offset outside some preset limit like 1.5 us), may go back to FREQUENCY-LOCKED state and try to reacquire phase. The most common cause of this would be very high fluctuations in TE caused by excessive PDV and asymmetry in the path between the master and the slave. Unaware nodes in the path (especially for the PTS case with G.8275.2) or behavior from the packet transport (for example, a timing-unaware microwave system in the path) might allow the accumulation of PDV. For the FTS case with G.8275.1 (because it has full on-path support and resets PDV at every T-BC), this would strongly suggest som