Configuring PTP
This document describes Precision Time Protocol (PTP) and how to configure it on the Cisco Industrial Ethernet 4000 Series Switch (IE 4000), Cisco Industrial Ethernet 4010 Series Switch (IE 4010), and Cisco Industrial Ethernet 5000 Series Switch (IE 5000). This document uses the term switch to refer to these platforms.
This document also describes the Network Time Protocol (NTP) to PTP conversion feature and how to configure it on the IE 4000, IE 4010, and IE 5000.
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.
 Note |
The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. In this document, the terms Grandmaster clock (GMC) or time source and time recipient are used instead of the traditional Master/Slave nomenclature. |
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
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).
Note |
Message-Based Synchronization
To ensure clock synchronization, PTP requires an accurate measurement of the communication path delay between time source (grandmaster clock) and the time recipient. PTP sends messages between the time source and time recipient to determine the delay measurement. 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 time source and time recipient devices. 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 time source and time recipient 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. |
To read a detailed description of synchronization messages, refer to PTP Event Message Sequences. To learn more about how transparent clocks calculate network delays, refer to Transparent Clock.
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, Time Source 1 is the grandmaster clock. If Time Source 1 becomes unavailable, the time recipient boundary clocks switch to Time Source 2 for synchronization.
PTP Event Message Sequences
This section describes the PTP event message sequences that occur during synchronization.
Synchronizing with Boundary Clocks
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:
-
The time source sends a Sync message to the time recipient and notes the time t1 at which it was sent.
-
The time recipient receives the Sync message and notes the time of reception t2.
-
The time source conveys to the time recipient the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.
-
The time recipient sends a Delay_Req message to the time source and notes the time t3 at which it was sent.
-
The time source receives the Delay_Req message and notes the time of reception t4.
-
The time source conveys to the time recipient the timestamp t4 by embedding it in a Delay_Resp message.
After this sequence, the time recipient possesses all four timestamps. These timestamps can be used to compute the offset of the time recipient clock relative to the time source, 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 time source to time recipient is the same as the time required from time recipient to time source. This assumption is not always valid on an Ethernet network due to asymmetrical packet delay times.
Synchronizing with Peer-to-Peer Transparent Clocks
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:
-
Port 1 generates timestamp t1 for a Pdelay_Req message.
-
Port 2 receives and generates timestamp t2 for this message.
-
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.
-
Port 2 returns timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.
-
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.
Synchronizing the Local Clock
In an ideal PTP network, the time source and time recipient clocks operate at the same frequency. However, drift can occur on the network. Drift is the frequency difference between the time source and time recipient clocks. 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 time source 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 time source clock in its subdomain of all the clocks it can see, including itself. The BMCA runs on the network continuously and quickly adjusts for changes in network configuration.
The BMCA uses the following criteria to determine the best time source 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
In addition to identifying the best time source 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 time source clocks or no time source clocks, as a result of the time source clock identification process
PTP Clocks
A PTP network is made up of PTP-enabled devices and devices that are not using PTP. 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.
The switch can function as a hybrid grandmaster boundary clock using NTP as its source. For more information, see NTP to PTP Time Conversion.
Ordinary Clock
An ordinary clock is a PTP clock with a single PTP port. It functions as a node in a PTP network. 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 to non-master mode. The master port synchronizes the clocks connected downstream, while the non-master 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 time recipient uses this information when determining the offset between the time recipient’s and the time source'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 time recipient contains the sum of all link delays. In theory, this is the total end-to-end delay (from time source to time recipient) of the SYNC packet.
The following figure illustrates PTP clocks in a time source-time recipient hierarchy within a PTP network.
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
-
Transport mechanisms that are required, permitted, or prohibited
-
Node types that are required, permitted, or prohibited
-
Options that are required, permitted, or prohibited
The following PTP profiles are available on the switch:
-
Default Profile
-
Power Profile (C37.238-2011/IEC 61850-9-3 support)
-
802.1AS Profile (IE 4000 only)
-
Extended Power Profile (IEEE C37.238-2017 support—Transparent clock mode only)
Default Profile Mode
The default PTP profile mode on the switch is Default Profile mode. In this mode:
-
The PTP mode of transport is Layer 3.
-
The supported transparent clock mode is end-to-end (E2E).
Table 1 lists the configuration values for the switch in Default Profile mode.
Power Profile Mode
The Power Profile is defined in C37.238-2011 - IEEE Draft Standard Profile for Use of IEEE 1588 Precision Time Protocol in Power System Applications. This switch documentation uses the terms Power Profile mode and Default Profile mode when referring to this IEEE 1588 profile and its associated configuration values.
The IEEE Power Profile defines specific or allowed values for PTP networks used in power substations. The defined values include the optimum physical layer, the higher level protocol for PTP messages, and the preferred best master clock algorithm. The Power Profile values ensure consistent and reliable network time distribution within substations, between substations, and across wide geographic areas.
The switch is optimized for PTP in these ways:
-
Hardware—The switch uses FPGA and PHY for the PTP function. The PHY time stamps the Fast Ethernet and Gigabit Ethernet ports.
-
Software—In Power Profile mode, the switch uses the configuration values defined in the IEEE 1588 Power Profile standard.
The following table lists the configuration values defined by the IEEE 1588 Power Profile and the values that the switch uses for each PTP profile mode.
|
PTP Field |
Power Profile Value |
Switch Configuration Value |
|
|---|---|---|---|
|
Power Profile Mode |
Default Profile Mode |
||
|
Message transmission |
Ethernet 802.3 with Ethertype 0X88F7. PTP messages are sent as 802.1Q tagged Ethernet frames with a default VLAN 0 and default priority 4. |
Access Ports –Untagged Layer 2 packets. Trunk Ports –802.1Q tagged Layer 2 packets with native VLAN on the port and default priority value of 4. |
Layer 3 packets. By default, 802.1q tagging is disabled. |
|
MAC address– Non-peer delay messages |
01-1B-19-00-00-00. |
01-1B-19-00-00-00. |
01-1B-19-00-00-00. |
|
MAC address– Peer delay messages |
01-80-C2-00-00-0E. |
01-80-C2-00-00-0E. |
Not applicable to this mode. |
|
Domain number |
0. |
0. |
0. |
|
Path delay calculation |
Peer-to-peer transparent clocks. |
Peer-to-peer transparent clocks using the peer_delay mechanism. |
End-to-end transparent clocks using the delay_request mechanism. |
|
BMCA |
Enabled. |
Enabled. |
Enabled. |
|
Clock type |
Two-step clocks are supported. |
Two-step. |
Two-step. |
|
Time scale |
Epoch.1 |
Epoch. |
Epoch. |
|
Grandmaster ID and local time determination |
PTP-specific TLV (type, length, value) to indicate Grandmaster ID. |
PTP-specific TLV to indicate Grandmaster ID. |
PTP-specific type, length, and value to indicate Grandmaster ID. |
|
Time accuracy over network hops |
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
Not applicable in this mode. |
Extended Power Profile
The Extended Power Profile supports C37.238-2017 in Transparent clock mode.
The Extended Power Profile has the following characteristics, in comparison with the Power profile (C37.238-2011):
-
This profile uses domain-number 254 by default.
-
The Transparent clock mode operation increments the "TotalTimeInAccuracy" by approximately 50ns by each node.
802.1AS Profile (IE 4000 only)
Note |
The 802.1AS Profile is supported for the IE 4000 only. |
The IEEE 802.1AS standard "Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks" specifies the protocol and procedures used to ensure that synchronization requirements are met for time-sensitive applications across bridged and virtual bridged local area networks.
802.1AS specifies the use of IEEE 1588 (PTP) specifications where applicable in the context of IEEE Std 802.1D -2004 and IEEE Std 802.1Q -2005.1. The 802.1AS standard is one of three 802.1 AVB draft standards. 802.1AS over Ethernet (802.3) qualifies as a Profile of IEEE 1588-2008. It simplifies IEEE 1588 and defines synchronization over different types of media.
Key characteristics of 802.1AS are:
-
For Ethernet full-duplex links, it uses the peer delay mechanism.
-
All switches in the domain need to be 802.1AS capable.
-
Transportation of 802.1AS packets is L2 multicast only, with no VLAN tag.
-
It requires two-step processing (use of Follow_Up and Pdelay_Resp_Follow_Up messages to communicate timestamps).
-
There is only a single active grandmaster in a time-aware network. That is, there is only a single 802.1AS domain.
-
The BMCA (Best Master Clock Algorithm) is same as that used in IEEE 1588 with the following exceptions:
-
Announce messages received on a time recipient port that were not sent by the receiving time-aware system are used immediately; that is, there is no foreign-time source qualification.
-
A port that the BMCA determines should be a time source port enters the time source state immediately; that is, there is no pre-time source state.
-
The uncalibrated state is not needed and therefore not used.
-
All time-aware systems are required to participate in best master selection (even if the system is not grandmaster capable).
-
802.1AS on the IE 4000
On the IE 4000, 802.1AS is used in the Time Sensitive Network (TSN) feature. However, as a precise timing distribution mechanism, 802.1AS runs by itself without TSN configuration or inputs. The 802.1AS feature software implementation is based on the existing time stamping functionality of FPGA and has no new requirement on hardware beyond other PTP profiles.
The end-to-end time-synchronization performance of 802.1AS on the IE 4000 is as follows:
-
Any two time-aware systems separated by six or fewer time-aware systems (that is, seven or fewer hops) will be synchronized to within 1 μs peak-to-peak of each other during steady-state operation.
-
Performance beyond 7 hops is not defined.
PTP Profile Comparison
|
Profile |
Default (*) |
Power |
802.1AS |
||
|---|---|---|---|---|---|
|
Standard |
IEEE1588 v2 (J.3) |
IEEE C37.238-2011 |
IEEE802.1AS |
||
|
Mode |
Boundary |
End-to-End transparent |
Boundary |
Peer-to-Peer transparent |
** |
|
Path Delay |
Delay req/res |
Delay req/res |
Peer delay req/res |
Peer delay req/res |
Peer delay req/res |
|
Non-PTP device allowed in PTP domain |
Yes |
Yes |
No |
No |
No |
|
Transport |
UDP over IP (multicast and unicast) |
L2 Multicast |
L2 Multicast |
||
* Delay Request-Response Default PTP profile (as defined in IEEE1588 J.3).
** There is no mode setting for 802.1AS. Mathematically it is equivalent to P2P transparent, but it works differently from a transparent clock.
Tagging Behavior for PTP Packets
The following table describes the switch tagging behavior in Power Profile and Default Profile modes.
|
Switch Port Mode |
Configuration |
Power Profile Mode |
Default Profile Mode |
||
|---|---|---|---|---|---|
|
Behavior |
Priority |
Behavior |
Priority |
||
|
Trunk Port |
vlan dot1q tag native enabled |
Switch tags packets |
7 |
Switch tags packets |
7 |
|
Trunk Port |
vlan dot1q tag native disabled |
PTP software tags packets |
4 |
Untagged |
None |
|
Access Port |
N/A |
Untagged |
None |
Untagged |
None |
PTP Clock Modes Supported on the Switch
PTP synchronization behavior depends on the PTP clock mode that you configure on the switch. You can configure the switch for one of the following global modes.
See Guidelines and Limitations for guidelines for configuring each of the clock modes.
Grandmaster-Boundary Clock Mode
The switch can function as a hybrid grandmaster boundary clock using NTP as its source. For more information, see NTP to PTP Time Conversion.
Boundary Clock Mode
A switch configured for boundary clock mode participates in selecting the best time source clock on the subdomain, selecting from all clocks it can see, including itself. If the switch does not detect a more accurate clock than itself, then the switch becomes the time source clock. If a more accurate clock is detected, then the switch synchronizes to that clock and becomes a time recipient clock.
After initial synchronization, the switch and the connected devices exchange PTP timing messages to correct the changes caused by clock offsets and network delays.
Forward Mode
A switch configured for forward mode passes incoming PTP packets as normal multicast traffic.
E2E and P2P Transparent Clock Modes
Transparent clocks synchronize their local clocks to the GMC by snooping the Sync messages. They do not participate in the best master clock algorithm. Transparent clocks use the default PTP clock mode on all ports.
Configurable Boundary Clock Synchronization Algorithm
You can configure the BC synchronization algorithm to accommodate various PTP use cases, depending on whether you need to prioritize filtering of input time errors or faster convergence. A PTP algorithm that filters packet delay variation (PDV) converges more slowly than a PTP algorithm that does not.
By default, the BC uses a linear feedback controller (that is, a servo) to set the BC's time output to the next clock. The linear servo provides a small amount of PDV filtering and converges in an average amount of time. For improved convergence time, BCs can use the TC feedforward algorithm to measure the delay added by the network elements forwarding plane (the disturbance) and use that measured delay to control the time output.
While the feedforward BC dramatically speeds up the boundary clock, the feedforward BC does not filter any PDV. The adaptive PDV filter provides high quality time synchronization in the presence of PDV over wireless access points (APs) and enterprise switches that do not support PTP and that add significant PDV.
Three options are available for BC synchronization (all are compliant with IEEE 1588-2008):
-
Feedforward—For very fast and accurate convergence; no PDV filtering.
-
Adaptive—Filters as much PDV as possible, given a set of assumptions about the PDV characteristics, the hardware configuration, and the environmental conditions.
Note
With the adaptive filter, the switch does not meet the time performance requirements specified in ITU-T G.8261.
-
Linear—Provides simple linear filtering (the default).
Adaptive mode (ptp transfer filter adaptive ) is not available in Power Profile mode.
For configuration information, see Configuring PTP on the Switch.
NTP to PTP Time Conversion
NTP to PTP Time Conversion allows you to use Network Time Protocol (NTP) as a time source for PTP. Customers who use PTP for very precise synchronization within a site can use NTP across sites, where precise synchronization is not required.
NTP is the traditional method of synchronizing clocks across packet based networks. NTP uses a two-way time transfer mechanism, between a time source and an end device. NTP is capable of synchronizing a device within a few 100 milliseconds across the Internet, and within a few milliseconds in a tightly controlled LAN. The ability to use NTP as a time source for PTP allows customers to correlate data generated in their PTP network with data in their enterprise data centers running NTP.
The following figure shows an example of an industrial network based on the Industrial Automation and Control System Reference Model. The enterprise zone and demilitarized zone run NTP, and the manufacturing zone and cell/area zone run PTP with NTP as the time source. The switch with the NTP to PTP conversion feature can be either the Layer 2 Switch or the Distribution Switch in the Cell/Area Zone.
Grandmaster Boundary Clock Hybrid
The NTP to PTP conversion feature adds grandmaster clock functionality to Cisco PTP, so the switch can be a time source as well as forward time. A new PTP clock type, grandmaster boundary clock (GMC-BC), provides the NTP time source for PTP. The GMC-BC acts like a BC, which is a multi-port device, with a single-port GMC connected to a virtual port on the BC. The GMC-BC switches between acting like a GMC when the GMC-BC is the primary GMC, and acting like a BC when the GMC-BC is a backup. This ensures that all devices on the PTP network remain synchronized in a failover scenario. The following figure shows a PTP network with redundant GMC-BCs. GMC-BC 1 is the grandmaster clock, and GMC-BC 2 is both backup GMC and BC.
In a network with two GMC-BCs, the secondary GMC-BC can synchronize to both the NTP reference and the PTP reference at the same time, so the secondary GMC-BC can immediately take over when the primary GMC-BC fails. The GMC-BC instantly updates the time during a switchover.
Clock Manager
The clock manager is the component in the Cisco NTP to PTP software architecture that keeps track of the various time services and selects the clock that actively provides time. The clock manager notifies the time services of important changes, such as state changes, leap seconds, or daylight saving time.
The clock manager selects the NTP or manually-set clock first, followed by PTP and the real-time clock if NTP is not active. The following table shows the results of the clock selection process.
|
NTP (Active) or Manually Set |
PTP (Active) |
Real-Time Clock |
Selected Output |
|---|---|---|---|
|
True |
Don’t care |
Don’t care |
NTP or Manually Set |
|
False |
True |
Don’t care |
PTP |
|
False |
False |
True |
Real-Time Clock |
In general, the clock manager ensures that the time displayed in the Cisco IOS commands show ptp clock and show clock match. The show clock command always follows this priority, but there are two corner cases where the show ptp clock time may differ:
-
The switch is either a TC or a BC, and there is no other active reference on the network. To preserve backwards compatibility, the TC and BC never take their time from the clock manager, only from the network’s PTP GMC. If there is no active PTP GMC, then the time displayed in the show clock and the show ptp clock command output may differ.
-
The switch is a syntonizing TC, a BC with a slave port, or a GMC-BC with slave port, and the time provided by the PTP GMC does not match the time provided by NTP or the user (that is, manually set). In this case, the PTP clock must forward the time from the PTP GMC. If the PTP clock does not follow the PTP GMC, then the PTP network will end up with two different time bases, which would break any control loops or sequence of event applications using PTP.
The following table shows how the Cisco IOS and PTP clocks behave given the various configurations. Most of the time, the two clocks match. Occasionally, the two clocks are different; those configurations are highlighted in the table.
|
IOS Clock Configuration |
PTP Clock Configuration |
IOS Clock Source |
PTP Clock Source |
|---|---|---|---|
|
Calendar |
PTP BC, E2E TC, or GMC-BC in BC Mode |
PTP |
PTP |
|
Manual |
PTP BC, E2E TC, or GMC-BC in BC Mode |
Manual |
PTP |
|
NTP |
PTP BC, E2E TC, or GMC-BC in BC Mode |
NTP |
PTP |
|
Calendar |
GMC-BC in GM Mode |
Calendar |
Calendar |
|
Manual |
GMC-BC in GM Mode |
Manual |
Manual |
|
NTP |
GMC-BC in GM Mode |
NTP |
NTP |
GMC Block
GMC Block protects an existing network from any rogue GMC that might try to synchronize with the devices inside the network. This feature is supported for all PTP clock modes except Forward mode. After the feature is enabled on an interface, only the egress Announce, Sync, and Followup PTP packets are allowed and all ingress Announce, Sync, and Followup packets are dropped on this interface. This prevents the port state transition to time recipient.
Information about a rogue GMC is retrieved from the packets before dropping them. However, egress PTP packets are still allowed from this interface, so it can act as a GMC. To identify the rogue device, details such as IP address and clock ID are stored and displayed for the interface. Two Syslog messages are also generated to notify the presence and clearance of rogue devices.
You can configure PTP gmc-block on multiple ports, if you suspect multiple foreign networks are connected to your existing system. Per-port Syslog messages are displayed after an interval of 30 seconds of receiving rogue packets and after 180 -240 seconds when packets stop coming. Relay minor alarms and SNMP traps are also generated to notify of the presence of foreign rogue devices.
Packet Flow
The following figure shows an example of a PTP network topology with the GMC Block feature configured on an interface.
PTP packets originate in the GMC of the foreign network in an attempt to sync with the existing network. When the PTP packets reach the port configured with GMC Block, the packets are dropped after the system retrieves the required information from them.
Because packets from the foreign network are restricted, the system syncs with the local GMC present in the existing system. PTP packets originated on the port configured with GMC Block are still allowed to egress from this interface, which allows devices in the existing network to be GMC.PTP over Port Channels
PTP in Transparent Clock (TC) mode and Boundary Clock (BC) mode works seamlessly over Port Channel interfaces without additional configuration.
For aggregrate links, the PTP profile standard recommends direct access of a physical link, bypassing the link aggregation algorithm so that the same member link is used for all PTP packets. The objective of PTP transport over parallel redundant member links of an aggregate port is to maintain PTP and link aggregation standards while avoiding PTP packet redundancy and providing redundancy of the aggregate port. To allow the Port Channel interface to be seen as any other regular physical interface on the switch, the PTP over Port Channels feature uses the PTP state derived by the BMCA, similar to the Boundary Clock (BC) mode implementation. In BC mode, all the parallel redundant ports on the Time Recipient end of the Port Channel are transitioned to PASSIVE state and do not process or send out PTP messages.
The following diagram shows part of the full topology of a PTP network where all nodes are TC nodes. A PTP message is initiated by the GMC (not shown in the diagram), which may or may not be directly connected to the TC Time Source switch, and flows through the Port Channel towards the Ordinary Clock (OC, or the end PTP consumer node). The Reply messages flow in the opposite direction. Possible topologies can be as follows:
GMC ---------- TC (Time Source) -------- TC (Time Recipient)----------- OC
or
GMC ---------- BC ----------- TC (Time Source) -------- TC (Time Recipient)----------- OC
To use the PTP state for member link selection, the BMCA runs in Transparent Mode as well as Boundary clock mode. PTP states are maintained internally to discard packets arriving on member links in the PASSIVE state. The switch towards the GMC is unaware of the member link selection and therefore continues to send PTP messages on all the member links.
You can disable PTP on some of the Port Channel member links to reduce the duplicate PTP messages sent from the time source end of the Port Channel interface. This would also help in interoperating with other vendor switches that use only user-configured member links for PTP transport. For example:
Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#interface GigabitInterface1/3
Switch(config-if)#channel-group 5 mode on
Switch(config-if)#no ptp enable
Switch(config-if)#exit
Switch(config)#interface GigabitInterface1/4
Switch(config-if)#channel-group 5 mode on
Switch(config-if)#no ptp enable
Switch(config-if)#end
Switch#
The switch in Transparent mode syntonizes its clock to the GMC. For example:
Switch#show ptp time-property
PTP CLOCK TIME PROPERTY
Clock Syntonized: TRUE
Domain Syntonized: FALSE
Scaled Fractional Frequency Offset: Unknown
Switch#
PTP performance is measured and is comparable to standalone links.
The BMCA Port State in Transparent Clock mode is shown in the output of the show ptp internal-info command. To aid in troubleshooting, the PTP over port channels feature adds the following for Transparent Clock mode:
-
Syslog and SNMP trap when the PTP Transparent Clock node loses synchronization with the GMC.
-
Local port information for which node is syntonized to the GMC in the show ptp command.
Note |
PTP over port channels is supported with Horizontal Stacking. For information about PTP and Horizontal Stacking, see PTP over Horizontal Stacking. |
PTP over Horizontal Stacking
IEEE 1588v2 PTP Default Profile, Power Profile (C37.238-2011), and Extended Power Profile (C37.238-2017) are supported in both Standalone mode and in Horizontal Stack mode on the IE 5000. PTP on an IE 5000 in a horizontal stacked configuration works transparently so that all the other devices and switches connecting to the IE 5000 are not aware of the horizontal stack. The PTP over Horizontal Stacking feature provides the same PTP behavior for standalone and horizontal stacked IE 5000 switches, with the benefit of High Availability if one of the switches goes down in a horizontal stack.
Note |
For information about Horizontal Stacking on the IE 5000, see Horizontal Stacking Software Configuration Guide for IE 5000 Switches. |
The topology diagram above shows a 1588 PTP over horizontal stacking network that includes grandmaster clocks, horizontal stacked switches in Boundary/Transparent clock mode, PTP peer devices, and end points such as PLCs, digital relays, and so on. In this diagram, Master 1 is the grandmaster clock. If Master 1 becomes unavailable, the PTP time recipient devices connected to horizontal stacked switches switch over to Master 2 for synchronization. The grandmaster clocks, PTP peer devices, and end points can be connected to any switch (that is, stack master or stack member) in the horizontal stack.
In a horizontal stack, all switches appear as a single logical switch. For PTP, all switches in the stack use the same “clock identity” value in PTP messages and therefore appear as a single logical switch to the PTP peer devices. The “clock identity” value is derived from the base MAC address of the stack master.
All the existing functionalities of PTP in a standalone switch are also supported in horizontal stacking with the below limitations:
-
PTP over horizontal stacking is supported on a maximum stack size of 3 switches.
-
GPS should be connected to the horizontal stack master.
-
IRIG input/output is not supported in horizontal stack mode.
Any of the stacked switches can be GMC and any can use the Default and Power Profiles. The clock modes supported for PTP over Horizontal Stacking are as follows:
-
Default Profile
-
Boundary Clock
-
E2E Transparent Clock
-
-
Power Profile
-
Boundary Clock
-
P2P Transparent Clock
-
-
Extended Power Profile (C37.238-2017)
-
P2P Transparent Clock
-
-
GMC-BC
-
GPS (GPS on stack master)
-
NTP
-
IRIG (not supported)
-
Guidelines and Limitations
PTP Messages
-
The Cisco PTP implementation supports only the two-step clock and not the one-step clock. If the switch receives a one-step message from the Grand Master Clock, it will convert it into a two-step message.
-
Cisco PTP supports multicast PTP messages only.
PTP Mode and Profile
-
The switch and the grandmaster clock must be in the same PTP domain.
-
When Power Profile mode is enabled, the switch drops the PTP announce messages that do not include these two Type, Length, Value (TLV) message extensions: Organization_extension and Alternate_timescale .
If the grandmaster clock is not compliant with PTP and sends announce messages without these TLVs, configure the switch to process the announce message by entering the ptp allow-without-tlv command.
Refer to Configuring PTP Power Profile Mode on the Switch for a complete description of this command.
- When the switch is in Power Profile mode, only the peer_delay mechanism is supported.
To change to Boundary Clock Mode and the peer_delay mechanism, enter the ptp mode boundary pdelay-req command.
- To disable Power Profile mode and return the switch to E2E and P2P Transparent Clock Modes, enter the no
ptp
profile
power
command.Refer to Configuring Default Profile Mode on the Switch for a complete description of this command.
- In Default Profile mode, only the delay_request mechanism is supported.
To change to Boundary Clock Mode with the delay_request mechanism, enter the ptp mode boundary delay-req command.
-
The 802.1AS profile is available on the IE 4000 only.
-
The 802.1AS profile does not have a clock mode setting.
-
IEC 61850-9-3 is supported when operating as Transparent Clock in Power Profile and the allow-without-tlv global configuration option is enabled.
Packet Format
-
The packet format for PTP messages can be 802.1q tagged packets or untagged packets.
-
The switch does not support 802.1q QinQ tunneling.
-
In switch Power Profile mode:
-
When the PTP interface is configured as an access port, PTP messages are sent as untagged, Layer 2 packets.
-
When the PTP interface is configured as a trunk port, PTP packets are sent as 802.1q tagged Layer 2 packets over the port native VLAN.
-
-
Time recipient IEDs must support tagged and untagged packets.
-
When PTP packets are sent on the native VLAN in E2E and P2P Transparent Clock Modes, they are sent as untagged packets. To configure the switch to send them as tagged packets, enter the global vlan dot1q tag native command.
VLAN Configuration
-
Sets the PTP VLAN on a trunk port. The range is from 1 to 4094. The default is the native VLAN of the trunk port.
-
In boundary mode, 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.
-
Most grandmaster clocks use the default VLAN 0. In Power Profile mode, the switch default VLAN is VLAN 1 and VLAN 0 is reserved. When you change the default grandmaster clock VLAN, it must be changed to a VLAN other than 0.
-
When VLAN is disabled on the grandmaster clock, the PTP interface must be configured as an access port.
Clock Configuration
-
All PHY PTP clocks are synchronized to the grandmaster clock. The switch system clock is not synchronized as part of PTP configuration and processes.
-
When VLAN is enabled on the grandmaster clock, it must be in the same VLAN as the native VLAN of the PTP port on the switch.
-
Grandmaster clocks can drop untagged PTP messages when a VLAN is configured on the grandmaster clock. To force the switch to send tagged packets to the grandmaster clock, enter the global vlan dot1q tag native command.
Clock Modes
Note |
The 802.1AS profile does not have a clock mode setting. |
-
Boundary Clock Mode
-
You can enable this mode when the switch is in Power Profile Mode (Layer 2) or in Default Profile Mode (Layer 3).
-
-
Forward Mode
-
You can enable this mode when the switch is in Power Profile Mode (Layer 2) or in Default Profile Mode (Layer 3).
-
When the switch is in Forward mode, the only global configuration available is the CLI command to switch to a different PTP mode (that is, boundary, e2etransparent, or p2ptransparent).
-
-
E2E Transparent Clock Mode
-
You can enable this mode only when the switch is in Default Profile Mode (Layer 3).
-
When the switch is in E2E Transparent mode, the only global configuration available is the CLI command to switch to a different PTP mode (that is, boundary, p2ptransparent, or forward).
-
-
P2P Transparent Clock Mode
-
You can enable this mode only when the switch is in Power Profile Mode (Layer 2) or when operating as Extended Power Profile.
-
-
GMC-BC Clock Mode
-
You can enable this mode when the switch is in Default Profile Mode or Power Profile Mode.
-
PDV Filtering
Adaptive mode (ptp transfer filter adaptive ) is not available in Power Profile mode or 802.1AS profile mode.
PTP Interaction with Other Features
-
Prior to Cisco IOS Release 15.2.(7)E3, the following PTP clock modes do not support PTP over EtherChannels.:
-
e2etransparent
-
p2ptransparent
See PTP over Port Channels Feature History for details on EtherChannel support.
-
-
The following PTP clock modes only operate on a single VLAN:
-
e2etransparent
-
p2ptransparent
-
NTP to PTP Conversion
-
The NTP to PTP feature supports the Default E2E Profile and Power Profile.
GMC Block
-
The GMC Block feature is not supported in Forward mode.
PTP over Horizontal Stacking
-
Horizontal Stacking is supported on the IE 5000 only.
-
PTP over horizontal stacking is supported on a maximum stack size of 3 switches.
-
GPS should be connected to the horizontal stack master.
-
IRIG input/output is not supported in horizontal stack mode.
Default Settings
-
PTP is enabled on the switch by default.
-
By default, the switch uses configuration values defined in the Default Profile (Default Profile mode is enabled).
-
The switch default PTP clock mode is E2E and P2P Transparent Clock Modes.
-
The default BC synchronization algorithm is linear filter.
Configuring PTP on the Switch
Use one of the following procedures in this section to configure the switch for PTP.
Note |
To configure the switch for grandmaster-boundary clock mode (gmc-bc), see Configuring NTP to PTP Time Conversion. |
Configuring Default Profile Mode on the Switch
This section describes how to configure the switch to operate in Default Profile mode.
Before you begin
The switch sends untagged PTP packets on the native VLAN when the switch port connected to the grandmaster clock is configured as follows:
-
Switch is in Default Profile mode.
-
Switch is in trunk mode.
-
VLAN X is configured as the native VLAN.
When the grandmaster clock requires tagged packets, make one of the following configuration changes:
-
Force the switch to send tagged frames by entering the global vlan dot1q tag native command.
-
Configure the grandmaster clock to send and receive untagged packets. If you make this configuration change on the grandmaster clock, you can configure the switch port as an access port.
These are some guidelines for configuring the Default Profile on the switch:
-
When you enter no with PTP port configuration commands, the specified port property is set to the default value.
-
To determine the value in seconds for the ptp global command interval variable, use a logarithmic scale. Below are examples of the interval variable value converted to seconds with a logarithmic scale:
|
Value Entered |
Logarithmic Calculation |
Value in Seconds |
|---|---|---|
|
-1 |
2 -1 |
1/2 |
|
0 |
2 0 |
1 |
SUMMARY STEPS
- Enter global configuration mode:
- Configure the switch for Default Profile mode when the switch is in Power Profile mode. If the switch is already in Default Profile mode, this command has no effect. The command no ptp profile-name returns to the switch to the Default Profile mode.
- Specify the synchronization clock mode:
- (Optional, BC and TC mode) Specify the PTP clock domain:
- (Optional, BC mode only) Specify the BMCA priority:
- (Optional, BC mode only) Specify time-property preservation:
- (Optional, BC mode only) Specify the BC synchronization algorithm:
- (Optional, BC mode only) Specify the DSCP Event/General message values:
- (Optional) Enter interface configuration mode:
- (Optional) Specify port settings:
- Return to privileged EXEC mode:
- Verify your entries:
- (Optional) Save your entries in the configuration file:
DETAILED STEPS
| Step 1 |
Enter global configuration mode: configure terminal |
| Step 2 |
Configure the switch for Default Profile mode when the switch is in Power Profile mode. If the switch is already in Default Profile mode, this command has no effect. The command no ptp profile-name returns to the switch to the Default Profile mode. no ptp profile power |
| Step 3 |
Specify the synchronization clock mode: ptp {mode boundary delay-req | e2etransparent | forward | gmc-bc}
|
| Step 4 |
(Optional, BC and TC mode) Specify the PTP clock domain: ptp domain domain-number domain-number — A number from 0 to 255. The participating grandmaster clock, switches, and time recipient devices should be in the same domain. |
| Step 5 |
(Optional, BC mode only) Specify the BMCA priority: ptp priority1 priority priority2 priority
|
| Step 6 |
(Optional, BC mode only) Specify time-property preservation: ptp time-property persist {value | infinite}
Preserving the time properties prevents time recipient clocks from detecting a variance in the time values when the redundant GMC comes out of standby. |
| Step 7 |
(Optional, BC mode only) Specify the BC synchronization algorithm: ptp transfer {feedforward | filter {adaptive | linear }}
|
| Step 8 |
(Optional, BC mode only) Specify the DSCP Event/General message values: ptp ip dscp dscp_value message {event | general}
|
| Step 9 |
(Optional) Enter interface configuration mode: interface interface-id |
| Step 10 |
(Optional) Specify port settings: Boundary delay-req mode: ptp {announce {interval value | timeout value } | delay-req interval value | enable | sync {interval value | limit value } | vlan value } e2etransparent mode: ptp {enable | sync {interval value | limit value }}
|
| Step 11 |
Return to privileged EXEC mode: end |
| Step 12 |
Verify your entries: show running-config |
| Step 13 |
(Optional) Save your entries in the configuration file: copy running-config startup-config |
Example
The following example configures the switch to operate in Default Profile mode and end-to-end transparent mode, and uses default values for all PTP interval settings:
switch(config)# no ptp profile
switch(config)# ptp mode e2etransparent
The following example configures the switch for Default Profile mode and boundary clock mode with the delay_request mechanism, and uses default values for all PTP interval settings:
switch(config)# no ptp profile
switch(config)# ptp mode boundary delay-req
Configuring PTP Power Profile Mode on the Switch
This section describes how to configure the switch to use the PTP Power Profile and operate in Power Profile mode.
Before you begin
These are some guidelines for configuring the Power Profile on the switch:
-
When you enter no with PTP port configuration commands, the specified port property is set to the default value.
-
To determine the value in seconds for the ptp global command interval variable, use a logarithmic scale. Below are examples of the interval variable value converted to seconds with a logarithmic scale:
|
Value Entered |
Logarithmic Calculation |
Value in Seconds |
|---|---|---|
|
-1 |
2 -1 |
1/2 |
|
0 |
2 0 |
1 |
SUMMARY STEPS
- Enter global configuration mode:
- Set the Power Profile:
- Specify the synchronization clock mode:
- (Optional, BC and TC mode; not available in Extended Power Profile) Specify TLV settings:
- (Optional, BC and TC mode) Specify the PTP clock domain:
- (Optional, BC and TC mode) Specify the packet priority:
- (Optional, BC mode only) Specify the BMCA priority:
- (Optional, BC mode only) Specify time-property preservation:
- (Optional, BC mode only) Specify the BC synchronization algorithm:
- (Optional) Enter interface configuration mode:
- (Optional) Specify port settings:
- Return to privileged EXEC mode:
- Verify your entries:
- (Optional) Save your entries in the configuration file:
DETAILED STEPS
| Step 1 |
Enter global configuration mode: configure terminal |
| Step 2 |
Set the Power Profile: ptp profile power |
| Step 3 |
Specify the synchronization clock mode: ptp mode {boundary pdelay-req | p2ptransparent | forward}| gmc-bc}
|
| Step 4 |
(Optional, BC and TC mode; not available in Extended Power Profile) Specify TLV settings: ptp allow-without-tlv |
| Step 5 |
(Optional, BC and TC mode) Specify the PTP clock domain: ptp domain domain-number domain-number—A number from 0 to 255. The default is 0 for the Power Profile and 254 for the Extended Power Profile. The participating grandmaster clock, switches, and time recipient devices should be in the same domain. |
| Step 6 |
(Optional, BC and TC mode) Specify the packet priority: ptp packet priority The PTP packets have a default priority of 4. Lower values take precedence. |
| Step 7 |
(Optional, BC mode only) Specify the BMCA priority: ptp priority1 priority priority2 priority
|
| Step 8 |
(Optional, BC mode only) Specify time-property preservation: ptp time-property persist {value | infinite }
Preserving the time properties prevents time recipient clocks from detecting a variance in the time values when the redundant GMC comes out of standby. |
| Step 9 |
(Optional, BC mode only) Specify the BC synchronization algorithm: ptp transfer {feedforward | filter linear }
|
| Step 10 |
(Optional) Enter interface configuration mode: interface interface-id |
| Step 11 |
(Optional) Specify port settings: Boundary pdelay-req mode: ptp {announce {interval value | timeout value } | pdelay-req interval value | enable | sync {interval value | limit value } | vlan value } p2ptransparent mode: ptp {pdelay-req interval value | enable | sync limit value | vlan value }
|
| Step 12 |
Return to privileged EXEC mode: end |
| Step 13 |
Verify your entries: show running-config |
| Step 14 |
(Optional) Save your entries in the configuration file: copy running-config startup-config |
Example
The following example configures the switch for P2P transparent mode (the default in Power Profile mode), specifies allow-without-tlv PTP message processing, and uses default values for all PTP interval settings:
switch(config)# ptp allow-without-tlv
The following example configures the switch for boundary clock mode using the peer delay request (pdelay-req) mechanism and uses default values for all PTP interval settings:
switch(config)# ptp mode boundary pdelay-req
Configuring 802.1AS Profile Mode on the Switch (IE 4000 only)
This section describes how to configure the IE 4000 switch to use the 802.1AS Profile and operate in 802.1AS Profile mode.
SUMMARY STEPS
- Enter global configuration mode:
- Set the 802.1AS Profile:
DETAILED STEPS
| Step 1 |
Enter global configuration mode: configure terminal |
| Step 2 |
Set the 802.1AS Profile: ptp profile dot1as |
Example
The following example shows configuring the IE 4000 switch to use the 802.1AS Profile:
IE4000-SW2(config)#ptp profile dot1as
802.1AS Troubleshooting
Refer to the following to troubleshoot 802.1AS issues:
-
New Syslogs (Informational)—Parent and Grandmaster clock change syslogs notify user about the parent/grandmaster reselection. If that change happens frequently, or does not meet system expectation, further investigation should be taken. The following shows example log entries:
-
Mar 24 21:22:40.702: %PTP-6-PARENT_CLOCK_CHANGE: Old parent clock identity: 0x0:0:0:0:0:0:0:0 port number: 0, New parent clock identity: 0x0:35:1A:FF:FE:DA:12:80 port number: 9
-
Mar 24 21:22:40.702: %PTP-6-GRANDMASTER_CLOCK_CHANGE: Old grandmaster clock identity: 0x0:0:0:0:0:0:0:0, New grandmaster clock identity: 0x0:35:1A:FF:FE:DA:12:80
-
Mar 24 19:18:34.235: %PTP-6-GRANDMASTER_CLOCK_CHANGE_TO_LOCAL: Old grandmaster clock identity: 0x0:35:1A:FF:FE:DA:12:80, New grandmaster clock identity: 0x58:97:BD:FF:FE:D9:97:80 (local system)
-
-
SyncReceive TimeOut
-
802.1AS added a new timer to detect sync receive timeout. If the next sync message does not arrive within 3 x sync interval (specified in the header of first sync message) on a PTP time recipient port, sync receive timeout occurs.
-
This can be learned by turning on debug ptp event and observing "PTP (Interface GigabitEthernet1/1): sync receipt timeout" on the console.
-
At SyncReceive Timeout, the state of that PTP port will no longer be time recipient. The next BMCA will re-select the new time recipient port.
-
Configuring Extended Power Profile
This section describes how to configure the switch to use the Extended Power Profile (C37.238-2017) in Transparent mode.
Note |
All the options available for the Power Profile are available in Extended Power Profile except for ptp allow-without-tlv and a clock mode other than Transparent Clock mode. |
Procedure
| Step 1 |
Enter global configuration mode: configure terminal |
| Step 2 |
Set the Extended Power Profile: ptp profile power-2017 |
| Step 3 |
(Optional) Specify the PTP clock domain: ptp domain domain-number domain-number—A number from 0 to 255. The default is 0 for the Power Profile and 254 for the Extended Power Profile. The participating grandmaster clock, switches, and time recipient devices should be in the same domain. |
| Step 4 |
(Optional) Specify the packet priority: ptp packet priority The PTP packets have a default priority of 4. Lower values take precedence. |
| Step 5 |
(Optional) Enter interface configuration mode: interface interface-id |
| Step 6 |
(Optional) Specify port settings: p2ptransparent mode: ptp {pdelay-req interval value | enable | sync limit value | vlan value }
|
| Step 7 |
Return to privileged EXEC mode: end |
| Step 8 |
Verify your entries: show running-config |
| Step 9 |
(Optional) Save your entries in the configuration file: copy running-config startup-config |
Example
The following example shows configuring the switch to use the Extended Power Profile:
Switch(config)#)#ptp profile ?
power Power profile (IEEE C37.238-2011)
power-2017 Power profile (IEEE C37.238-2017)
Switch(config)#ptp profile power-2017
Switch(config)#
This example shows the output of show ptp clock when the Extended Power Profile is configured:
Switch#show ptp clock
PTP CLOCK INFO
PTP Device Type: Peer to Peer transparent clock
PTP Device Profile: Power Profile C37.238-2017
Local Time Inaccuracy: 50 ns
Clock Identity: 0xE0:E:DA:FF:FE:69:11:0
Clock Domain: 254
Number of PTP ports: 17
PTP Packet priority: 4
Delay Mechanism: Peer to Peer
Local clock time: 09:36:16 MVT Mar 29 2021
Switch#
Verifying Configuration
|
Command |
Purpose |
|---|---|
| show ptp {clock | foreign-master-records | parent | port {FastEthernet | GigabitEthernet} | time-property } | Specifies the PTP information to display.
|
Power Profile Example
switch# show ptp parent
PTP PARENT PROPERTIES
Parent Clock:
Parent Clock Identity: 0xA4:C:C3:FF:FE:BF:B4:0
Parent Port Number: 23
Observed Parent Offset (log variance): N/A
Observed Parent Clock Phase Change Rate: N/A
Grandmaster Clock:
Grandmaster Clock Identity: 0xA4:C:C3:FF:FE:BF:2B:0
Grandmaster Clock Quality:
Class: 248
Accuracy: Unknown
Offset (log variance): N/A
Priority1: 128
Priority2: 128
switch# show ptp clock
PTP CLOCK INFO
PTP Device Type: Boundary clock
PTP Device Profile: Power Profile
Clock Identity: 0xA4:C:C3:FF:FE:BF:E0:80
Clock Domain: 0
Number of PTP ports: 26
PTP Packet priority: 4
Priority1: 128
Priority2: 128
Clock Quality:
Class: 248
Accuracy: Unknown
Offset (log variance): N/A
Offset From Master(ns): 25
Mean Path Delay(ns): 705
Steps Removed: 4
Local clock time: 14:23:56 PST Apr 5 2013
switch# show ptp foreign-master-record
PTP FOREIGN MASTER RECORDS
Interface GigabitEthernet1/1
Foreign master port identity: clock id: 0xF4:4E:5:FF:FE:E5:82:0
Foreign master port identity: port num: 1
Number of Announce messages: 4
Message received port: 1
Time stamps: 1999872004, 1999870997
Interface GigabitEthernet1/2
Empty
Interface GigabitEthernet1/3
Empty
Interface GigabitEthernet1/4
Empty
Interface GigabitEthernet1/5
Empty
Interface GigabitEthernet1/6
Empty
Interface GigabitEthernet1/7
Empty
Interface GigabitEthernet1/8
Empty
Interface GigabitEthernet1/9
Empty
Interface GigabitEthernet1/10
Empty
Interface GigabitEthernet1/11
Empty
Interface GigabitEthernet1/12
Empty
Interface GigabitEthernet1/13
Empty
Interface GigabitEthernet1/14
Empty
Interface GigabitEthernet1/15
Empty
Interface GigabitEthernet1/16
Empty
Interface GigabitEthernet1/17
Empty
Interface GigabitEthernet1/18
Empty
Interface GigabitEthernet1/19
Empty
Interface GigabitEthernet1/20
Empty
switch#
switch# show ptp ?
clock show ptp clock information
foreign-master-record show PTP foreign master records
parent show PTP parent properties
port show PTP port properties
time-property show PTP clock time property
switch# show ptp time-property
PTP CLOCK TIME PROPERTY
Current UTC offset valid: 0
Current UTC offset: 35
Leap 59: 0
Leap 61: 0
Time Traceable: 16
Frequency Traceable: 32
PTP Timescale: 1
Time Source: Internal Osciliator
Time Property Persistence: 300 seconds
switch# show ptp port GigabitEthernet 1/1
PTP PORT DATASET: GigabitEthernet1/1
Port identity: clock identity: 0xF4:4E:5:FF:FE:E5:91:80
Port identity: port number: 1
PTP version: 2
Port state: UNCALIBRATED
Delay request interval(log mean): 5
Announce receipt time out: 3
Peer mean path delay(ns): 0
Announce interval(log mean): 0
Sync interval(log mean): 0
Delay Mechanism: Peer to Peer
Peer delay request interval(log mean): 0
Sync fault limit: 500000000
switch# 802.1AS Profile Example
IE4000-SW2#show ptp clock //check profile, and clock offset
PTP CLOCK INFO PTP
Device Type: 802.1AS - Time Aware Bridge
PTP Device Profile: 802.1AS Profile
Clock Identity: 0x58:97:BD:FF:FE:D9:97:80
Clock Domain: 0
…
Offset From Master(ns): 3 // this should be less than 1uS
IE4000-SW2#show ptp port FastEthernet 1/9
PTP PORT DATASET: FastEthernet1/9
…
Neighbor Rate Ratio: 1 (+0 PPM) // this should be within +/-100PPM
Port 802.1AS capable: TRUE // 802.1AS capable
IE4000-SW2#show ptp parent
PTP PARENT PROPERTIES
…
Clock Identity Path Trace: // path trace TLV list – the clock IDs of nodes on the clock distribution chain from the grandmaster
Clock Identity 0: 0x0:00:00:11:11:11:11:01 // grandmaster
Clock Identity 1: 0x0:35:1A:FF:FE:DA:12:80 // 2nd clock in the path
Configuration Example
The following example configures the switch for P2P transparent mode, specifies allow-without-tlv PTP message processing, and uses default values for all PTP interval settings:
switch(config)# ptp allow-without-tlv
The following example configures the switch for boundary clock mode using the peer delay request (pdelay- req) mechanism and uses default values for all PTP interval settings:
switch(config)# ptp mode boundary pdelay-req
The following example configures the switch to operate in Default Profile mode and end-to-end transparent mode and uses default values for all PTP interval settings:
switch(config)# no ptp profile
switch(config)# ptp mode e2etransparent
The following example configures the switch for Default Profile mode and boundary clock mode with the delay_request mechanism, and uses default values for all PTP interval settings:
switch(config)# no ptp profile
switch(config)# ptp mode boundary delay-req
Configuring NTP to PTP Time Conversion
Before you begin
-
Review the Guidelines and Limitations.
-
To use the NTP to PTP conversion feature, the switch must have an IP address for NTP to function.
-
To use the NTP to PTP conversion feature, you must configure at least one NTP server. Configuring three or more NTP servers allows NTP to ignore bad clocks.
Note
For information about configuring NTP, see the section Configuring NTP in the Catalyst 3750-X and 3560-X Switch Software Configuration Guide, Release 12.2(55)SE .
-
When you enter no with PTP port configuration commands, the specified port property is set to the default value.
-
To determine the value in seconds for the ptp global command interval variable, use a logarithmic scale. Below are examples of the interval variable value converted to seconds with a logarithmic scale:
|
Value Entered |
Logarithmic Calculation |
Value in Seconds |
|---|---|---|
|
-1 |
2 -1 |
1/2 |
|
0 |
2 0 |
1 |
SUMMARY STEPS
- Enter global configuration mode:
- Configure the switch for Default Profile mode or Power Profile mode.
- Specify GMC-BC as the synchronization clock:
- (Optional) Specify the BMCA priority:
- (Optional) Specify the BC synchronization algorithm:
- Enter interface configuration mode:
- (Optional) Specify port settings:
- Return to privileged EXEC mode:
- Verify your entries:
- (Optional) Save your entries in the configuration file:
DETAILED STEPS
| Step 1 |
Enter global configuration mode: configure terminal |
| Step 2 |
Configure the switch for Default Profile mode or Power Profile mode. no ptp profile power or ptp profile power |
| Step 3 |
Specify GMC-BC as the synchronization clock: ptp mode gmc-bc delay-req The GMC-BC automatically selects NTP as the time source if it is available. |
| Step 4 |
(Optional) Specify the BMCA priority: ptp priority1 priority priority2 priority
|
| Step 5 |
(Optional) Specify the BC synchronization algorithm: ptp transfer {feedforward | filter {adaptive | linear }}
|
| Step 6 |
Enter interface configuration mode: interface interface-id |
| Step 7 |
(Optional) Specify port settings: ptp {announce {interval value | timeout value } | delay-req interval value | enable | sync {interval value | limit value } | vlan value }
|
| Step 8 |
Return to privileged EXEC mode: end |
| Step 9 |
Verify your entries: show running-config |
| Step 10 |
(Optional) Save your entries in the configuration file: copy running-config startup-config |
Example
The following example configures the switch to use the Default Profile, act as Grandmaster Clock with NTP as the time source, and use the feedforward BC synchronization algorithm:
switch(config)# no ptp profile power
switch(config)# ptp mode gmc-bc
switch(config)# ptp transfer feedforward
Verifying Configuration
Perform these steps to verify that switch is running as GMC-BC, and that NTP and PTP are synchronized:
SUMMARY STEPS
- Monitor the status of NTP until NTP locks:
- Display the status of each individual NTP server:
- After NTP is up and running, verify that the NTP clock and the PTP clock are in sync.
DETAILED STEPS
| Step 1 |
Monitor the status of NTP until NTP locks: show ntp status Note especially the following fields:
Example: |
||
| Step 2 |
Display the status of each individual NTP server: show ntp association
Example: |
||
| Step 3 |
After NTP is up and running, verify that the NTP clock and the PTP clock are in sync.
Example: |
Configuration Example
switch# conf t
switch(config)# no ptp profile power
switch(config)# ptp mode gmc-bc
switch(config)# ptp transfer feedforward
switch(config)# end
Configuring PTP Master Only
Follow these steps to enable PTP Master only and block all ingress PTP Announce, Sync, and Followup messages on an interface.
Before you begin
Ensure that PTP is enabled before enabling the PTP Master Only feature.
SUMMARY STEPS
- Enter global configuration mode:
- Enter interface configuration mode:
- Enable GMC Block on the interface:
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
Enter global configuration mode: |
configure terminal |
| Step 2 |
Enter interface configuration mode: |
interface interface-id |
| Step 3 |
Enable GMC Block on the interface: |
ptp gmc-block |
Example
Switch#
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#int gi
Switch(config)#int gigabitEthernet 1/9
Switch(config-if)#ptp ?
announce announce settings
delay-req delay request settings
enable ptp protocol enable
gmc-block block rogue gmc
sync sync settings
Switch(config-if)#ptp gmc-block
Switch(config-if)
Verifying Configuration
To check rogue device details use the show ptp rogue master record command, for example:
Switch#
Switch#sh ptp rogue-master-record
PTP Rogue Master Records
Interface GigabitEthernet1/1
Empty
Interface GigabitEthernet1/2
Empty
Interface GigabitEthernet1/3
Empty
Interface GigabitEthernet1/4
Rogue master MAC address :0xB0:AA:77:58:6D:04
Rogue master IP address: 20.0.0.1
Rogue master clock identity: 0xB0:AA:77:FF:FE:58:6D:0
Last packet received time stamp: 08:46:51 UTC Wed Mar 25 2020
Interface GigabitEthernet1/13
Empty
Interface FastEthernet1/5
Empty
SNMP Traps
SNMP traps are generated to identify rogue devices. Two SNMP traps are generated, one to detect and one to clear the rogue device presence.
Following is an example of an SNMP trap for detect:
Received SNMPv2c Trap: Community: public
From: 10.65.217.108
mib_2.1.3.0 = 00:11:15.96
snmpModules.1.1.4.1.0 = ciscoPtpRogueMaster
cPtpClockRogueMasterDetect.1 = true(1)
cPtpClockPortName.1 = GigabitEthernet1/9
Following is the SNMP walk output:
Mib Object: 1.3.6.1.4.1.9.9.760.1.2.7.1.11
cPtpClockPortBlockGMC.0.3.1.1 = 0
cPtpClockPortBlockGMC.0.3.1.2 = 0
cPtpClockPortBlockGMC.0.3.1.3 = 0
cPtpClockPortBlockGMC.0.3.1.4 = 0
cPtpClockPortBlockGMC.0.3.1.5 = 0
cPtpClockPortBlockGMC.0.3.1.6 = 0
cPtpClockPortBlockGMC.0.3.1.7 = 0
cPtpClockPortBlockGMC.0.3.1.8 = 0
cPtpClockPortBlockGMC.0.3.1.9 = true(1) (port 9 is enabled with gmc-block)
cPtpClockPortBlockGMC.0.3.1.10 = 0
cPtpClockPortBlockGMC.0.3.1.11 = 0
cPtpClockPortBlockGMC.0.3.1.12 = 0
Syslog Messages
Two Syslog messages are displayed after receiving PTP packets from a GMC outside the network.
-
%PTP-4-ROGUE_MASTER_DETECT: Rogue master packets received on Gigabitetherne1/4
After the gmc-block command is configured the system waits for 30 seconds. If a rogue packet is received this message is displayed. If a rogue packet arrives after the 30 second timer expires, the message is still displayed.
This message is displayed only once and not for every packet.
-
%PTP-6-ROGUE_MASTER_CLEAR: Stopped receiving rogue master packets on Gigabitetherne1/4
This message is displayed after rogue PTP packets are no longer received on the interface.
The system waits 180-240 seconds before displaying this syslog message. If packets are received again the timer is reinitialized.
Alarm
If rogue packets are received on the PTP master only configured port, the following alarm is generated.
|
Source |
Severity |
Description |
Relay |
Time |
|---|---|---|---|---|
|
PTP |
Minor |
Rogue master packets received |
MIN |
Jan 2 2020 10:41:23 |
PTP Serviceability
PTP Serviceability refers to the ability to troubleshoot and monitor PTP performance on a network with a Cisco IE Switch. This section describes how to display the following PTP Serviceability statistics and information:
-
PTP message counters
-
PTP error counters
-
Timestamp offset and mean path delay maximum and minimum values
-
Histogram of the offset and mean path delay values
Displaying PTP Message Counters
To display counter information for PTP messages sent and received on all interfaces, use the show ptp port counters messages command. To display counters for a specific interface, enter show ptp port counters messages <interface> . For example:
Switch# show ptp port gi1/4 counters messages
GigabitEthernet1/4
Transmit Receive
5 Announce 34 Announce
9 Sync 68 Sync
9 Follow_Up 68 Follow_Up
10 Delay_Req 0 Delay_Req
0 Delay_Resp 10 Delay_Resp
0 Pdelay_Req 0 Pdelay_Req
0 Pdelay_Resp 0 Pdelay_Resp
0 Pdelay_Resp_Follow_Up 0 Pdelay_Resp_Follow_Up
0 Signaling 0 Signaling
0 Management 0 Management
Note |
Note: the output of show ptp port counters messages was changed in Cisco IOS Release 15.2(8)E. Switches with earlier Cisco IOS releases display the output of show ptp counters messages in a different format. |
The command output is described in the table below.
Enter clear ptp port counters messages to clear the message counters for all interfaces.
To clear the counters for specific port, enter clear ptp port interface <interface> counters messages .
|
Port |
The port type and number (for example, Gi1/3). |
|
Transmit, Receive |
The direction of the data displayed in the table. |
|
Announce |
General message (not tagged with a timestamp) used to establish a time source-time recipient hierarchy. |
|
Sync |
Event message tagged with a timestamp when data packets reach or leave a port and used to synchronize ordinary and boundary clocks. |
|
Follow_Up |
General message (not tagged with a timestamp) used to used to synchronize ordinary and boundary clocks. |
|
Delay_Req |
Delay request—Event message tagged with a timestamp when data packets reach or leave a port and used to synchronize ordinary and boundary clocks. |
|
Delay_Resp |
Delay response—General message used to synchronize ordinary and boundary clocks. The time source conveys the timestamp t4 to the time recipient by embedding it in a Delay_Resp message. |
|
Pdelay_Req |
Peer delay request—Event message tagged with a timestamp when data packets reach or leave a port and used to measure the link delay in transparent clocks. |
|
Pdelay_Resp |
Peer delay response—Event message tagged with a timestamp when data packets reach or leave a port and used to measure the link delay in transparent clocks. |
|
Pdelay_Resp_Follow_Up |
Peer delay response follow up—General message (not tagged with a timestamp) used to measure the link delay in transparent clocks. |
|
Signaling |
Message used to transport a sequence of one or more TLV entities. Signaling messages are transmitted from one clock to one or more other clocks. |
|
Management |
Messages used to access attributes and to generate certain events defined in the PTP standard. |
Displaying PTP Error Message Counters
PTP errors are categorized as field mismatch errors, unexpected messages, duplicate messages, and generic errors. To display counter information for PTP errors that occurred on all interfaces, use the show ptp port counters errors command. To display counters for a specific interface, enter show ptp port counters errors <interface> . For example:
NAT2#sh ptp port counters errors
GigabitEthernet1/1
0 Sanity check failed 0 Blocked port
0 Timestamp get failed 0 ParentId invalid
0 Vlan mismatch 0 GmcId invalid
0 Domain mismatch 0 SequenceId invalid
0 Sync fault 0 Unmatched Follow_Up
0 Duplicate Sync 0 Unmatched Delay_Resp
0 Duplicate Announce 0 Unmatched Pdelay_Resp
0 Send error 0 Unmatched Pdelay_Resp_Follow_Up
0 Misc error 0 Rogue master Sync
0 Rogue master Follow_Up 0 Rogue master Announce
NAT2#sh ptp port gi1/2 counters errors
GigabitEthernet1/2
0 Sanity check failed 0 Blocked port
0 Timestamp get failed 0 ParentId invalid
0 Vlan mismatch 0 GmcId invalid
0 Domain mismatch 0 SequenceId invalid
0 Sync fault 0 Unmatched Follow_Up
0 Duplicate Sync 0 Unmatched Delay_Resp
0 Duplicate Announce 0 Unmatched Pdelay_Resp
0 Send error 0 Unmatched Pdelay_Resp_Follow_Up
0 Misc error 0 Rogue master Sync
0 Rogue master Follow_Up 0 Rogue master Announce
NAT2#
The command output is described in the table below.
Enter clear ptp port counters errors to clear the error counters for all interfaces.
To clear the error counters for specific port, enter clear ptp port interface <interface> counters errors .
|
Port |
The port type and number. |
|
Sanity check failed |
The PTP message header field(s) of ingress PTP packets are invalid. |
|
Timestamp get failed |
The timestamp for PTP messages is generated by the hardware. The timestamp error counter is incremented when the software is unable to fetch the timestamp for a given PTP message. The PTP messages that have a timestamp are Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp. |
|
Vlan mismatch |
The VLAN ID of ingress PTP messages is different from the VLAN ID configured in the ptp vlan command. |
|
Domain mismatch |
(Applicable only in Boundary Clock mode) The domain number field of ingress PTP messages is different from the configured PTP clock domain (the PTP domain number configured in the ptp domain command). |
|
Sync fault |
The PTP clock offset value has exceeded the “sync limit” value configured on the PTP time recipient port (the value configured for ptp sync limit on the interface, which is in the PTP SLAVE state). |
|
Duplicate sync |
The number of duplicate PTP Sync messages received by the switch. (Duplicates are identified by checking the PTP sequence number on received messages.) |
|
Duplicate announce |
The number of duplicate PTP Announce messages received by the switch. (Duplicates are identified by checking the PTP sequence number on received messages.) |
|
Send error |
The number of PTP messages that could not be sent due to failures. PTP software might fail to send PTP messages due to reasons such as memory allocation failure, failure to obtain the correct outgoing interface information, etc. |
|
Misc error |
The number of miscellaneous errors that have occurred in the PTP protocol. Any error other than the ones listed above is classified as a miscellaneous error. |
|
Rogue master Follow_Up |
The number of dropped incoming follow up messages for rogue packets. |
|
Blocked port |
The PTP messages (except Peer-Delay messages) are received on REP/STP blocked ports. |
|
ParentId invalid |
(Applicable only in Boundary Clock mode) The source port identity of ingress PTP messages is different from parent port identity of the local PTP clock. |
|
GMCId invalid |
(Applicable only in Boundary Clock mode)
The grandmaster clock identity of ingress announce messages has an invalid value (the grandmaster clock identity of ingress announce messages is the same as the clock identity of the local PTP clock). |
|
SequenceId invalid |
(Applicable only in Boundary Clock mode)
The sequence ID field of ingress PTP messages has an invalid value (the sequence ID of the follow-up message is different from the sequence ID of the preceding sync message). |
|
Unmatched Follow_Up |
The switch received a Follow up message when there was no outstanding SYNC message for which it expected a Follow up. |
|
Unmatched Delay_Resp |
Unmatched Delay Response—The switch received a Delay Response without sending a Delay Request. |
|
Unmatched Pdelay_Resp |
Unmatched Peer Delay Response—The switch received a Peer Delay Response message without sending a Peer Delay Request. |
|
Unmatched Pdelay_Resp_Follow_Up |
Unmatched Peer Delay Response Follow up—The switch received a Peer Delay Response Follow up message without sending a Peer Delay Request. |
|
Rogue master Sync |
The number of dropped incoming Sync messages for rogue packets. |
|
Rogue master Announce |
The number of dropped incoming Announce messages for rogue packets. |
Displaying PTP Offset and Delay
The PTP offset value is the measured offset of the clock from the master clock, in nanoseconds. The mean path delay is the average time, in nanoseconds, taken by PTP frames to travel between time source and time recipient. You can display the historical maximum and minimum values for the offset from time source and mean path delay when the switch is operating in GMC-BC (Grandmaster Boundary Clock) or BC (Boundary Clock) modes. You can also display a histogram of offset, delay, and time errors, where the historical values of the field specified are divided into bins to show the data distribution.
High offset and delay values can indicate a problem, for example, when a device goes down in the network and the link to the time source is available but not viable. Ideally, offset and delay values should be as small as possible. Some PTP modes or profiles might cause higher offset values. Offsets can be negative.
Offset and delay values are shown for the last day and the past 5 seconds, 15 seconds, 1 minute, 5 minutes, 15 minutes, 1 hour, 5 hours, 15 hours, 1 day (same as last day), 5 days, 15 days, and more than fifteen days.
If the switch is the time source or grandmaster clock these values are zero.
Note |
The commands to show historical maximum and minimum values for the offset from time source and mean path delay are supported for both PTP Default Profile and Power Profile. The commands to show time error data apply to p2ptransparent or e2etransparent clock modes. |
Offset
To display the historical maximum and minimum values for the offset from time source, enter the show ptp history offset command, for example:
NAT1#sh ptp history offset
5 seconds 15 seconds 1 minute 5 minutes
Max offset from master(ns): 0 0 0 0
Min offset from master(ns): 0 0 0 0
15 minutes 1 hour 5 hours 15 hours
Max offset from master(ns): 0 0 0 0
Min offset from master(ns): 0 0 0 0
1 day 5 days 15 days >15 days
Max offset from master(ns): 2999 2999 2999 2999
Min offset from master(ns): -726 -726 -726 -726
NAT1#
Delay
To display the historical maximum and minimum values for the mean path delay, enter show ptp history delay , as shown in this example:
NAT1#sh ptp history delay
5 seconds 15 seconds 1 minute 5 minutes
Max mean path delay(ns): 0 0 0 0
Min mean path delay(ns): 0 0 0 0
15 minutes 1 hour 5 hours 15 hours
Max mean path delay(ns): 0 0 0 0
Min mean path delay(ns): 0 0 0 0
1 day 5 days 15 days >15 days
Max mean path delay(ns): 12154 12154 12154 12154
Min mean path delay(ns): 0 0 0 0
NAT1#
Time Error
To display the historical maximum and minimum values for time error data when the clock mode is p2ptransparent or e2etransparent, enter show ptp history time-error , as shown in this example:
NAT2#sh ptp history time-error
5 seconds 15 seconds 1 minute 5 minutes
Max time error(ns): 0 0 0 0
Min time error(ns): -35260 -36487 -36487 0
15 minutes 1 hour 5 hours 15 hours
Max time error(ns): 0 0 0 0
Min time error(ns): 0 0 0 0
1 day 5 days 15 days >15 days
Max time error(ns): 0 0 0 0
Min time error(ns): 0 0 0 0
NAT2#
Histogram
To display a histogram of PTP offset, delay, or time-error data, enter the show ptp histogram [offset|delay|time-error] command. Data is shown for the last 60 seconds, the last hour, and the last 24 hours. Values are divided into ranges of 0 to 20 nanoseconds, 20 to 50 nanoseconds, 50 to 100 nanoseconds, 100 to 250 nanoseconds, 250 to 500 nanoseconds, 500 to 1000 nanoseconds, 1000 to 10,000 nanoseconds, and greater than 10,000 nanoseconds. Offset and time-error values are further classified as negative or positive.
-
Offset—Available when the clock mode is boundary; displays histogram for offset from time source.
-
Delay—Available when the clock mode is boundary or gmc-boundary; displays histogram of mean path delay data.
-
Time-error—Available when the clock mode is p2ptransparent or e2etransparent; displays histogram of data for time-error (frequency error * residence time).
The following example shows the histogram for PTP offset and delay.
Switch#show ptp histogram offset
Offset data history
Last 60 seconds:
0 5 5 2 -6 1 0 4
-3 -5 2 -4 0 -1 2 4
3 -3 -4 -2 3 3 2 -3
0 -8 4 4 -2 6 -5 -6
4 0 2 -1 -4 1 -6 2
2 -3 -1 4 -1 1 0 3
-4 -6 0 5 0 7 5 0
-6 2 4 1
Offset range Positive Negative
0-20ns 38 22
20-50ns 0 0
50-100ns 0 0
100-250ns 0 0
250-500ns 0 0
500-1us 0 0
1-10us 0 0
>10us 0 0
Last 60 mins:
-6 2 -2 -6 0 0 0 1
-6 3 -2 3 -6 -1 4 3
-4 3 -6 -2 3 -2 -1 -4
-1 -7 2 0 -6 3 1 -5
5 -6 3 -1 -4 -1 2 1
-2 1 2 -2 4 2 0 4
0 -2 3 -2 -5 -4 -3 -5
-1 -1 -4 -1
Offset range Positive Negative
0-20ns 27 33
20-50ns 0 0
50-100ns 0 0
100-250ns 0 0
250-500ns 0 0
500-1us 0 0
1-10us 0 0
>10us 0 0
Last 24hr:
0 -4 -3 4 7 0 6 1
-6 3 3 -3 4 0 1 -9
1 -3 -2 0 2 -5 -1 -4
Offset range Positive Negative
0-20ns 14 10
20-50ns 0 0
50-100ns 0 0
100-250ns 0 0
250-500ns 0 0
500-1us 0 0
1-10us 0 0
>10us 0 0
Switch#show ptp histogram delay
Mean path delay data history
Last 60 seconds:
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 123 123
123 123 123 123
Delay range
0-20ns 0
20-50ns 0
50-100ns 0
100-250ns 60
250-500ns 0
500-1us 0
1-10us 0
>10us 0
Last 60 minutes:
122 122 123 123 123 123 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 122 122 122
121 121 122 121 122 122 122 122
122 122 122 122 122 122 122 122
122 122 122 122 122 121 121 121
121 122 122 122 122 121 121 122
122 122 122 122
Delay range
0-20ns 0
20-50ns 0
50-100ns 0
100-250ns 60
250-500ns 0
500-1us 0
1-10us 0
>10us 0
Last 24 hours:
121 122 121 122 122 122 122 122
121 122 121 122 121 121 122 121
121 122 122 122 122 122 122 122
Delay range
0-20ns 0
20-50ns 0
50-100ns 0
100-250ns 24
250-500ns 0
500-1us 0
1-10us 0
>10us 0
The following example shows the histogram for time error data.
NAT2#sh ptp histogram time-error
Time Error (in nanoseconds)
Last 60 seconds:
286 270 264 240 211 201 172
137 129 105 83 38 -5 -48
-69 -97 -148 -208 -229 -266 -336
-357 -427 -451 -500 -567 -664 -705
-772 -840 -910 -1022 -1071 -1165 -1262
-1435 -1489 -1592 -1757 -1836 -1969 -2199
-2263 -2498 -2578 -2735 -3013 -3106 -3311
-3509 -3718 -3936 -4183 -4596 -4729 -5020
-5338 -5650 -6121 -6282
Time Error range Positive Negative
---------------- -------- --------
0-20ns 0 1
20-50ns 1 1
50-100ns 1 2
100-250ns 7 3
250-500ns 3 6
500-1us 0 6
1-10us 0 29
>10us 0 0
Last 60 minutes:
-208 -3106 -16704 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0
Time Error range Positive Negative
---------------- -------- --------
0-20ns 57 0
20-50ns 0 0
50-100ns 0 0
100-250ns 0 1
250-500ns 0 0
500-1us 0 0
1-10us 0 1
>10us 0 1
Last 24 hours:
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0
Time Error range Positive Negative
---------------- -------- --------
0-20ns 24 0
20-50ns 0 0
50-100ns 0 0
100-250ns 0 0
250-500ns 0 0
500-1us 0 0
1-10us 0 0
>10us 0 0
NAT2#
Clearing Statistics
Enter clear ptp history to clear the offset, delay, and time error historical statistics.
Enter clear ptp histogram to clear the offset, delay, and time error histogram statistics.
Debugging PTP
Commands that you can use to debug PTP are listed in the following table.
|
debug ptp messages [message-type] |
Enables debugging of PTP messages. You can specify message-type to filter out the logs based on the PTP message type:
|
|
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. |
Related Documents
Feature History
|
Feature Name |
Release |
Feature Information |
|---|---|---|
|
C37.238-2017: Power Profile Support |
15.2(8)E1 |
IEEE 1588 PTPv2, C37.238-2017 Power Profile Support for Transparent Clock on IE 4000, IE 4010, and IE 5000. |
|
PTP IE5000 Horizontal Stack |
15.2(8)E |
PTP support on IE 5000 switches operating as a horizontal stack. |
|
PTP over port channels TC |
15.2(8)E |
PTP support over port channels for Transparent Clocks. |
|
PTP over port channels BC |
15.2(7)E3 |
PTP support over port channels for Boundary clock. |
|
IEC 61850-9-3 2016 profile |
15.2(7)E3 |
Configure for Power Profile in Transparent clock mode to enable. |
|
GMC Block |
15.2(7)E3 |
Initial support on IE 4000, IE 4010, and IE 5000 switches. |
|
PTP DSCP Values |
15.2(7)E3 |
Initial support on IE 4000, IE 4010, and IE 5000 switches. |
|
PTP Serviceability |
15.2(7)E1a |
Initial support on IE 4000, IE 4010, and IE 5000 switches. |
|
802.1AS Profile |
15.2(5)E2 |
Initial support on IE 4000 switches. |
|
Time Service Enhancements |
15.2(4)EA1 |
Initial support on IE 5000 switches for NTP to PTP Time Conversion, Feedforward BC, and PDV Filtering. |
|
15.2(4)EA |
Initial support on IE 4000 switches for NTP to PTP Time Conversion, Feedforward BC, and PDV Filtering. |
|
|
Precision Time Protocol |
15.2(4)EC |
Initial support of the feature on the IE 4010. |
|
15.2(2)EB1 |
Initial support of the feature on the IE 5000. |
|
|
15.2(2)EA |
Initial support of the feature on the IE 4000. |
Feedback