Cisco PTP

Configuring Precision Time Protocol (PTP)
• Finding Feature Information, on page 1

• Restrictions and Limitations for PTP, on page 1
• Information About Precision Time Protocol, on page 2
• Examples: Layer 2 and Layer 3 PTP Configurations, on page 17
• Feature History and Information for PTP, on page 21
Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and
feature information, see Bug Search Tool and the release notes for your platform and software release. To
find information about the features documented in this module, and to see a list of the releases in which each
feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support.
To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not
required.
Restrictions and Limitations for PTP

• PTP is supported on the following Catalyst 3850 and Catalyst 3650 SKUs.
• WS-C3650-24PDM
• WS-C3650-48FQM
• WS-C3650-8X24UQ
• WS-C3650-12X48UQ
• WS-C3850-12X48U
• WS-C3850-12XS
• WS-C3850-16XS
• WS-C3850-24XS
• WS-C3850-24XU

1
Information About Precision Time Protocol
• WS-C3850-32XS
• WS-C3850-48XS
• The output of show clock on the device and PTP servo clock displayed in show platform software fed
switch active ptp domain 0 are not synced to each other. These are two different clocks used on the
switch.
• Inter-VLAN is not supported in PTP Transparent Clock Mode.
• PTP is not supported in stacked systems.
• The switch supports IEEE 802.1AS and IEEE 1588 Default profile and they are both mutually exclusive.
Only one profile can be enabled on the switch at a time.
• We do not recommend having non-PTP enabled devices in the PTP network since it decreases clock
synchronization accuracy.
• Management and Signaling messages are not supported in Cisco IOS XE Fuji 16.8.1a. These messages
are dropped in the switch without being processed.
• Moving from one PTP mode to the other is not recommended. Clear the existing mode using no PTP
mode and then configure a new mode.
• IPv6, VRF, Etherchannel interface and native L3 ports are not supported.
Information About Precision Time Protocol

Precision Time Protocol (PTP) is defined in IEEE 1588 as Precision Clock Synchronization for Networked
Measurements and Control Systems, and was developed to synchronize the clocks in packet-based networks
that include distributed device clocks of varying precision and stability. PTP is designed specifically for
industrial, networked measurement and control systems, and is optimal for use in distributed systems because
it requires minimal bandwidth and little processing overhead.
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
Ethernet Switches and Delays

Precision Time Protocol (PTP) is defined in IEEE 1588 as Precision Clock Synchronization for Networked
Measurements and Control Systems, and was developed to synchronize the clocks in packet-based networks
that include distributed device clocks of varying precision and stability. PTP is designed specifically for

2
Message-based Synchronisation
industrial, networked measurement and control systems, and is optimal for use in distributed systems because
it requires minimal bandwidth and little processing overhead.
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. 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.
Note Cisco PTP supports multicast PTP messages only.
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.

3
PTPv2 Message Types
Figure 1: PTP Network
PTPv2 Message Types

PTP messages are categorized into the following two types:
• Event Messages — Event messages are tagged with a timestamp when data packets are reaching or
leaving a port and are used to calculate the link delay based on the timestamps. Event messages are listed
below:
• Sync
• Delay_Req
• Pdelay_Req
• Pdelay_Resp
• 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
Announce messages are used to establish the synchronization hierarchy.

4
PTP Event Message Sequences
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.
• End-to-End Delay Mechanism, on page 5
• Peer-to-Peer Delay Mechanism, on page 6
PTP Event Message Sequences

This section describes the PTP event message sequences that occur during synchronization.
End-to-End Delay Mechanism

The ordinary and boundary clocks configured for the delay request-response mechanism use the following
event messages to generate and communicate timing information:
• Sync
• Delay_Req
• Follow_Up
• Delay_Resp
These messages are sent in the following sequence:
1. The master sends a Sync message to the slave and notes the time (t1) at which it was sent.
2. The slave receives the Sync message and notes the time of reception (t2).
3. The master conveys to the slave the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.
4. The slave sends a Delay_Req message to the master and notes the time (t3) at which it was sent.
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. This assumption is not always valid on an Ethernet
network due to asymmetrical packet delay times.

