IEEE 1588 Precision Time Protocol (PTP) is supported on Spectrum switches as of Onyx release 3.6.6000.
When enabled, the Onyx powered switch operates as an IPv4 end-to-end IEEE 1588-2008 (PTP version 2) 2-step Boundary Clock.
The following command globally enables the PTP protocol on the switch:
Prerequisite: IP address bound to the interface. PTP messages are sourced using the primary address of the interface
The following command enables PTP on a specific interface:
interface ethernet x/y
Prerequisite: IP address bound to the VLAN interface. PTP messages are sourced using the primary address of the interface.
The following command enables PTP on a specific VLAN:
interface vlan #
The following command enables the VLAN that requires PTP support per port.
interface ethernet x/y
Note: This tiered model allows to retain full control over the configuration granularity as to which VLANs and ports part of a VLAN are PTP enabled. A port may be part of multiple VLANs but only those that are specifically enabled and mapped to a PTP enabled VLAN will have a PTP port state enabled.
By enabling PTP on an interface, all incoming PTP messages are timestamped and trapped to the PTP engine and therefore not treated as regular multicast packets.
Default PTP message rates values and ranges as defined in the SMPTE ST 2059-2:2015 PTP Profile used in the Broadcast Media segment. These message rate values and domain ID can be changed to support those used by other PTP profiles such as AES67, AESr16, IEEE 1588-2008 Annex J.
|-3 (0.125s), 1 (2s)||-2 (0.25s)|
|Announce Receipt Timeout Interval||2, 10||3|
|Sync Interval (logSyncInt)||-7, -1||-3|
|Follow_up||N/A||Same rate as logSyncInt|
logSyncInt, logSyncInt +5
|Domain ID||0, 127||127|
PTP Port State
An understanding of the different PTP port states will help identify issues and troubleshoot what their root cause may be.
Port initializes its data sets, hardware, and communication facilities
Fault state of the protocol, no PTP messages except management
No messages on its communication path
Waiting for the announceReceiptTimeout to expire or to receive an Announce message from a master
Behaves as a master except no messages are sent, only management
Port is behaves as master
No messages sent except signaling or management messages
Transient state to allow initialization of synchronization servos, updating of data sets when a new master port has been selected
Synchronized to the selected master port
When in need of troubleshooting the PTP infrastructure, there are a series of parameters you may want to check.
All PTP nodes should be part of the same domain ID. PTP nodes shall ignore messages that are not for the Domain ID they are part of.
All PTP message rates should be configured to the same values for all the devices (Boundary Clocks, PTP Grand Master, PTP Slaves, etc). In the case of a rate mismatch and/or timeout values, devices with a higher message rate may consider that those with a lower message rate are timing out which would impact the PTP port state.
As of Onyx release 3.6.8008, the default communication mode for the Delay Request messages between a PTP port in Slave state and a Master is using "Mixed Mode", sometimes also known as "Hybrid". Thereby, a Master must respond to the unicast Delay Request message issued by a PTP Slave port with a Unicast Delay Response. This significantly reduces the processing load on PTP Slave ports that are in the same broadcast domain since the messages are not sent using multicast to the 126.96.36.199 group that all PTP nodes are mandated to listen to for receiving their PTP messages.
If there is a requirement to run all PTP messages from a PTP Slave port as multicast, the following command allows you to revert from mixed mode to multicast for any PTP port in Slave state.
ptp message-format multicast
While Masters may send using either the 1-step clock mechanism (sync message) or 2-step clock mechanism (sync and follow_up messages), all PTP ports in Slave state MUST be able to work with both modes as defined in the IEEE 1588-2008 standard. Some PTP implementations are known to have issues in this area, hence verification may be required.
During the election of the Master, Best Master Clock Algorithm (BMCA) follows a number of rules to determine which clock will serve as the Master. The following order is used to select the clock:
- Priority 1: The smaller the number the higher the priority. This is user settable in many implementations and serves to build a static hierarchy amongst Master clocks. Beware that this overrides clock class and accuracy.
- Clock Class: The clock is given a class based on the reference clock it is locked to. For example, a class of 6 is considered synchronized to a primary reference time source such as GPS. A value of 248 is the default for devices that are most likely freerunning from their internal oscillator.
- Accuracy: This refers to the value derived from the estimated accuracy based on the timesource attribute, the elapsed time since the last synchronization to the time source and the holdover specifications of the clock.
- Variance: The variability of the clock based on the Allan deviation.
- Priority 2: The smaller the number, the higher the priority. This is user settable in many implementations.
- Source PTP Port: The MAC address-based selection is used as a tiebreaker when all other properties are equal.
- Steps Removed: If there are multiple paths to the same Master across one of more Boundary Clocks, the one with the lowest Steps Removed count is preferred.
Securing the PTP Infrastructure
In Onyx 3.6.8100, 2 new commands related to securing the PTP infrastructure were introduced.
Acceptable Master Table (AMT)
AMT is an optional feature of the IEEE 1588 standard whereby you can configure a slave port to refuse to synchronize to clocks which are not part of the acceptable master table whitelist. In Onyx, this list is built against the Clock ID of the candidate masters. This option helps with reducing the risk of slaving from misconfigured or rogue Masters wherever they may be in the PTP domain. Therefore this command is global to the switch and not on a per port basis.
The following command enables AMT for all ports on the switch:
ptp amt <clock-id>
Forced Master Role
Forcing the PTP port state to Master for specific ports and/or VLANs provides a mechanism to prevent a Boundary Clock PTP port from changing state to anything but Master. This provides a means to help with reducing the risk of slaving from misconfigured or rogue Masters from directly connected PTP ports.
The following command enables Forced-Master on a specific interface or VLAN:
ptp enabled <forced-master>
Both of these security features provide a logging capability to track if any PTP nodes don't comply with the AMT whitelist or were advertising themselves as a Master when directly connected to the switch on a "forced-master" port and/or VLAN.