g bits to in- dicate that it has a traceable source of time and frequency. Make sure the clock is select- ing the correct master based on those Announce messages and that the port facing that foreign master goes into slave state. C. Ensure the packet counters are increasing steadily and in proportion to the expected packet rates. For G.8275.1, confirm that the packet rates are set according to the profile and are flowing in the correct direction. As a quick check, the count of Delay_Req, Delay_Resp, and Sync (and optional Follow_Up) should be twice the number of An- nounce messages. Only Delay_Re should be transmitted from the slave port; the rest should only be received by it (the opposite is true for a master port). d. For G.8275.2, ensure that the clock is completing negotiation with the master and confirm that the configured packet rates match the master configuration. A mismatch of packet rates can cause Announce timeouts, which interrupts the whole acquiring process. A packet trace helps considerably because it allows you to see what is happening if you sus- pect that the negotiation process is failing to complete. Announce timeouts happen when the master is sending (for example) only one Announce message per second and the slave is expecting more, such as eight per second. If the an- nounce timeout is set to three messages on the slave, then the announce timeout event will trigger after the slave thinks it has missed three Announce messages, or after 0.375 S. This will restart the whole negotiation process, and it will never lock. Step 5. If there is no alignment, check the one-step versus two-step interoperability. Ensure that the two-step bit is set in the Sync packet if the master is a two-step clock and that a Follow_Up arrives with a matching sequence number. The slave port should accept either, but if you know the slave device cannot accept what it is being offered, then adjust the master. Here are some additional troubleshooting steps based on some commonly observed symptoms: An engineer might obser