5
Peer-to-Peer Delay Mechanism
Figure 2: Detailed Steps—End-to-End Delay Mechanism
Peer-to-Peer Delay Mechanism

When the network includes multiple levels of boundary clocks in the hierarchy, with non-PTP enabled devices
between them, synchronization accuracy decreases.
The round-trip time is assumed to be equal to mean_path_delay/2, however this is not always valid for Ethernet
networks. To improve accuracy, the resident time of each intermediary clock is added to the offset in the
end-to-end transparent clock. Resident time, however, does not take into consideration the link delay between
peers, which is handled by peer-to-peer transparent clocks.
Peer-to-peer transparent clocks measure the link delay between two clock ports implementing the peer delay
mechanism. The link delay is used to correct timing information in Sync and Follow_Up messages.
Peer-to-peer transparent clocks use the following event messages:
• Pdelay_Req
• Pdelay_Resp
• Pdelay_Resp_Follow_Up
These messages are sent in the following sequence:
1. Port 1 generates timestamp t1 for a Pdelay_Req message.
2. Port 2 receives and generates timestamp t2 for this message.
3. Port 2 returns and generates timestamp t3 for a Pdelay_Resp message.
To minimize errors due to any frequency offset between the two ports, Port 2 returns the Pdelay_Resp
message as quickly as possible after the receipt of the Pdelay_Req message.

6
Synchronizing the Local Clock
4. Port 2 returns timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.
5. Port 1 generates timestamp t4 after receiving the Pdelay_Resp message. Port 1 then uses the four timestamps
(t1, t2, t3, and t4) to calculate the mean link delay.
Figure 3: Detailed Steps—Peer-to-Peer Delay Mechanism
Synchronizing the Local Clock

In an ideal PTP network, the master and slave clock operate at the same frequency. However, drift can occur
on the network. Drift is the frequency difference between the master and slave clock. You can compensate
for drift by using the time stamp information in the device hardware and follow-up messages (intercepted by
the switch) to adjust the frequency of the local clock to match the frequency of the master clock.
Best Master Clock Algorithm

The Best Master Clock Algorithm (BMCA) is the basis of PTP functionality. The BMCA specifies how each
clock on the network determines the best master clock in its subdomain of all the clocks it can see, including
itself. The BMCA runs locally on each port in the network continuously for every Announce interval and
quickly adjusts for changes in network configuration. BMCA based on IEEE 1588-2008 uses Announce
messages for advertising clock properties.
The BMCA uses the following criteria to determine the best master clock in the subdomain:
• Clock quality (for example, GPS is considered the highest quality)
• Clock accuracy of the clock’s time base
• Stability of the local oscillator
• Closest clock to the grandmaster
BMCA based on IEEE 1588-2008 uses own data set with the received data set to determine the best clock
based on the attributes with the following properties, in the indicated order:

7
PTP Clocks
• Priority1 - User-assigned priority to each clock. The range is from 0 to 255. The default value is 128.
• Class - Class to which the a clock belongs to, each class has its own priority
• Accuracy - Precision between clock and UTC, in nanoseconds
• Variance - Variability of the clock
• 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.

8
PTP Profiles
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

9
Default Profile
• 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.
Configuring PTP Default Profile

To configure Layer 2 PTP globally, follow these steps:
Procedure
Command or Action Purpose

Step 1 enable Enables privileged EXEC mode.
Example: Enter your password if prompted.
Device> enable
Step 2 configure terminal Enters global configuration mode.

Example:
Device configure terminal
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

10
Configuring Layer 3 PTP Default Profile

• 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.
• p2ptransparent — mode where the switch
does not synchronize its clock with the
master clock. A switch in this mode does
not participate in master clock selection
and uses the default PTP clock mode on
all ports.
Note Once PTP default profile is enabled

globally on the device, PTP is
enabled on all the interfaces. To
disable PTP selectively on individual
interfaces, use no ptp enable
command under interface
configuration.
Step 4 [no]ptp domain value Configures the domain value on PTP.

Example: • A single domain value can be set. The
Device(config)# ptp domain 8 range is from 4 to 127. The default value
is 0. No ptp domain command will set the
value to default.

To configure Layer 3 PTP globally, follow these steps:
Procedure

Device> enable

