Configuring Precision Time Protocol PTP
Configuring Precision Time Protocol PTP
• Transparent clock mode is not supported on native Layer 3 ports and EtherChannel interfaces. (boundary
clock mode is supported on native Layer 3 ports)
• You cannot configure PTP on any port of a supervisor module.
• Stateful Switchover (SSO) does not support PTP. The PTP protocol restarts after a switchover.
• MACsec with Precision Time Protocol (PTP) is not supported.
Why PTP?
Smart grid power automation applications such as peak-hour billing, virtual power generators, and outage
monitoring and management, require extremely precise time accuracy and stability. Timing precision improves
network monitoring accuracy and troubleshooting ability.
In addition to providing time accuracy and synchronization, the PTP message-based protocol can be
implemented on packet-based networks, such as Ethernet networks. The benefits of using PTP in an Ethernet
network include:
• Low cost and easy setup in existing Ethernet networks
• Limited bandwidth is required for PTP data packets
Why PTP?
In an Ethernet network, switches provide a full-duplex communication path between network devices. Switches
send data packets to packet destinations using address information contained in the packets. When the switch
attempts to send multiple packets simultaneously, some of the packets are buffered by the switch so that they
are not lost before they are sent. When the buffer is full, the switch delays sending packets. This delay can
cause device clocks on the network to lose synchronization with one another.
Additional delays can occur when packets entering a switch are stored in local memory while the switch
searches the MAC address table to verify packet CRC fields. This process causes variations in packet forwarding
time latency, and these variations can result in asymmetrical packet delay times.
Adding PTP to a network can compensate for these latency and delay problems by correctly adjusting device
clocks so that they stay synchronized with one another. PTP enables network switches to function as PTP
devices, including boundary clocks (BCs) and transparent clocks (TCs).
Message-based Synchronisation
To ensure clock synchronization, PTP requires an accurate measurement of the communication path delay
between the time source (master ) and the receiver (slave ). PTP sends messages between the master and slave
device to determine the delay measurement. Types of messages are described in detail in PTPv2 Message
Types, on page 3. Then, PTP measures the exact message transmit and receive times and uses these times
to calculate the communication path delay. PTP then adjusts current time information contained in network
data for the calculated delay, resulting in more accurate time information.
This delay measurement principle determines path delay between devices on the network, and the local clocks
are adjusted for this delay using a series of messages sent between masters and slaves. The one-way delay
time is calculated by averaging the path delay of the transmit and receive messages. This calculation assumes
a symmetrical communication path; however, switched networks do not necessarily have symmetrical
communication paths, due to the buffering process.
PTP provides a method, using transparent clocks, to measure and account for the delay in a time-interval field
in network timing packets, making the switches temporarily transparent to the master and slave nodes on the
network. An end-to-end transparent clock forwards all messages on the network in the same way that a switch
does.
The following figure shows a typical 1588 PTP network that includes grandmaster clocks, switches in boundary
clock mode, and Intelligent Electronic Device (IEDs) such as a digital relays or protection devices. In this
diagram, Master 1 is the grandmaster clock. If Master 1 becomes unavailable, the boundary clock slaves
switch to Master 2 for synchronization.
Figure 1: PTP Network
•
Announce messages are used to establish the synchronization hierarchy.
General Messages — General messages are not tagged with timestamps and are used to establish a master-slave
hierarchy. General messages are listed below:
• Announce
• Follow_Up
• Delay_Resp
• Pdelay_Resp_Follow_Up
Sync, Delay_Req, Follow_Up, and Delay_Resp messages are used to synchronize ordinary and boundary
clocks.
Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages are used to measure the link delay in
transparent clocks.
The Best Master Clock Algorithm elects the grandmaster clock and assign the ports as master or slave.
Following this, all the master ports start sourcing the clock to the downstream slaves using the Sync and
Follow_Up messages. The downstream slaves receive the clock and update their clock after computing the
delay of the link, time offset, frequency offset and drift error parameters.
The downstream slaves computes the link delay using one of the below mechanism.
• #unique_172
• Peer-to-Peer Delay Mechanism, on page 5
5. The master receives the Delay_Req message and notes the time of reception (t4).
6. The master conveys to the slave the timestamp t4 by embedding it in a Delay_Resp message.
After this sequence, the slave possesses all four timestamps. These timestamps can be used to compute the
offset of the slave clock relative to the master, and the mean propagation time of messages between the two
clocks.
The offset calculation is based on the assumption that the time for the message to propagate from master to
slave is the same as the time required from slave to master. Assumption is not always valid on an Ethernet
network due to asymmetrical packet delay times.
Figure 2: End-to-End Delay Mechanism
• Priority2 - Final-defined priority. The range is from 0 to 255. The default value is 128.
• Unique Identifier - 64-bit Extended Unique Identifier (EUI)
In addition to identifying the best master clock, the BMCA also ensures that clock conflicts do not occur on
the PTP network by ensuring that:
• Clocks do not have to negotiate with one another
• There is no misconfiguration, such as two master clocks or no master clocks, as a result of the master
clock identification process
PTP Clocks
A PTP network is made up of PTP-enabled devices. The PTP-enabled devices typically consist of the following
clock types.
Grandmaster Clock
Within a PTP domain, the grandmaster clock is the primary source of time for clock synchronization using
PTP. The grandmaster clock usually has a very precise time source, such as a GPS or atomic clock. When the
network does not require any external time reference and only needs to be synchronized internally, the
grandmaster clock can free run.
Note We do not recommend you to use the switch as GM clock in the network considering its reduced clock
accuracy.
Ordinary Clock
An ordinary clock is a PTP clock with a single PTP port. It functions as a node in a PTP network and can be
selected by the BMCA as a master or slave within a subdomain. Ordinary clocks are the most common clock
type on a PTP network because they are used as end nodes on a network that is connected to devices requiring
synchronization. Ordinary clocks have various interface to external devices.
Boundary Clock
A boundary clock in a PTP network operates in place of a standard network switch or router. Boundary clocks
have more than one PTP port, and each port provides access to a separate PTP communication path. Boundary
clocks provide an interface between PTP domains. They intercept and process all PTP messages, and pass all
other network traffic. The boundary clock uses the BMCA to select the best clock seen by any port. The
selected port is then set as a slave. The master port synchronizes the clocks connected downstream, while the
slave port synchronizes with the upstream master clock.
Transparent Clock
The role of transparent clocks in a PTP network is to update the time-interval field that is part of the PTP
event message. This update compensates for switch delay and has an accuracy of within one picosecond.
There are two types of transparent clocks:
End-to-end (E2E) transparent clocks measure the PTP event message transit time (also known as resident
time ) for SYNC and DELAY_REQUEST messages. This measured transit time is added to a data field
(correction field) in the corresponding messages:
• The measured transit time of a SYNC message is added to the correction field of the corresponding
SYNC or the FOLLOW_UP message.
• The measured transit time of a DELAY_REQUEST message is added to the correction field of the
corresponding DELAY_RESPONSE message.
The slave uses this information when determining the offset between the slave’s and the master’s time. E2E
transparent clocks do not provide correction for the propagation delay of the link itself.
Peer-to-peer (P2P) transparent clocks measure PTP event message transit time in the same way E2E
transparent clocks do, as described above. In addition, P2P transparent clocks measure the upstream link
delay. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P
transparent clock and the P2P transparent clock under consideration.
These two times (message transit time and upstream link delay time) are both added to the correction field of
the PTP event message, and the correction field of the message received by the slave contains the sum of all
link delays. In theory, this is the total end-to-end delay (from master to slave) of the SYNC packet.
The following figure illustrates PTP clocks in a master-slave hierarchy within a PTP network.
Figure 4: PTP Clock Hierarchy
PTP Profiles
The IEEE 1588 definition of a PTP profile is the set of allowed PTP features applicable to a device . A PTP
profile is usually specific to a particular type of application or environment and defines the following values:
• Best master clock algorithm options
• Configuration management options
• Path delay mechanisms (peer delay or delay request-response)
• Range and default values of all PTP configurable attributes and data set members
• Closest clock to the grandmaster
• Transport mechanisms that are required, permitted, or prohibited
• Node types that are required, permitted, or prohibited
• Options that are required, permitted, or prohibited
Default Profile
The default PTP profile mode on the switch is Default Profile mode. The PTP mode of transport is Layer 2
and Layer 3.
By default, PTP default profile is disabled globally on these platforms.
Procedure
Step 3 ptp mode {boundary {delay-req | pdelay-req Specifies the synchronization clock mode:
} | e2etransparent | p2ptransparent}
• boundary — mode to enable the switch
Example: to participate in selecting the best master
Device(config)# ptp mode boundary clock. If no better clocks are detected, the
delay-req switch becomes the grandmaster clock on
Device(config)# ptp mode boundary the network and the parent clock to all
pdelay-req connected devices. If the best master is
Device(config)# ptp mode e2etransparent
Device(config)# ptp mode p2ptransparent determined to be a clock connected to the
switch, the switch synchronizes to that
clock as a child to the clock, then acts as
a parent clock to devices connected to
other ports. After initial synchronization,
the switch and the connected devices
exchange timing messages to correct time
skew caused by clock offsets and network
delays. Use this mode when overload or
heavy load conditions produce significant
delay jitter
• e2etransparent — mode for the switch to
synchronize all switch ports with the grand
master clock connected to the switch,. This
is the default clock mode. The switch
corrects for the delay incurred by every
packet passing through it (referred to
residence time). This mode causes less
jitter and error accumulation than boundary
mode.
Step 3 ptp transport ipv4 udp Configures IPv4 as the PTP transport mode.
Example: Note Only IPv4 is supported as the PTP
Device(config)# ptp transport ipv4 udp transport method for Layer 3 PTP.
-1 2-1 1/2
0 20 1
Procedure
Step 4 ptp announce {interval value | timeout count} (Optional) Configures the interval between PTP
announce messages on an interface or the
Example:
number of PTP intervals before a timeout occurs
Device(config-if)# ptp announce interval on an interface.
1
• interval value — Sets the logarithmic
mean interval to send announce messages.
The range is 0 to 4. The default is 0 (1
second).
• timeout count — Sets the logarithmic
mean interval in seconds to announce
timeout messages. The range is 2 to 10.
The default is 3 (8 seconds).
Step 5 ptp sync {interval value | limit offset-value} (Optional) Configures the interval between PTP
synchronization messages on an interface.
Example:
Device(config-if)# ptp sync interval 1 • interval value — Sets the logarithmic
mean interval to send synchronization
messages. The range is –3 to 1. The default
is 0 (1 second).
• limit offset-value — Sets the maximum
clock offset value before PTP attempts to
resynchronize. The range is from 50 to
500000000 nanoseconds. The default is
500000000 nanoseconds.
Step 6 ptp delay-req interval value (Optional) Configures the logarithmic mean
interval allowed between PTP delay-request
Example:
messages when the port is in the master state.
Device(config-if)# ptp delay-req interval The range is 0 to 5. The default is 0 (1 second).
1
Step 7 ptp pdelay-req interval value (Optional) Configures the logarithmic mean
interval allowed between pdelay request
Example:
messages when the port is in the master state.
Device(config-if)# ptp pdelay-req The range is 0 to 5. The default is 0 (1 second).
interval 1
Procedure
Step 3 ptp priority1 value Sets the value of PTP clock priority1. The range
is from 0 to 255. The default value is 128.
Example:
Device(config)# ptp priority1 120 Note If the value of priority1 is
configured as 255, the clock
cannot be considered as
Grandmaster.
Step 4 ptp priority2 value Sets the value of PTP clock priority2. The range
is from 0 to 255. The default value is 128.
Example:
Device(config)# ptp priority2 120
Note show ptp parent will not display any output if the device is configured in transparent clock mode.
Grandmaster Clock:
Grandmaster Clock Identity: 0x0:11:1:FF:FE:0:0:1 <<Grandmaster clock
identity to which the device is synced to>>
Grandmaster Clock Quality:
Class: 6
Accuracy: Within 25ns
Offset (log variance): 0
Priority1: 128
Priority2: 128
show platform software fed switch active ptp domain 0
To verify the local servo PTP clock synchronization to Grandmaster clock on a device configured
in boundary mode with delay-request mechanism, use show platform software fed switch active
ptp domain 0 command.
Device# show platform software fed switch active ptp domain 0
Example
show ptp port interface interface-name
To verify PTP port state, use show ptp port interface interface-name command.
To verify the PTP port states on all interfaces use show ptp brief command.
The following is a sample output for boundary mode configuration with delay request mechanism:
Device# show ptp port FortyGigabitEthernet1/0/10
PTP PORT DATASET: FortyGigabitEthernet1/0/10
Port identity: clock identity: 0x0:A3:D1:FF:FE:5A:12:0
Port identity: port number: 10
PTP version: 2
Port state: SLAVE
Delay request interval(log mean): 0
Announce receipt time out: 3
Announce interval(log mean): 1
Sync interval(log mean): 0
Delay Mechanism: End to End
<< PTP mode delay >>
Peer delay request interval(log mean): 0
Sync fault limit: 500000000
show ptp parent
To identify which Grandmaster Clock identity the device is synced to in boundary mode, use show
ptp parent command.
Note show ptp parent will not display any output if the device is configured in transparent clock mode.
Grandmaster Clock:
Grandmaster Clock Identity: 0x0:0:0:5:0:0:0:1
<< GM: External Clock Source acting Grand Master >>
Grandmaster Clock Quality:
Class: 6
Accuracy: Within 1us
Offset (log variance): 0
Priority1: 128
Priority2: 128
Command Purpose
debug ptp bmc Enables debugging of the PTP Best Master Clock
Algorithm.
Cisco IOS XE Fuji 16.8.1a IEEE 1588v2, Precision PTP was developed to synchronize the clocks in
Time Protocol (PTP) packet-based networks that include distributed
support device clocks of varying precisionand stability.
Support for PTP on Layer 2 ports was introduced.
Support for this feature was introduced only on the
9300 switch models of the Cisco Catalyst 9300
Series Switches.
Cisco IOS XE Gibraltar PTP on native Layer 3 Support for PTP on native Layer 3 ports was
16.12.1 ports introduced.
Cisco IOS XE Amsterdam IEEE 1588v2 PTP on Support for PTP on an EtherChannel was
17.2.1 EtherChannel Interfaces introduced.
Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco
Feature Navigator, go to http://www.cisco.com/go/cfn.