Example:
Device# configure terminal

11

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.
Step 4 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.
• p2ptransparent — mode where the
switch does not synchronize its clock with
the master clock. A switch in this mode
does not participate in master clock
selection and uses the default PTP clock
mode on all ports.
Once PTP default profile is enabled globally

on the device, PTP is enabled on all the
interfaces. To disable PTP selectively on
individual interfaces, use no ptp enable
command under interface configuration.
Within PTP default profile, PTP messages are
processed in VLAN 1 by default. Use ptp vlan
vlan-name command under interface

12

configurations to allow PTP message
processing on specific VLAN. You must add
this to the VLAN database of the device.
Step 5 interface vlan vlan-id Specifies the VLAN or SVI interface to be

configured, and enters interface configuration
Example:
mode.
Device(config)# interface vlan2
Note Layer 3 PTP is supported only on
VLAN and SVI interfaces.
Step 6 ip address ip-address subnet-mask Configures the IP address and IP subnet.

Example:
Device(config)# ip address 100.1.1.1
255.255.255.0
Step 7 interface interface-id Specifies the physical interface to be

configured, and enters interface configuration
Example:
mode.
Device(config)# interface
TenGigabitEthernet1/0/1
Step 8 switchport mode { access | trunk } Sets the interface type : Access or trunk.
Example: • access — Sets the interface as a
Device(config-if)# switchport mode trunk nontrunking nontagged single-VLAN
interface. An access port can carry traffic
in one VLAN only. By default, an access
port carries traffic for VLAN1; to set the
access port to carry traffic for a different
VLAN, use the switchport access vlan
command in Step 8.
• trunk — Sets the interface as an Ethernet
trunk port. A trunk port can carry traffic
in one or more VLANs on the same
physical link (VLANs are based on the
trunk-allowed VLANs list). By default,
a trunk interface can carry traffic for all
VLANs. To specify that only certain
VLANs are allowed on the specified
trunk, use the switchport trunk allowed
vlan command in Step 9.
Note If switchport mode is trunk,
you should configure PTP
VLAN using the ptp vlan
vlan-id command.
Step 9 switchport access vlan vlan-id Specifies the VLAN for which this access port
will carry traffic. If you do not enter this
Example:

13
Disabling PTP on an inteface

Device(config-if)# switchport access command, the access port carries traffic on
vlan 5 VLAN1 only; use this command to change the
VLAN for which the access port carries traffic.
Step 10 switchport trunk allowed vlan {{ add | Sets allowed VLANs for the trunk interface.
except | remove } vlan_list | all | none } The default is to allow all VLANs on the trunk
interface: 1 to 3967 and 4048 to 4094. VLANs
Example:
3968 to 4047 are the default VLANs reserved
Device(config-if)# switchport trunk for internal use by default; this group of
allowed vlan 2,10
VLANs is configurable. By default, all VLANs
are allowed on all trunk interfaces.
Step 11 ptp vlan vlan-id Sets the PTP VLAN on a trunk port. The range
is from 1 to 4094. The default is the native
Example:
VLAN of the trunk port. In boundary mode,
Device(config-if)# ptp vlan 5 only PTP packets in PTP VLAN will be
processed, PTP packets from other VLANs
will be dropped. Before configuring the PTP
VLAN on an interface, the PTP VLAN must
be created and allowed on the trunk port.
Step 12 end Returns to privileged EXEC mode.

Example:
Device(config-if)# end
Disabling PTP on an inteface

PTP is enabled on all the ports, by default. To disable PTP on an interface, follow these steps:
Procedure

Device> enable

Example:
Step 3 interface interface-id Specifies the physical port to be configured,

and enters interface configuration mode.
Example:
gigabitethernet2/0/1

14
Configuring PTP Timers

Step 4 [ no ] ptp enable To disable PTP, use the no form of this
command.
Example:
Device(config-if)# no ptp enable

Example:
Configuring PTP Timers

To change the PTP timer values from default to required values, follow these steps:
Procedure

Device> enable

Example:
Step 3 interface interface-id Specifies the physical port to be configured,

and enters interface configuration mode.
Example:
gigabitethernet2/0/1
Step 4 ptp announce {interval seconds | timeout (Optional) Configures the interval between PTP
count} announce messages on an interface or the
number of PTP intervals before a timeout occurs
Example:
on an interface.
Device(config-if)# ptp announce interval
1 • interval seconds — Sets the logarithmic
mean interval in seconds to send announce
messages. The range is 0 to 4. The default
is 1 (2 seconds).
• 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).

15
Configuring the values of PTP clocks

Step 5 ptp sync {interval seconds | limit offset-value} (Optional) Configures the interval between PTP
synchronization messages on an interface.
Example:
Device(config-if)# ptp sync interval 1 • interval seconds — Sets the logarithmic
mean interval in seconds to send
synchronization messages. The range is
–3 to 1. The default is 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 seconds (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 -1 to 1. The default is 0 (1 second).
1
Step 7 ptp pdelay-req interval seconds (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 -1 to 1. The default is 0 (1 second).
interval 1

Example:
Configuring the values of PTP clocks

You can configure the values of ptp clock priority1 and priority2 using the commands below:
Procedure

Device> enable

Example:
Step 3 ptp priority1 value Configure the values of ptp clock priority1. The
range is 0 to 255. The default value is 128.
Example:

16
Examples: Layer 2 and Layer 3 PTP Configurations

Device(config)# ptp priority1 120 Note If the value of priority1 is configured
to 255, the clock cannot become as
Grandmaster.
Step 4 ptp priority2 value Configure the values of ptp clock priority2. The
range is 0 to 255. The default value is 128.
Example:
Device(config)# ptp priority2 120
Step 5 exit Returns to global configuration mode.

Example:
Device(config)# exit

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 GigabitEthernet1/0/45
PTP PORT DATASET: GigabitEthernet1/0/45
Port identity: clock identity: 0xCC:46:D6:FF:FE:C5:24:0
Port identity: port number: 45
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
Peer delay request interval(log mean): 0
Sync fault limit: 500000000
The following is a sample output for boundary mode configuration with pdelay request mechanism:
Device# show ptp port GigabitEthernet1/0/45
PTP PORT DATASET: GigabitEthernet1/0/45
Port identity: clock identity: 0xCC:46:D6:FF:FE:C5:24:0
PTP version: 2
Port state: MASTER

17

Delay Mechanism: Peer to Peer
show ptp brief
The following is a sample output for show ptp brief command:
Device# show ptp brief
Interface Domain PTP State
TenGigabitEthernet1/0/1 0 MASTER
TenGigabitEthernet1/0/2 0 SLAVE
TenGigabitEthernet1/0/3 0 FAULTY
show ptp clock
To verify the PTP clock identity details and to verify the configured values of Priority1 and Priority2,
use show ptp clock command.
The following is a sample output for show ptp clock command:
Device# show ptp clock
PTP CLOCK INFO
PTP Device Type: Boundary clock
PTP Device Profile: Default Profile
Clock Identity: 0xCC:46:D6:FF:FE:C5:24:0 <<clock identity of this
switch>>
Clock Domain: 0
Number of PTP ports: 52
Priority1: 128
Priority2: 128
Clock Quality:
Class: 248
Accuracy: Unknown
Offset (log variance): 16640
Offset From Master(ns): 0
Mean Path Delay(ns): 0
Steps Removed: 1
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.
The following is a sample output for show ptp parent command:

Device# show ptp parent
PTP PARENT PROPERTIES
Parent Clock:
Parent Clock Identity: 0x0:11:1:FF:FE:0:0:1

18
Parent Port Number: 1

Observed Parent Offset (log variance): 16640
Observed Parent Clock Phase Change Rate: N/A
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
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
Displaying data for domain number 0

============================
Profile Type : DEFAULT

Profile State: enabled
Clock Mode : BOUNDARY CLOCK
Delay mechanism: End-to-End
PTP clock : 2017-6-28 5:58:59
Transport Method: L2 Ethernet
By default, local servo PTP clock will be displaying EPOCH time(1970-1-1) when the device is not
synced to any PTP Grandmaster Clock.
Example
show ptp port interface interface-name
To verify PTP port state, use show ptp port interface interface-name 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
PTP version: 2
Port state: SLAVE

19
Delay Mechanism: End to End

<< PTP mode delay >>
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.
The following is a sample output for show ptp parent command:

Device# show ptp parent
PTP PARENT PROPERTIES
Parent Clock:
Parent Clock Identity: 0x38:E:4D:FF:FE:81:FE:29
<< Immediate next Master >>
Parent Port Number: 196
Observed Parent Offset (log variance): 17258
Observed Parent Clock Phase Change Rate: N/A
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
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
Displaying data for domain number 0
=======================================
Profile Type : DEFAULT

Profile State: enabled
Clock Mode : BOUNDARY CLOCK
Delay Mechanism: : END-TO-END
PTP clock : 2017-12-15 15:27:27
mean_path_delay 214 nanoseconds
Transport Method : udp-ipv4 << PTP Transport Method
>>

20
Feature History and Information for PTP
Table 1: Debug Commands
Command Purpose
debug ptp messages Enables debugging of PTP messages.
debug ptp error Enables debugging of PTP errors.
debug ptp bmc Enables debugging of the PTP Best Master Clock
Algorithm.
debug ptp event Enables debugging of PTP state event.

The following table provides release information about the feature or features described in this module. This
table lists only the software release that introduced support for a given feature in a given software release
train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Releases Modification
Cisco IOS XE Fuji 16.8.1 Support for PTP on Layer 2 was enabled.
Cisco IOS XE Gibraltar 16.12.1 Support for PTP on native L3 ports was introduced.

21

22

Cisco PTP

Uploaded by

Copyright:

Available Formats

Cisco PTP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco PTP

Uploaded by

Copyright:

Available Formats

Configuring Precision Time Protocol (PTP)

• Finding Feature Information, on page 1

Finding Feature Information

Restrictions and Limitations for PTP

Configuring Precision Time Protocol (PTP)

Information About Precision Time Protocol

Ethernet Switches and Delays

Configuring Precision Time Protocol (PTP)

Note Cisco PTP supports multicast PTP messages only.

Configuring Precision Time Protocol (PTP)

Figure 1: PTP Network

PTPv2 Message Types

Announce messages are used to establish the synchronization hierarchy.

Configuring Precision Time Protocol (PTP)

PTP Event Message Sequences

End-to-End Delay Mechanism

Configuring Precision Time Protocol (PTP)

Figure 2: Detailed Steps—End-to-End Delay Mechanism

Peer-to-Peer Delay Mechanism

Configuring Precision Time Protocol (PTP)

Synchronizing the Local Clock

Best Master Clock Algorithm

Configuring Precision Time Protocol (PTP)

Configuring Precision Time Protocol (PTP)

Configuring Precision Time Protocol (PTP)

• Path delay mechanisms (peer delay or delay request-response)

Configuring PTP Default Profile

Command or Action Purpose

Step 2 configure terminal Enters global configuration mode.

Configuring Precision Time Protocol (PTP)

Command or Action Purpose

Note Once PTP default profile is enabled

Step 4 [no]ptp domain value Configures the domain value on PTP.

Configuring Layer 3 PTP Default Profile

Command or Action Purpose

Step 2 configure terminal Enters global configuration mode.

Configuring Precision Time Protocol (PTP)

Command or Action Purpose

Once PTP default profile is enabled globally

Configuring Precision Time Protocol (PTP)

Command or Action Purpose

Step 5 interface vlan vlan-id Specifies the VLAN or SVI interface to be

Step 6 ip address ip-address subnet-mask Configures the IP address and IP subnet.

Step 7 interface interface-id Specifies the physical interface to be

Configuring Precision Time Protocol (PTP)

Command or Action Purpose

Step 12 end Returns to privileged EXEC mode.

Disabling PTP on an inteface

Command or Action Purpose

Step 2 configure terminal Enters global configuration mode.

Step 3 interface interface-id Specifies the physical port to be configured,

Configuring Precision Time Protocol (PTP)

Command or Action Purpose

Step 5 end Returns to privileged EXEC mode.

Configuring PTP Timers

Command or Action Purpose

Step 2 configure terminal Enters global configuration mode.

Step 3 interface interface-id Specifies the physical port to be configured,

Configuring Precision Time Protocol (PTP)