Understanding PTP

The Precision Time Protocol (PTP), as defined in the IEEE 1588 standard, synchronizes withnanosecond accuracy the real-time clocks of the devices in a network. The clocks in are organized into a server-client hierarchy. PTP identifies the port that is connected to a device with the most precise clock. This clock is referred to as the server clock. All the other devices on the network synchronize their clocks with the server clock and are referred to as members. Constantly-exchanged timing messages ensure continued synchronization.

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.

Table 1. Nodes within a PTP Network

Network Element

Description

Grandmaster (GM)

A network device physically attached to the primary time source. All clocks are synchronized to the grandmaster clock.

Ordinary Clock (OC)

An ordinary clock is a 1588 clock with a single PTP port that can operate in one of the following modes:

  • Server mode—Distributes timing information over the network to one or more client clocks, thus allowing the client to synchronize its clock to the server clock.

  • Client mode—Synchronizes its clock to a server clock. You can enable the client mode on up to two interfaces simultaneously in order to connect to two different server clocks.

Boundary Clock (BC)

The device participates in selecting the best server clock and can act as the server clock if no better clocks are detected.

Boundary clock starts its own PTP session with a number of downstream clients. The boundary clock mitigates the number of network hops and results in packet delay variations in the packet network between the Grandmaster and client.

Transparent Clock (TC)

A transparent clock is a device or a switch that calculates the time it requires to forward traffic and updates the PTP time correction field to account for the delay, making the device transparent in terms of time calculations.


Note

In Cisco IOS XR Release 7.3.1, on the Cisco N540-FH-CSR-SYS router, PTP is not supported on ports 0-14.

Note

In Cisco IOS XR Release 7.3.2, PTP is enabled by default on all Ethernet ports of the following variants of the Cisco NCS 540 router. This support facilitates interoperability with FPGA ports.

  • N540-FH-CSR-SYS

  • N540-FH-AGG-SYS

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 requirement for PTP data packets

Routers and Delays

In an IP network, routers provide a full-duplex communication path between network devices. Routers send data packets to packet destinations using IP address information contained in the packets. When the router attempts to send multiple packets simultaneously, the router buffers some packets so that they are not lost before they are sent. When the buffer is full, the router 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 router are stored in its local memory while the router searches the address table to verify packet 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 routers to function as PTP devices, including boundary clocks (BCs) and transparent clocks (TCs).

For more information about PTP clock devices and their role in a PTP network, see the PTP Clocks section.

Message-Based Synchronization

To ensure clock synchronization, PTP requires an accurate measurement of the communication path delay between the time source (server) and the receiver (client). PTP sends messages between the server and client device 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. The local clocks are adjusted for this delay using a series of messages sent between servers and clients. 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, routed networks do not necessarily have symmetrical communication paths, due to the various asymmetries in the network.

Using transparent clocks, PTP provides a method to measure and account for the delay in a time-interval field in network timing packets. This makes the routers temporarily transparent to the server and client nodes on the network. An end-to-end transparent clock forwards all messages on the network in the same way that a router does.

To read a detailed description of synchronization messages, see the PTP Event Message Sequences section. To learn more about how transparent clocks calculate network delays, refer to Transparent Clock, on page 7.

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 server sends a Sync message to the client and notes the time (t1) at which it was sent.

  • The client receives the Sync message and notes the time of reception (t2).

  • The server conveys to the client the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.

  • The client sends a Delay_Req message to the server and notes the time (t3) at which it was sent.

  • The server receives the Delay_Req message and notes the time of reception (t4).

  • The server conveys to the client the timestamp t4 by embedding it in a Delay_Resp message.

After this sequence, the client possesses all four timestamps. These timestamps can be used to compute the offset of the client clock relative to the server, 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 server to client is the same as the time required from client to server. This assumption is not always valid on an Ethernet/IP network due to asymmetrical packet delay times.

Figure 1. Detailed Steps—Boundary Clock Synchronization

Synchronizing the Local Clock

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

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.

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 server or client 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 interfaces to external devices.

Boundary Clock

A boundary clock in a PTP network operates in place of a standard network 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 client. The server port synchronizes the clocks connected downstream, while the client port synchronizes with the upstream server 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.

Restrictions for PTP

PTP over MPLS is not supported.

PTP Phase Difference Threshold Between Passive and Secondary Ports

Table 2. Feature History Table

Feature Name

Release Information

Feature Description

PTP Phase Difference Threshold Between Passive and Secondary Ports

Release 24.2.1

Introduced in this release on the following Cisco NCS 540 router variants running on Cisco IOS XR:

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

Passive ports can now be included in the Delay Request-Response Mechanism (DRRM), which allows for the monitoring of PTP phase differences between a passive port and a secondary port. If these PTP phase differences surpass a predefined limit, system logs are triggered. This feature enables you to detect potential errors such as fiber asymmetry or a clock failure in the PTP network.

This feature introduces these changes:

CLI:

  • phase-difference-threshold-breach

  • The show ptp foreign-masters command output is enhanced to include phase difference values and servo status.

YANG Data Models:

The following data models are enhanced:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

The Precision Time Protocol (PTP), as defined in the IEEE 1588 standard, is designed for precise time synchronization across networked devices. It operates by having Foreign Masters (FMs) broadcast timing information to interfaces within the network. The selection of the Grandmaster (GM), the primary reference clock, is determined by the Best Master Clock Algorithm (BMCA). Devices synchronize their clocks to the GM through a process known as the Delay Request-Response Mechanism (DRRM), wherein ports that are directly synchronizing with the GM enter a secondary state.

Historically, ports in a passive state—those that receive timing messages from FMs but aren’t actively syncing to the GM—didn’t participate in DRRM, which meant they didn’t synchronize their clocks.

Starting Cisco IOS XR Software Release 24.2.1, DRRM has been extended to include passive ports, enabling them to engage in the exchange of delay request and response packets. This enhancement allows for the calculation of PTP phase differences between the clocks on passive ports and the GM.

This calculated PTP phase difference provides a valuable insight into the timing characteristics of other foreign masters in the network by using the grandmaster as a reference point. It can be utilized on any boundary clock or slave clock that has connections to at least one other foreign master.

You can access these measurements and the calculated PTP phase differences using show commands through the router's CLI. Also, the information can be retrieved programmatically through operational data models in YANG, providing flexibility in how you can access and utilize this synchronization data.

Phase Difference Alarm

PTP phase difference can also be used to monitor the timing properties of the network. You can configure a value at which a bistate alarm is triggered when the PTP phase difference of a FM exceeds the threshold. The PTP phase difference can have a negative or positive value, but the threshold can only be the absolute value. You can configure the PTP phase difference threshold using the phase-difference-threshold-breach command.

System Log for PTP Phase Difference

When the configured threshold is reached, system logs (syslogs) are displayed. The following syslog is triggered if the configured PTP phase difference threshold is passed through by any master. 

Phase difference for clock ACDE48FFFE234567, steps removed 1, receiving-port 1, received on interface GigabitEthernet0/2/0/3 is 40ns, configured threshold is 30ns. Raising phase difference alarm.

Isolate Foreign Masters Causing Packet Timing Signal Fail

Table 3. Feature History Table

Feature Name

Release Information

Feature Description

Isolate Foreign Masters Causing Packet Timing Signal Fail

Release 24.2.1

Introduced in this release on the following Cisco NCS 540 router variants running on Cisco IOS XR:

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

This feature permits the flexible selection of timing sources by filtering out Foreign Master (FM) clocks that exhibit unstable timing. This filtering causes the secondary clocks to produce a signal deemed Packet Timing Signal Fail (PTSF)-unusable, from consideration within the Best Master Clock Algorithm (BMCA). The system continuously monitors these clocks for timing stabilization, and upon detecting enhanced stability, it may reevaluate and possibly reintegrate them as suitable time sources.

This feature introduces these changes:

CLI:

  • detect-ptsf-unusable

  • The show ptp foreign-masters command output is enhanced to include phase difference values and servo status.

YANG Data Models:

The following data models are enhanced:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

Starting Cisco IOS XR Software Release 24.2.1, the servo mechanism now has the ability to detect unusable clocks due to packet timing signal fail by analyzing timestamps from foreign masters. This enhancement allows the system to identify foreign masters with unstable timing as unsuitable for use. A platform supports multiple masters, such a master can be excluded from the BMCA selection process while remaining under observation for potential recovery. Even after a master is deemed unusable, the DRRM continues to operate and timestamps from it are still provided to the servo. This ongoing monitoring enables PTP to detect and respond to any improvements in the primary's timing, allowing it to be reconsidered as usable.

System Log for PTSF-unusable

When the master becomes PTSF-unusable, and if its the current Grandmaster, the following system log (syslogs) is displayed:

Foreign master with clock ID ACDE48FFFE234567, steps removed 1, receiving-port 1, received on interface GigabitEthernet0/2/0/4 is now PTSF-unusable and disqualified from selection.

PTP Profiles

Table 4. Feature History Table

Feature Name

Release Information

Description

PTP and SyncE support on breakout ports for N540-24Q8L2DD-SYS and N540X-16Z4G8Q2C-A/D Routers

Release 7.11.1

With this release, timing support for PTP and SyncE is extended to 4x10G and 4x25G breakout ports of N540-24Q8L2DD-SYS and N540X-16Z4G8Q2C-A/D Routers.

Class B and Class C performances are supported on 4x10G and 4x25G breakout ports in N540-24Q8L2DD-SYS and N540X-16Z4G8Q2C-A/D Routers.

PTP Profiles Support for N540-6Z14S-SYS-D

Release 7.5.2

PTP Profiles are now supported on the following Cisco NCS 540 router variant:

  • N540-6Z14S-SYS-D

PTP Profiles Support for N540-24Q8L2DD-SYS

Release 7.4.1

PTP Profiles are specific selections of PTP configurations that allow organizations to achieve a performance that meets the requirement of a particular application. You can configure different PTP profiles for different applications, such as audio and media. PTP profiles ensure the application components stay in sync across multiple devices.

PTP Profiles are now supported on the following Cisco NCS 540 router variant:

  • N540-24Q8L2DD-SYS

PTP and SyncE Support for N540X-8Z16G-SYS-D and N540X-8Z16G-SYS-A

 Release 7.3.1

Cisco N540X-8Z16G-SYS-D and N540X-8Z16G-SYS-A routers support PTP and SyncE:

  • Class B timing on 1 G RJ-45 ports

  • Class C timing on all 1G and 10 G fiber ports

PTP Profiles Support for N540X-16Z4G8Q2C-A/D

Release 7.0.1

PTP Profiles are now supported on the following Cisco NCS 540 router variant:

  • N540X-16Z4G8Q2C-A/D

ITU-T Telecom Profiles for PTP

Cisco IOS XR software supports ITU-T Telecom Profiles for PTP as defined in the ITU-T recommendation. A profile consists of PTP configuration options applicable only to a specific application.

Separate profiles can be defined to incorporate PTP in different scenarios based on the IEEE 1588-2008 standard. A telecom profile differs in several ways from the default behavior defined in the IEEE 1588-2008 standard and the key differences are mentioned in the subsequent sections.

The following sections describe the ITU-T Telecom Profiles that are supported for PTP.

G.8265.1

G.8265.1 profile fulfills specific frequency-distribution requirements in telecom networks. Features of G.8265.1 profile are:

  • Clock advertisement: G.8265.1 profile specifies changes to values used in Announce messages for advertising PTP clocks. The clock class value is used to advertise the quality level of the clock, while the other values are not used.

  • Clock Selection: G.8265.1 profile also defines an alternate BMCA to select port states and clocks is defined for the profile. This profile also requires to receive Sync messages (and optionally, Delay-Response messages) to qualify a clock for selection.

  • Port State Decision: The ports are statically configured to be Server or Client instead of using FSM to dynamically set port states.

  • Packet Rates: The packet rates higher than rates specified in the IEEE 1588-2008 standard are used. They are:

    • Sync/Follow-Up Packets: Rates from 128 packets-per-second to 16 seconds-per-packet.

    • Delay-Request/Delay-Response Packets: Rates from 128 packets-per-second to 16 seconds-per-packet.

    • Announce Packets: Rates from 8 packets-per-second to 64 packets-per-second.

  • Transport Mechanism: G.8265.1 profile only supports IPv4 PTP transport mechanism.

  • Mode: G.8265.1 profile supports transport of data packets only in unicast mode.

  • Clock Type: G.8265.1 profile only supports Ordinary Clock-type (a clock with only one PTP port).

  • Domain Numbers: The domain numbers that can be used in a G.8265.1 profile network ranges from 4 to 23. The default domain number is 4.

  • Port Numbers: Multiple ports can be configured; however, all ports must be of the same type, either Server or Client.

G.8275.1

G.8275.1 profile fulfills the time-of-day and phase synchronization requirements in telecom networks with all network devices participating in the PTP protocol. G.8275.1 profile with SyncE provides better frequency stability for the time-of-day and phase synchronization.

Features of G.8275.1 profile are:

  • Synchronization Model: G.8275.1 profile adopts hop-by-hop synchronization model. Each network device in the path from Server to Client clock synchronizes its local clock to upstream devices and provides synchronization to downstream devices.

  • Clock Selection: G.8275.1 profile also defines an alternate BMCA that selects a clock for synchronization and port state for the local ports of all devices in the network is defined for the profile. The parameters defined as a part of the BMCA are:

    • Clock Class

    • Clock Accuracy

    • Offset Scaled Log Variance

    • Priority 2

    • Clock Identity

    • Steps Removed

    • Port Identity

    • notSlave flag

    • Local Priority

  • Port State Decision: The port states are selected based on the alternate BMCA algorithm. A port is configured to a server-only port state to enforce the port to be a server for multicast transport mode.

  • Packet Rates: The nominal packet rate for Announce packets is 8 packets-per-second and 16 packets-per-second for Sync/Follow-Up and Delay-Request/Delay-Response packets.

  • Transport Mechanism: G.8275.1 profile only supports Ethernet PTP transport mechanism.

  • Mode: G.8275.1 profile supports transport of data packets only in multicast mode. The forwarding is done based on forwardable or non-forwardable multicast MAC address.

  • Clock Type: G.8275.1 profile supports the following clock types:

    • Telecom Grandmaster (T-GM)

    • Telecom Time subordinate/client Clock (T-TSC)

    • Telecom Boundary Clock (T-BC)

  • Domain Numbers: The domain numbers that can be used in a G.8275.1 profile network ranges from 24 to 43. The default domain number is 24.

The G.8275.1 supports the following:

  • T-GM: The telecom grandmaster (T-GM) provides timing to all other devices on the network. It does not synchronize its local clock with any other network element other than the Primary Reference Time Clock (PRTC).

  • T-BC: The telecom boundary clock (T-BC) synchronizes its local clock to a T-GM or an upstream T-BC, and provides timing information to downstream T-BCs or T-TSCs. If at a given point in time there are no higher-quality clocks available, T-BC continues to provide its own timing information to its peers, although derived clock is not as accurate as the T-GM.

  • T-TSC: The telecom time subordinate/client clock (T-TSC) synchronizes its local clock to another PTP clock (in most cases, the T-BC), and does not provide synchronization through PTP to any other device.

Performance Requirements

The router is compliant with Class B performance requirements for T-TSC and T-BC as documented in G.8273.2.

G.8275.2

The G.8275.2 is a PTP profile for use in telecom networks where phase or time-of-day synchronization is required. It differs from G.8275.1 in that it is not required that each device in the network participates in the PTP protocol. Also, G.8275.2 uses PTP over IPv4 in unicast mode.

The G.8275.2 profile is based on the partial timing support from the network. Hence nodes using G.8275.2 are not required to be directly connected.

The G.8275.2 profile is used in mobile cellular systems that require accurate synchronization of time and phase. For example, the fourth generation (4G) of mobile telecommunications technology.

Table 5. Feature History Table

Feature Name

Release Information

Description

ITU-T G.8275.2 and Default PTP profiles over IPv6

Release 7.7.1

For ITU-T G.8275.2 and the IEEE 1588 default PTP profiles, the encapsulation type for PTP packet transport is now extended to IPv6.

The transport command now accepts the keyword ipv6 .

In this release, this feature is supported on the following Cisco NCS 540 router variants:

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

  • N540-28Z4C-SYS-A/D

  • N540X-16Z4G8Q2C-A/D

  • N540-12Z20G-SYS-A/D

  • N540X-12Z16G-SYS-A/D

Features of G.8275.2 profile are:

  • Clock Selection: G.8275.2 profile also defines an alternate BMCA that selects a clock for synchronization and port state for the local ports of all devices in the network is defined for the profile. The parameters defined as a part of the BMCA are:

    • Clock Class

    • Clock Accuracy

    • Offset Scaled Log Variance

    • Priority 2

    • Clock Identity

    • Steps Removed

    • Port Identity

    • notSlave flag

    • Local Priority


    Note

    See ITU-T G.8275.2 document to determine the valid values for Clock Class parameter.

  • Port State Decision: The port states are selected based on the alternate BMCA algorithm. A port can be configured as "server-only", "client-only", or "any" mode.

  • Packet Rates:

    • Synchronization/Follow-Up—minimum is one packet-per-second and maximum of 128 packets-per-second.

    • Packet rate for Announce packets—minimum of one packet-per-second and maximum of eight packets-per-second.

    • Delay-Request/Delay-Response packets—minimum is one packet-per-second and maximum of 128 packets-per-second.

  • Transport Mechanism: G.8275.2 profile supports only IPv4 PTP transport mechanism.

  • Mode: G.8275.2 profile supports transport of data packets only in unicast mode.

  • Clock Type: G.8275.2 profile supports the following clock types:

    • Telecom Grandmaster (T-GM): Provides timing for other network devices and does not synchronize its local clock to other network devices. However, T-GM can be connected to a GPS or GNSS for deriving better clock information.

    • Telecom Time Subordinate/Client Clock (T-TSC) and Partial-Support Telecom Time Subordinate/Client Clocks (T-TSC-P): A client clock synchronizes its local clock to another PTP clock, but does not provide PTP synchronization to any other network devices.

    • Telecom Boundary Clock (T-BC) and Partial-Support Telecom Boundary Clocks (T-BC-P): Synchronizes its local clock to a T-GM or an upstream T-BC clock and provides timing information to downstream T-BC or T-TSC clocks.

  • Domain Numbers: The domain numbers that can be used in a G.8275.2 profile network ranges from 44 to 63. The default domain number is 44.

PTP Virtual Port

Feature Name

Release Information

Feature Description

PTP Virtual Port Support for N540X-12Z16G-SYS-A/D and N540-24Q8L2DD-SYS

Release 7.7.1

PTP Virtual Port is now supported on the following Cisco NCS 540 router variants:

  • N540X-12Z16G-SYS-A/D

  • N540-24Q8L2DD-SYS

PTP Virtual Port Support for Cisco NCS 540 routers

Release 7.4.1

You can now select the best available timing source for your routers by using the PTP Virtual Port feature.

This feature allows you to compare, select, and advertise the best clock source between a PTP server and other local timing sources connected to the routers.

Vitual Port is an external frequency, phase, and time input interface on a Telecom Boundary Clock (T-BC), and thus participates in the timing source selection.

G.8275.1 introduces the concept of a virtual port on the T-BC. A virtual port is an external frequency, phase, and time input interface on a T-BC, which can participate in the source selection.

Limitations

  • Assisted Partial Timing Support (APTS) is supported only for the G8275.2 non hybrid mode.

  • Virtual port is supported for G8275.1 and G8275.2 in hybrid and non-hybrid modes.

  • Virtual port configuration is not allowed under Ordinary Clocks.

  • Virtual port cannot be configured if the time of day (ToD) priority is not set under the global PTP configuration mode. Use the time-of-day priority command to set the ToD.

Assisted Partial Timing Support
Table 6. Feature History Table

Feature Name

Release Information

Description

Assisted Partial Timing Support

Release 7.7.1

Assisted Partial Timing Support (APTS) enables you to select timing and synchronization for mobile backhaul networks.

APTS is now available on the following routers:

  • N540X-12Z16G-SYS-A/D

  • N540-24Q8L2DD-SYS

APTS allows for proper distribution of phase and time synchronization in the network.

In a network having GNSS or GPS reference, all nodes (or secondary clocks) at the edge of the network follow the GNSS primary clock that runs at the core. When GNSS or GPS reference fails at the core, the secondary clocks running at the edge no longer receive accurate time stamps from the primary clock.

With the use of APTS, the nodes at the edge of the network identify GNSS or GPS as primary clock source, and PTP as the secondary source. So even if the GNSS reference is lost, the nodes fall back to the backup PTP session running between the primary clock at core and the nodes at the edge, and are thereby able to maintain an accurate time stamp.

Configuring the G.8265.1 Profile

Configuring the Client Global Configuration: Example

Master Node 

ptp
 clock
 domain 4
 profile g.8265.1 clock-type master
 profile master
  transport ipv4
  sync frequency 16
  announce interval 1
  delay-request frequency 16
interface gi 0/1/0/0
 ptp
  profile master
  transport ipv4
  port state master-only
  ipv4 address 18.1.1.1/24

Slave Node 

ptp
clock
domain 4
profile g.8265.1 clock-type slave

profile slave
transport ipv4
sync frequency 16
announce interval 1
delay-request frequency 16
interface gi 0/1/0/0
ptp
profile slave
transport ipv4
Master ipv4 18.1.1.1
port state slave-only
ipv4 address 18.1.1.2/24

Configuring the G.8275.1 Profile


Note

The Sync 2 port and GNSS receiver configuration listed below are not supported simultaneously for network synchronization. Choose only one synchronization method at a time.

Configuring the Global Settings: Example

ptp
clock
 domain 24
 profile g.8275.1 clock-type [T-BC | TGM | TTSC]
!
profile profile1
 transport ethernet
 sync frequency 16
 announce frequency 8
 delay-request frequency 16
!
 profile profile2
 transport ethernet
 sync frequency 16
 announce frequency 8
 delay-request frequency 16
 !
 !
     physical-layer-frequency    
 !

Configuring Client Port: Example

interface GigabitEthernet0/0/0/3
 ptp
  profile profile1
  multicast target-address ethernet 01-1B-19-00-00-00
  transport ethernet
  port state slave-only
  local-priority 10
!
  frequency synchronization
  selection input
  priority 1
  wait-to-restore 0
 ! 
!

Configuring Server Port: Example

interface GigabitEthernet0/0/0/1
 ptp
  profile profile2
  multicast target-address ethernet 01-1B-19-00-00-00
  port state master-only
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
 !
 frequency synchronization
 !
!

Configuring the G.8275.2 Profile


Note

The Sync 2 port and GNSS receiver configuration listed below are not supported simultaneously for network synchronization. Choose only one synchronization method at a time.

Global configuration for the telecom profile for Server clock:

ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-GM
 !
 profile master
  transport ipv4
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
!
 
interface GigabitEthernet0/0/0/11
 ptp
  profile master
 !
 ipv4 address 11.11.11.1 255.255.255.0
!

Global configuration for the telecom profile for Client clock:

Effective Cisco IOS XR Software Release 7.7.1, the encapsulation type for PTP packet transport is now extended to IPv6; you can now use the transport ipv6 to set this encapsulation type. 

ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-TSC
 !
 profile slave
  transport ipv4 
  port state slave-only
  sync frequency 64
  announce frequency 8
  delay-request frequency 64
 !
 log
  servo events
  best-master-clock changes
 !        
!
interface GigabitEthernet0/0/0/12
 ptp
  profile slave
  master ipv4 10.10.10.1
  !
 !
 ipv4 address 10.10.10.2 255.255.255.0
!

Global configuration with clock type as T-Boundary Clock (T-BC) for the telecom profile:

Effective Cisco IOS XR Software Release 7.7.1, the encapsulation type for PTP packet transport is now extended to IPv6; you can use the transport ipv6 to set this encapsulation type. 


ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-BC
 !
 profile slave
  transport ipv4 
  port state slave-only
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
 profile master
  transport ipv4
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
 log
  servo events
  best-master-clock changes
 !        
!


interface GigabitEthernet0/0/0/11
 ptp
  profile master
 !
 ipv4 address 10.10.10.2 255.255.255.0
!

interface GigabitEthernet0/0/0/12
 ptp
  profile slave
  master ipv4 10.10.10.1 
  !
 !
 ipv4 address 10.10.10.3 255.255.255.0
!

Example: Configuring G.8275.2 in Hybrid Mode

  1. Configuring Sync2

    clock-interface sync 2 location 0/RP0/CPU0
port-parameters
gps-input tod-format cisco pps-input ttl <depending on the tod format incoming : cisco/ntp4>
!
frequency synchronization
selection input
priority 1
wait-to-restore 0
quality receive exact itu-t option 1 PRC

  2. Configuring the T-GM with GNSS as source


    Note

    If the server clock receives front panel inputs, skip to step b.

    1. Enabling GNSS

      gnss-receiver 0 location 0/RP1/CPU0
no shut
constellation auto
frequency synchronization
selection input
wait-to-restore 0
quality receive exact itu-t option 1 PRC

      Note

      In Cisco IOS XR Release 7.0.1, GNSS is not supported on N540-28Z4C-SYS-A/D and N540-12Z20G-SYS-A/D variants.


      Note

      In Cisco IOS XR Release 7.3.1, GNSS is not supported on N540X-6Z18G-SYS-A/D and N540X-8Z16G-SYS-AD variants.


      Note

      In Cisco IOS XR Release 7.4.1, GNSS is not supported on the N540X-4Z14G2Q-SYS-A/D variants.

    2. Configuring global PTP

      ptp
          clock
          domain 44
          profile g.8275.2 clock-type T-GM      
         !
         profile 8275.2
        transport ipv4
        port state any
        sync frequency 64
        announce frequency 8
        delay-request frequency 64
         !
         physical-layer-frequency        
        !

    3. Configuring global frequency

      frequency synchronization
        quality itu-t option 1
        clock-interface timing-mode system
        !

    4. Enabling GPS for phase and frequency input

      clock-interface sync 2 location 0/RP0/CPU0
         port-parameters
         gps-input tod-format ntp4 pps-input ttl baud-rate 9600
         !
         frequency synchronization
         selection input
         priority 1
         wait-to-restore 0
         quality receive exact itu-t option 1 PRC
         !
         !

    5. Configuring PTP and SyncE output on port for T-GM

      interface HundredGigE0/0/0/1
    ptp
    profile 8275.2
    !
    frequency synchronization
    !

  3. Configuring G.8275.2 on T-BC

    1. Configuring global SyncE

      frequency synchronization
     quality itu-t option 1
     clock-interface timing-mode system
     !

    2. Configuring global PTP

      ptp
clock
domain 44
profile g.8275.2 clock-type T-BC
!
profile 8275.2
  transport ipv4
  port state any
  sync frequency 64
  announce frequency 8
  delay-request frequency 64
!
physical-layer-frequency  <-- This is a mandatory command -->
!

    3. Configuring Client port on Hybrid BC

      interface HundredGigE0/0/0/0
ptp
profile 8275.2
!
frequency synchronization
selection input
priority 1
wait-to-restore 0
!
!

    4. Configuring Server port on Hybrid BC

      interface HundredGigE0/0/0/1
ptp
profile 8275.2
!
frequency synchronization
!
!

  4. Configuring G8275.2 on T-TSC

    1. Configuring global SyncE

      frequency synchronization
     quality itu-t option 1
     clock-interface timing-mode system
     !

    2. Configuring global PTP

      ptp
clock
domain 44
profile g.8275.2 clock-type T-TSC
!
profile 8275.2
  transport ipv4
  port state any
  sync frequency 64
  announce frequency 8
  delay-request frequency 64
!
physical-layer-frequency  <-- This is a mandatory command -->
!

    3. Configuring Client port on Hybrid BC

      interface HundredGigE0/0/0/0
ptp
profile 8275.2
!
frequency synchronization
selection input
priority 1
wait-to-restore 0
!
!

Example: Configuring G.8275.2 in Non-Hybrid Mode

  1. Configuring Sync2

    clock-interface sync 2 location 0/RP0/CPU0
port-parameters
gps-input tod-format cisco pps-input ttl <depending on the tod format incoming : cisco/ntp4>
!
frequency synchronization
selection input
priority 1
wait-to-restore 0
quality receive exact itu-t option 1 PRC

  2. Configuring the T-GM with GNSS as source


    Note

    If the server clock receives front panel inputs, skip to step b.

    1. Enabling GNSS

      gnss-receiver 0 location 0/RP1/CPU0
frequency synchronization
selection input
wait-to-restore 0
quality receive exact itu-t option 1 PRC

      Note

      In Cisco IOS XR Release 7.0.1, GNSS is not supported on N540-28Z4C-SYS-A/D and N540-12Z20G-SYS-A/D variants.


      Note

      In Cisco IOS XR Release 7.3.1, GNSS is also not supported on N540X-6Z18G-SYS-A/D and N540X-8Z16G-SYS-AD variants.


      Note

      In Cisco IOS XR Release 7.4.1, GNSS is not supported on the N540X-4Z14G2Q-SYS-A/D variants.

    2. Configuring global PTP

      ptp
          clock
          domain 44
          profile g.8275.2 clock-type T-GM      
         !
         profile 8275.2
        transport ipv4
        port state any
        sync frequency 64
        announce frequency 8
        delay-request frequency 64
         !       
        !

    3. Enabling GPS for phase and frequency input

      clock-interface sync 2 location 0/RP0/CPU0
         port-parameters
         gps-input tod-format ntp4 pps-input ttl baud-rate 9600
         !
         
         selection input
         priority 1
         wait-to-restore 0
         quality receive exact itu-t option 1 PRC
         !
         !

    4. Configuring PTP and SyncE output on port for T-GM

      interface HundredGigE0/0/0/1
    ptp
    profile 8275.2
    !
    !

  3. Configuring G.8275.2 on T-BC

    1. Configuring global PTP

      ptp
clock
domain 44
profile g.8275.2 clock-type T-BC
!
profile 8275.2
  transport ipv4
  port state any
  sync frequency 64
  announce frequency 8
  delay-request frequency 64
!

    2. Configuring Client port on Hybrid BC

      interface HundredGigE0/0/0/0
ptp
profile 8275.2
!
selection input
priority 1
wait-to-restore 0
!
!

    3. Configuring Server port on Hybrid BC

      interface HundredGigE0/0/0/1
ptp
profile 8275.2
!
!

  4. Configuring G8275.2 on T-TSC

    1. Configuring global PTP

      ptp
clock
domain 44
profile g.8275.2 clock-type T-TSC
!
profile 8275.2
  transport ipv4
  port state any
  sync frequency 64
  announce frequency 8
  delay-request frequency 64
!

    2. Configuring Client port on Hybrid BC

      interface HundredGigE0/0/0/0
ptp
profile 8275.2
!
selection input
priority 1
wait-to-restore 0
!
!

Configuring Virtual Port

Effective Cisco IOS XR Release 7.4.1, you can configure virtual port on the G8275.1 and G8275.2 profiles in hybrid and non-hybrid modes.

For virtual port configuration to work, GNSS or Sync2 must be configured.

ptp
clock
domain 44
profile g.8275.2 clock-type T-BC
!
profile profile1
transport ipv4
sync frequency 64
clock operation one-step
announce frequency 8
delay-request frequency 64
!
virtual-port
offset-scaled-log-variance 20061
priority2 128
clock-class 6
clock-accuracy 33
local-priority 127
!
frequency priority 254
time-of-day priority 90     <<--time-of-day priority is a required parameter if you want to configure virtual port-->>
log

Configuring APTS

Effective Cisco IOS XR Release 7.4.1, you can configure APTS on the G8275.2 profile in non-hybrid mode.

ptp
apts
clock
domain 44
profile g.8275.2 clock-type T-BC
!
profile profile1
transport ipv4
sync frequency 64
clock operation one-step
announce frequency 8
delay-request frequency 64
!
virtual-port
  offset-scaled-log-variance 20061  
  priority2 128  
  clock-class 6  
  clock-accuracy 33  
  local-priority 127  
 !
 frequency priority 254 
 time-of-day priority 90 
 log

Monitor PTP virtual port using PTP timeReceiver ports

Table 7. Feature History Table

Feature Name

Release Information

Feature Description

Monitor PTP virtual port using PTP timeReceiver ports

Release 24.4.1

You can now configure a threshold value for the Time of Day (ToD) difference or offset between the PTP virtual port Global Navigation Satellite System (GNSS) and the time received by the timeReceiver ports. The timeReceiver ports receive the timing signal from remote timeTransmitters.

As part of the monitoring process, the servo mechanism in the router routinely calculates the ToD offset between the GNSS receiver and the best PTP timeTransmitter. When the offset value exceeds the configured threshold, the router raises a syslog message. Based on the generated syslog message, you can determine if you should switch from the virtual port GNSS to selecting the PTP timeTransmitter as a fallback source.

Command introduced: gm-threshold-breach threshold_value

YANG data models:

  • Cisco-IOS-XR-ptp-cfg, version 3.2.0

  • Cisco-IOS-XR-um-ptp-cfg, version 2.0.0

  • Cisco-IOS-XR-ptp-oper, version 2.3.0

See (GitHub, Yang Data Models Navigator)

Monitor PTP virtual port using PTP timeReceiver ports

The router achieves redundancy by having a primary and secondary timing source. For example, it can receive timing signals from a primary source, such as the Global Navigation Satellite System (GNSS) receiver, and secondary sources like PTP timeTransmitters.

When configuring a PTP virtual port to receive the GNSS timing signal, the router initially considers it the optimal local timing source. To monitor the quality of the virtual port signal, the servo mechanism in the router routinely calculates the Time of Day (ToD) difference, or offset, between the GNSS and the best timeReceiver port. You can now configure a ToD offset threshold value for the PTP virtual port GNSS. Threshold refers to a predefined limit or value set for the ToD offset. The router enforces the configured threshold value upon the absolute measured offset value, without any relative adjustments or considerations. If the offset exceeds the threshold, known as a threshold breach, the router sends alarm notifications as syslog messages.

Threshold configuration

Suppose you intend to configure a threshold of 1000 ns for the virtual port that receives the GNSS signal. You must configure the command as shown in the example: 

Router(config-ptp-vp)#gm-threshold-breach 1000

Threshold breach

When the offset value exceeds the configured threshold value, it is referred to as a threshold breach. If the calculated offset value is 1100 ns, it exceeds the configured threshold. Upon detecting that the virtual port has breached the threshold value, the router sends a syslog message indicating a threshold breach. You can then analyze the syslog message and determine if you should switch from the virtual port GNSS to selecting the best PTP timeTransmitter as a fallback source.

The router enforces the configured threshold value of 1000 ns on the absolute measured offset value of 1100 ns, without any relative adjustments or considerations.

Sample syslog message

The alarm notification is sent as a syslog message, and it shows that the configured threshold value is 1000 ns. However, the offset value is 1100 ns, indicating a threshold breach. 

Time of day offset between virtual port and best foreign master clock aaaafffeaaaa00,
steps removed 1, receiving port 1, received on interface GigabitEthernet0/2/0/0 is 1100 ns,
configured threshold is 1000 ns. Raising virtual port offset alarm due to threshold breach.

Supported platforms

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

Alarm conditions

The list provided explains the specific state or events that raise or clear the threshold alarm.

  • An alarm is raised when

    • the configured threshold is exceeded, for reasons such as changing the timeTransmitter.

    • a new threshold value that is lesser than the current offset is configured.

  • An alarm is cleared when

    • the offset value drops below the configured threshold.

    • the threshold value is unconfigured.

    • the virtual port is no longer the best source of timing for reasons such as configuration or clock rank change.

    • all timeTransmitters are lost.

Configure threshold to monitor PTP virtual port using PTP timeReceiver ports

Use this task to configure a threshold value to monitor the PTP Virtual Port using PTP timeReceiver timing sources.

Before you begin

Configure global SyncE and GNSS before you configure the virtual port. See the Configuration Example for more information.

Procedure

Step 1

Configure PTP.

Router(config)#ptp

Step 2

Configure the PTP virtual port.

Router(config-ptp)#virtual-port

Step 3

Configure the threshold for the PTP virtual port.

Router(config-ptp-vp)#gm-threshold-breach 1000

Note

 

The valid range is from 0 through 4,294,967,295 ns.

Configuration example

The example shows a Time-Based Clock (T-BC) consolidated configuration with Synchronous Ethernet (SyncE), GNSS, and PTP with the threshold value. 

T-BC (Middle Router Configurations)
Global SyncE Configuration
Router#configure terminal
Router(config)#frequency synchronization
Router(config-freqsync)#quality itu-t option 1
Router(config-freqsync)#clock-interface timing-mode system
Router(config-freqsync)#commit

Source GNSS Configuration
Router#configure terminal
Router(config)#gnss-receiver 0 location 0/rp0/cpu0
Router(config-gnss)#frequency synchronization
Router(config-gnss-freqsync)#selection input
Router(config-gnss-freqsync)#priority 20
Router(config-gnss-freqsync)#time-of-day-priority 100
Router(config-gnss-freqsync)#quality receive exact itu-t option 1 PRC
Router(config-gnss-freqsync)#commit

Virtual Port and Global PTP Configuration
Router#configure terminal
Router(config)#ptp
Router(config-ptp)#physical-layer-frequency
Router(config-ptp)#time-of-day priority 90
Router(config-ptp)#clock
Router(config-ptp-clock)#domain 24
Router(config-ptp-clock)#profile G.8275.1 clock-type T-BC
Router(config-ptp-clock)#time-source GPS
Router(config-ptp-clock)#timescale PTP
Router(config-ptp-clock)#virtual-port
Router(config-ptp-vp)#clock-accuracy 0x21
Router(config-ptp-vp)#clock-class 6
Router(config-ptp-vp)#local-priority 128
Router(config-ptp-vp)#priority2 50
Router(config-ptp-vp)#offset-scaled-log-variance 0x4e5d
Router(config-ptp-vp)#gm-threshold-breach 1000
Router(config-ptp-vp)#ptp
Router(config-ptp)#profile master
Router(config-ptp-profile)#transport ethernet
Router(config-ptp-profile)#sync frequency 16
Router(config-ptp-profile)#delay-req frequency 16
Router(config-ptp-profile)#announce frequency 8
Router(config-ptp-profile)#ptp
Router(config-ptp)#profile slave
Router(config-ptp-profile)#transport ethernet
Router(config-ptp-profile)#sync frequency 16
Router(config-ptp-profile)#delay-req frequency 16
Router(config-ptp-profile)#announce frequency 8
Router(config-ptp-profile)#commit
Interface Configuration
Router#configure terminal
Router(config)#interface HundredGigE0/0/1/1
Router(config-if)#ptp
Router(config-if-ptp)#profile slave
Router(config-if-ptp)#transport ethernet
Router(config-if-ptp)#local-priority 30
Router(config-if-ptp)#port state slave-only
Router(config-if-ptp)#clock operation one-step
Router(config-if-ptp)#multicast target-address ethernet 01-1B-19-00-00-00
Router(config-if-ptp)#frequency synchronization
Router(config-if-freqsync)#selection input
Router(config-if-freqsync)#priority 30
Router(config-if-freqsync)#wait-to-restore 0
Router(config-if-freqsync)#commit

Verify PTP virtual port using PTP timeReceiver ports

These commands show that the offset value is 900 ns for the virtual port. The offset value does not exceed the configured threshold value of 1000 ns. The offset value indicates no threshold breach, implying consistent timing between the GNSS receiver and the best timeReceiver port.

Before you begin

Use these show commands to verify that the offset does not exceed the configured threshold value. You can execute these commands as needed and do not have to follow a specific sequence.

Procedure

Step 1

Verify local PTP clock information.


RP/0/0/CPU0#show ptp local-clock
    Clock ID: ACDE48FFFE234567
    Clock properties:
       Domain: 0, Priority1: 7, Priority2: 83, Class: 7
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF
       Time Source: GPS
       Timescale: PTP
       Frequency-traceable, Time-traceable
       Current UTC offset: 35 seconds
    Virtual Port:
       Configured: True, Connected: True
       Offset from PTP best foreign master: 900ns

If no timeTransmitters send timestamps, the show command displays:

Offset from PTP best foreign master: none qualified

Step 2

Verify the best timeReceiver clock information.

RP/0/0/CPU0:demo#show ptp foreign-masters best
    Used to set system frequency and time
    Ipv4, Address 1.2.3.4
    Received on interface GigabitEthernet0/2/0/3 (port number 0x1007)
    Clock ID: ACDE48FFFE234567
    Best foreign-master for 5 days, 4 hours, 27 minutes
    Advertised for 5 days, 4 hours, 20 minutes
 Offset from Virtual Port: 900ns
    Clock properties:
       Domain: 0, Priority1: 7, Priority2: 83, Class: 6
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF
       Steps-removed: 5, Time Source: GPS, Timescale: PTP

If the virtual port is not configured or connected, the show command displays:

Offset from Virtual Port: not configured/not connected

If the servo cannot provide offset, the show command displays:

Offset from Virtual Port: unavailable

Step 3

Verify the timeReceiver clock information.

RP/0/0/CPU0:demo#show ptp foreign-masters 
    Used to set system frequency and time 
    Ipv4, Address 1.2.3.4 
    Received on interface GigabitEthernet0/2/0/3 (port number 0x1007) 
    Clock ID: ACDE48FFFE234567  
        Advertised for 5 days, 4 hours, 20 minutes 
    Offset from Virtual Port: 900ns 
    Received Clock properties:  
       Domain: 0, Priority1: 7, Priority2: 83, Class: 6 
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF 
       Steps-removed: 5, Time Source: GPS, Timescale: PTP

If the virtual port is not configured or connected, the show command displays:

Offset from Virtual Port: not configured/not connected

If the servo cannot provide offset, the show command displays:

Offset from Virtual Port: unavailable

Step 4

Verify the generated syslog.

Router#show logging
Router:Sep 21 06:42:39.995 UTC: ptp_ctrlr[1081]: %L2-PTP-4-VIRTUAL_PORT_OFFSET_EXCEEDED : Time of day offset between virtual port
and best foreign master clock aaaafffeaaaa00, steps removed 1, receiving port 1, 
received on interface GigabitEthernet0/2/0/0 is 1100 ns, 
configured threshold is 1000 ns. Raising virtual port offset alarm due to threshold breach.

Restriction to monitor PTP virtual port using PTP timeReceiver ports

The main restriction to consider while enforcing the threshold:

  • The threshold is only enforced on the best timeReceiver, even when the offset is reported for multiple timeReceivers.

PTP Over Bridged Virtual Interface

Table 8. Feature History

Feature Name

Release Information

Description

PTP over BVI Support on Physical Bridge-Member Subinterfaces

 Release 24.3.1

The router can now handle PTP sessions on subinterfaces that are members of a bridge group. This support is important for applications that require precise time synchronization across different VLANs or subnets within the bridge group.

PTP over BVI Support on Cisco NCS 540 Small Density Routers

 Release 7.10.1

You can now configure PTP over BVI on the following variants:

  • N540-6Z14S-SYS-D

  • N540X-6Z18G-SYS-A, N540X-6Z18G-SYS-D, N540X-8Z16G-SYS-A, N540X-8Z16G-SYS-D, N540X-4Z14G2Q-A, N540X-4Z14G2Q-D

PTP over BVI

Release 7.2.2

This feature allows PTP traffic to flow over a bridged virtual interface.

You can now configure PTP over BVI on the following variants:

  • N540-24Z8Q2C-SYS

  • N540X-ACC-SYS

  • N540-ACC-SYS

  • N540-28Z4C-SYS

  • N540-28Z4C-SYS-A

  • N540-28Z4C-SYS-D

  • N540X-16Z4G8Q2C-A

  • N540X-16Z4G8Q2C-D

  • N540X-16Z8Q2C-D

  • N540-12Z20G-SYS-A

  • N540-12Z20G-SYS-D

  • N540X-12Z16G-SYS-A

  • N540X-12Z16G-SYS-D

Limitations

  • PTP over BVI is supported only for PTP IPv4 sessions on BVI.

  • PTP over BVI is supported only on the PTP transmitter interfaces of a T-BC.

  • PTP over BVI will not work when Two-Pass Forwarding over BVI is configured. For more information on Two-Pass Forwarding over BVI refer to Interface and Hardware Component Configuration Guide for Cisco NCS 540 Series Routers.

  • BVI bridge members can be bundle interfaces. However, if the PTP transmit and receive path is across different bundle member interfaces, it may impact PTP accuracy.

Configuring PTP Over BVI

Consider the following topology:

Router BVI1 acts as PTP server or a BC node. Hosts A and B act as clients. Bridge group BG_test and bridge-domain BD_1 are part of a Layer 2 cloud.

Figure 2.
Figure 3. Sample Topology for Configuring PTP Over BVI
This image displays a topology with hosts A and B on bridge group BG_test. BG_test and bridge-domain BD_1 are part of a Layer 2 cloud.

On the PTP Server, BVI1, configure the following:

ptp
!
interface GigabitEthernet0/0/0/1
l2transport
!
Interface Bundle-Ether 100
L2transport
!
interface BVI1
ptp
  profile master
!
ipv4 address 10.10.0.4 255.255.255.0
!
l2vpn
bridge group foo
  bridge-domain bar
   interface GigabitEthernet0/0/0/0
   !
   interface GigabitEthernet0/0/0/1
   !
   Interface Bundle-Ether 100
   !
   routed interface BVI1
   !
  !
!
!

Note

Host routers A and B have the standard PTP client configuration.

Verifying PTP Over BVI

To check for the packet counters at BVI interface on the server, use the show ptp packet-counters bvi bvi-name command.

To check the state of PTP on the BVI interface on the server, use the show ptp interface brief command.

Slow Tracking

Under normal configured conditions, any change in offset triggers an immediate reaction in the servo. With the Slow Tracking feature enabled, the servo corrects the phase offset based on the configured value. If the phase offset exceeds the acceptable range, servo goes into Holdover state. In such a condition, the Slow Tracking feature becomes inactive and the servo corrects itself to the latest offset and goes into Phase locked state. Slow Tracking becomes active again.


Note

  • The supported slow tracking rate range is from 8-894 nanoseconds per second and must be in multiples of 8.

  • This feature is active only when servo is in Phase locked mode.

 
Router:# config
ptp
clock
domain 24
profile g.8275.1 clock-type T-BC
!
profile profile1
multicast target-address ethernet 01-1B-19-00-00-00
transport ethernet
sync frequency 16
clock operation one-step
announce frequency 8
delay-request frequency 16
!
physical-layer-frequency
servo-slow-tracking 16
!

PTP Holdover Traceability Suppression

Table 9. Feature History Table

Feature Name

Release Information

Feature Description

PTP Holdover Traceability Suppression

Release 7.4.1

When a device which is configured as a Boundary clock (T-BC) loses synchronization with a quality Primary clock, to ensure that the downstream nodes continue to receive the configured clock class for a specified duration, and it’s traceable you can configure this feature.

PTP Holdover Traceability Suppression for T-GM and T-GM with VP/APTS modes

Release 7.8.1

This feature extends the PTP holdover traceability suppression functionality to the devices which are in T-GM or T-GM with VP/APTS modes.

When the device loses synchronization with a quality Primary clock, to ensure that the downstream nodes continue to receive the configured clock class, and it’s traceable you can configure this feature.

This feature enables the device which is configured as a boundary clock (T-BC) with PTP Profiles G.8275.1 or G.8275.2 to send out the configured clock-class as holdover clock-class and the time traceability flag to be set as TRUE for the specified duration. This is to ensure the down-stream nodes do not have an impact as this is a deviation from prescribed G.8275.1 ITU-T standards.

The Cisco IOS XR Software Release 7.8.1 introduces the holdover traceability suppression functionality to the devices which are in T-GM or T-GM with VP/APTS modes. Prior to this release, this feature was supported on T-BC mode only.


Note

  • There are PTP flaps during switchovers or ISSU as the PTP holdover timer is running on the active RSP.

  • Once the configured holdover override duration has lapsed and the device is unable to receive a quality Primary clock within this duration, the device sends the prescribed default clock class of 165, and the traceability flag will be set as FALSE to advertise loss of clock to downstream nodes.

Configuring PTP Holdover traceability suppression

This section describes how to configure the PTP holdover traceability suppression feature:

Router# config
Router(config)# ptp
Router(config-ptp)# holdover-spec-duration 1000
Router(config-ptp)# holdover-spec-clock-class 135
Router(config-ptp)# uncalibrated-traceable-override
Router(config-ptp)# holdover-spec-traceable-override

IEEE Default Profile

The IEEE 1588 standard defines one profile, the default profile A telecom profile defines:

  • Restrictions on network technology

  • Required PTP options

  • Allowed PTP options

  • Forbidden PTP options

The IEEE 1588 Default Profile can be configured only over IP and MPLS networks.

The Default Profile requires the following PTP options:

  • The standard BMCA, with both priority fields set to 128.

  • All management messages implemented

  • Domain number zero

Example: Hybrid Default Profile

Global PTP Configuration:


ptp
 clock
  domain 0
 exit
 profile slave
  transport ipv4
  sync frequency 32
  announce frequency 2
  delay-request frequency 32
 exit
 profile master
  transport ipv4
 exit
 uncalibrated-clock-class 255 unless-from-holdover
 freerun-clock-class 255
 startup-clock-class 255
 physical-layer-frequency  <-- This is a mandatory command -->
exit

PTP Hybrid Mode

Your router allows the ability to select separate sources for frequency and time-of-day (ToD). Frequency selection can be between any source of frequency available to the router, such as: GPS, SyncE or IEEE 1588 PTP. The ToD selection is between the source selected for frequency and PTP, if available (ToD selection is from GPS or PTP). This is known as hybrid mode, where a physical frequency source (SyncE) is used to provide frequency synchronization, while PTP is used to provide ToD synchronization.

Frequency selection uses the algorithm described in ITU-T recommendation G.781, and is described in the Configuring Frequency Synchronization module in this document. The ToD selection is controlled using the time-of-day priority configuration. This configuration is found under the source interface frequency synchronization configuration mode and under the global PTP configuration mode. It controls the order for which sources are selected for ToD. Values in the range of 1 to 254 are allowed, with lower numbers.

Configuring PTP Hybrid Mode


Note

You must configure the PTP hybrid mode when using the G.8275.1 PTP profile.

Configure hybrid mode by selecting PTP for the time-of-day (ToD) and another source for the frequency. This task summaries the hybrid configuration. See the other PTP configuration modules for more detailed information regarding the PTP configurations. For more information on SyncE configurations, see the Configuring Ethernet Interfaces section in the Interface and Hardware Component Configuration Guide for Cisco NCS 540 Series Routers.

To configure PTP Hybrid mode:

  1. Configure Global Frequency Synchronization

    RP/0/RP0/CPU0:router(config)# frequency synchronization
    RP/0/RP0/CPU0:router(config)# commit
    RP/0/RP0/CPU0:router(config)# quality itu-t option [1 | 2]

  2. Configure Frequency Synchronization in Interface.

    RP/0/RP0/CPU0:router(config)# interface GigabitEthernet 0/0/0/0
RP/0/RP0/CPU0:router(config-if)# frequency synchronization
RP/0/RP0/CPU0:router(config-if-freqsync)# selection input
RP/0/RP0/CPU0:router(config-if-freqsync)# time-of-day-priority 100
RP/0/RP0/CPU0:router(config-if-freqsync)# commit

  3. Configure Global PTP

    RP/0/RP0/CPU0:router(config)# ptp
RP/0/RP0/CPU0:router(config-ptp)# time-of-day priority 1
RP/0/RP0/CPU0:router(config)# commit

  4. Configure Client Port

    RP/0/RP0/CPU0:router(config)# interface GigabitEthernet0/0/0/2 RP/0/RP0/CPU0:router(config-if)# ptp
RP/0/RP0/CPU0:router(config-if)# profile slave
RP/0/RP0/CPU0:router(config-if)# multicast target-address ethernet 01-1B-19-00-00-00 
RP/0/RP0/CPU0:router(config-if)# transport ethernet sync frequency 16
RP/0/RP0/CPU0:router(config-if)# announce frequency 8
RP/0/RP0/CPU0:router(config-if)# delay-request frequency 16
RP/0/RP0/CPU0:router(config-if)# frequency synchronization
RP/0/RP0/CPU0:router(config-if-freqsync)# selection input
RP/0/RP0/CPU0:router(config-if-freqsync)# priority 1
RP/0/RP0/CPU0:router(config-if-freqsync)# wait-to-restore 0

  5. Configure Server Port

    RP/0/RP0/CPU0:router(config)# interface GigabitEthernet0/0/0/3 
RP/0/RP0/CPU0:router(config)# ptp
RP/0/RP0/CPU0:router(config)# profile master
RP/0/RP0/CPU0:router(config)# multicast target-address ethernet 01-1B-19-00-00-00 
RP/0/RP0/CPU0:router(config)# port state master-only 
RP/0/RP0/CPU0:router(config)# transport ethernet
RP/0/RP0/CPU0:router(config)# sync frequency 16
RP/0/RP0/CPU0:router(config)# announce frequency 8
RP/0/RP0/CPU0:router(config)# delay-request frequency 16
RP/0/RP0/CPU0:router(config)# frequency synchronization
RP/0/RP0/CPU0:router(config-if-freqsync)# exit

Configure PTP for SyncE and PTP Traceability

In the hybrid mode of operation, if the SyncE and PTP clocks are coming from separate nodes and are not traceable to each other, and if the offset between the clocks is high, then the PTP-receiver may fail to synchronize with the PTP-transmitter node.

Starting with Cisco IOS XR Release 24.4.1, a new command, synchronous-ethernet prefer-interface ptp-receiver is introduced in the global frequency-synchronisation mode to ensure traceability between the PTP and SyncE clocks.

If you configure this CLI, note these points:

  • A SyncE source among equal sources 1 is selected on the same interface on which PTP is selected by the router.

  • If the SyncE source on the PTP receiver interface is inferior (in terms of QL and user configured priority) than any other available SyncE source, then the SyncE source is selected using the default criteria (based on the ITU-T G.781 requirements).

  • In the event that the selected PTP source goes down or if the PTP source's quality degrades, the system may switch to another PTP source. In such case, use the synchronous-ethernet prefer-interface ptp-receiver command so that the SyncE source selection would also switch to the new PTP receiver interface. Here, the preferred switching of SyncE source to the new PTP receiver interface shall happen only if the new interface uses the same SyncE QL and the user configured priority as the previously selected interface.


Note

The router can monitor only limited number of interfaces for SyncE selection. The synchronous-ethernet prefer-interface ptp-receiver command selects a SyncE source from the PTP receiver interface only if the interface is part of the list displayed using the show frequency synchronization selection command.

This example shows how to configure the synchronous-ethernet prefer-interface ptp-receiver command. 

RP/0/RP0/CPU0:router(config)# frequency synchronization synchronous-ethernet prefer-interface ptp-receiver
RP/0/RP0/CPU0:router(config)# commit

This example verifies the synchronous-ethernet prefer-interface ptp-receiver configuration. 

RP/0/RP0/CPU0:router(config)# show running-config frequency synchronization
Thu Aug 8 04:50:13.638 UTC
frequency-synchronization
 synchronous-ethernet prefer-interface ptp-receiver
!

Verifying the PTP Hybrid Mode Configurations

Use the following show commands to verify the configurations:

  • show ptp platform servo 

    RP/0/RP0/CPU0:ios# show ptp platform servo 
Tue Mar  5 07:08:00.134 UTC
Servo status: Running
Servo stat_index: 2
Device status: PHASE_LOCKED
Servo Mode: Hybrid
Servo log level: 0
Phase Alignment Accuracy: 0 ns
Sync timestamp updated: 8631
Sync timestamp discarded: 0
Delay timestamp updated: 8631
Delay timestamp discarded: 0
Previous Received Timestamp T1: 22521.011765183  T2: 22521.011766745  T3: 22521.018061685  T4: 22521.018063247  
Last Received Timestamp T1: 22521.073747183  T2: 22521.073748745  T3: 22521.080054957  T4: 22521.080056515  
Offset from master:  0 secs, 2 nsecs
Mean path delay   :  0 secs, 1560 nsecs
setTime():1  stepTime():1 adjustFreq():0 
Last setTime: 21984.000000000 flag:0  Last stepTime:-276573300 Last adjustFreq:0 
RP/0/RP1/CPU0:ios#

  • show running-config ptp 

    RP/0/RP0/CPU0:router# show running-config ptp
ptp
clock
domain 24
profile g.8275.1 clock-type T-BC
!
profile slave
transport ethernet
sync frequency 16
announce frequency 8
delay-request frequency 16
!
profile master
transport ethernet
sync frequency 16
announce frequency 8
delay-request frequency 16
!
!
physical-layer frequency
!

  • show running-config frequency synchronization 

    RP/0/RP0/CPU0:router# show running-config frequency synchronization
Tue Feb 6 06:36:26.472 UTC
frequency synchronization
quality itu-t option 1
clock-interface timing-mode system
!

  • show frequency synchronization interface brief 

    RP/0/RP0/CPU0:P3# show frequency synchronization interface brief

Tue Feb 6 06:37:49.234 UTC
Flags: > - Up D - Down S - Assigned for selection
d - SSM Disabled x - Peer timed out i - Init state
s - Output squelched
Fl Interface QLrcv QLuse Pri QLsnd Output driven by
==== ======================== ===== ===== === ===== ========================
>S GigabitEthernet0/0/0/2 PRC PRC 1 DNU GigabitEthernet0/0/0/2
>x GigabitEthernet0/0/0/3 Fail n/a 100 PRC GigabitEthernet0/0/0/2
>x GigabitEthernet0/0/0/4 Fail n/a 100 PRC GigabitEthernet0/0/0/2
RP/0/RP0/CPU0:P3#

Performance Monitoring for PTP Networks

Table 10. Feature History Table

Feature Name

Release Information

Feature Description

Performance Monitoring

 Release 24.3.1

You can now get statistical information with Performance Monitoring in PTP networks, such as clock accuracy, synchronization status, and network delays by defining Performance Monitoring Parameters and Port Specific Parameters.

This feature empowers operators with comprehensive performance monitoring and precise time-stamp analysis, offering enhanced granularity for time synchronization in telecommunication networks. By providing detailed insights, it enables operators to make well-informed decisions and take proactive actions to ensure optimal network performance.

The feature introduces these changes:

CLI:

YANG Data Models:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-ptp-oper.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

(see GitHub, YANG Data Models Navigator)

Performance Monitoring in PTP involves tracking and analyzing the performance of PTP networks to ensure accurate time synchronization across devices. This includes monitoring various metrics such as clock accuracy, synchronization status, and network delays. The goal is to identify and address any issues that may affect the precision and reliability of time synchronization in the network.

Performance Monitoring now has the ability to provide performance monitoring and time-stamp analysis information in a PTP network as per Annex J IEEE 1588-2019. This feature also includes additional monitoring granularity for time synchronization in telecommunication networks as per Annex F from the G8275 standard. For more information on PTP, Best TimeTransmitter Clock Algorithm (BTCA), see PTP Overview.

You can use the following parameters to define the Performance Monitoring in a PTP Network:

  • Performance Monitoring Parameters

  • Port Specific Parameters

Performance Monitoring Parameters

In addition to using the timestamps received from the grandmaster to sync to the grandmaster’s clock, the timestamps can now be used to calculate parameters that are of your interest in performance monitoring:

  • TimeTransmitter - TimeReceiver Delay: corrected propagation time from TimeTransmitter to TimeReceiver.

  • TimeReceiver - TimeTransmitter Delay: corrected propagation time from TimeReceiver to TimeTransmitter.

  • Mean Path Delay: mean propagation time over the PTP Communication Path.

  • Offset from TimeTransmitter: time difference between a TimeTransmitter PTP instance and a TimeReceiver PTP instance as computed by the TimeReceiver PTP instance.

For each of these parameters, you can measure the average, minimum, maximum, and standard deviation for each measurement. These values are calculated and maintained for the following time intervals over the specified time periods:

  • 3-minute: maintained for the current 1-hour period.

  • 15-minute: maintained for the current 24-hour period.

  • 1-hour: maintained for the current 2-hour period.

  • 24-hour: maintained for the current 48-hour period.

The platform actively calculates the end-to-end latency between the TimeTransmitter and TimeReceiver through the Delay-Request-Response-Mechanism (DRRM), allowing Precision Time Protocol (PTP) to seamlessly operate across networks equipped with Transparent clocks, non-PTP aware switches, or a mix of both. Upon a request, PTP dynamically extracts these calculated values from the servo using a platform specific API, allowing you to make proactive changes to the network to ensure precise time synchronization essential for applications that depend on accurate timing.

Additional Port Specific Parameters

The parameters mentioned above apply to the entire Precision Time Protocol (PTP) instance, and there is an additional set of parameters specific to individual ports. These parameters include the counters for various packet types,

  • received (rx) and

  • transmitted (tx)

It is important to collect and maintain these counters for performance monitoring purposes, which follows the same time intervals and periods as those used for monitoring clock performance.

Port-specific parameters play a crucial role in ensuring accurate time synchronization. These packet types are essential for maintaining the accuracy and reliability of time synchronization in a PTP network:

  • Sync Packets: These packets are sent by the master clock to the slave clocks to synchronize their time. They contain the precise time at which the packet was sent.

  • Delay Request Packets: Sent by the slave clock to the master clock, these packets measure the delay between the master and slave clocks. The master clock responds with a Delay Response packet.

  • Follow-Up Packets: These packets are sent by the master clock immediately after the Sync packet. They contain the exact time the Sync packet was sent, which helps in correcting any delays introduced by the network.

  • Announce Packets: These packets are used by the master clock to announce its presence and capabilities to the slave clocks. They help in the selection of the best master clock in the network.

  • Management Packets: These packets are used for configuration and management purposes within the PTP network. They allow for the adjustment of various parameters and settings.

Record format

Record format refers to the structure or layout of data within a record, which is used to store information about time synchronization events and measurements. This format can include various fields such as timestamps, event types, and other relevant data that PTP uses to maintain accurate time synchronization across a network. It is a single buffer for both annexes.

The format is the same for both clock and port performance monitoring parameters that is presented in the operational data. The data is stored over a 48-hour period, resulting in a list of records as per Annex J 1588-2019, composed of the following:

  • 1 record for the current 15-minute set of statistics (stored at position 0 in the buffer).

  • 96 records for the 15-minute sets of statistics over the last 24-hour period (stored between positions 1-96 in the buffer).

  • 1 record for the current 24-hour set of statistics (stored at position 97 in the buffer).

  • 1 record for the previous 24-hour set of statistics (stored at position 98 in the buffer).

The data buffer records data at 3-minute intervals over the most recent 1-hour period, creating a list of records that includes:

  • 1 record for the current 3-minute set of statistics (stored at position 100 in the buffer).

  • 20 records for the 3-minute set of statistics over the last 1-hour period (stored between positions 101-120).

  • 1 record for the current 1-hour set of statistics (stored at position 121 in the buffer).

  • 1 record for the previous 1-hour set of statistics (stored at position 122 in the buffer).

Configure PTP Performance Monitoring

The purpose of this task is to configure and verify PTP performance monitoring.

Procedure

Step 1

Configure the performance-monitoring command to enable collection of performance monitoring statistics and for the users to make performance monitoring requests.

Example:


Router(config)# ptp
Router(config-ptp)# performance-monitoring
Router(config-ptp)# commit

Step 2

Run the sh ptp platform performance-counters command to display the details of all 123 records.

The existing command show ptp platform is extended to include the performance monitoring data for the local clock. The detail mode of the command displays all 123 records while the brief mode displays only the current windows for 15 minutes, 24 hours, 3minutes, and 1hour.

Example:


Router#sh ptp platform performance-counters detail 

PTP Current record index 15 min: 96
PTP Current record index 3 min: 119

PTP performance monitoring statistics: 
==============================================================================================================
15 min stats
[0]     12 August 2024 07:08:59 UTC 15 min statistics
--------------------------------------------------------------------------------------------------------------
                Stat    Min(sec.nsec)        Max(sec.nsec)       Mean(sec.nsec)     Std deviation           Samples
--------------------------------------------------------------------------------------------------------------
  Master-slave-delay -000000000.15937      000000000.333       -000000000.1780       000000000.71191      154       
  Slave-master-delay  000000000.319        000000000.16593      000000000.2437       000000000.74103      154       
     mean-path-delay  000000000.322        000000000.334        000000000.327        000000000.4057       154       
  offset-from-master -000000000.16263      000000000.6         -000000000.2108       000000000.72546      154       

--------------------------------------------------------------------------------------------------------------
            Complete      Valid      PmRef      ServoAtStart     ServoAtEnd          LastServoFlapTime
--------------------------------------------------------------------------------------------------------------
               FALSE      FALSE       TRUE        PHASE_LOCKED   HOLDOVER               12 Apr 2024 07:09:09 UTC 

==============

….

Step 3

Run the show ptp dataset performance clock command to display the performance monitoring data-set details in 15 minutes intervals.

Example:


Router#show ptp dataset performance clock

performanceMonitoringDS for the current 15-minute window:
Clock ID ccccfffecccc00, steps removed 1, receiving-port 2:
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is valid
    Period is complete
    Measurement has been taken with reference to system clock
    Master slave delay:
        Average: 50ns
        Min: 50ns
        Max: 70ns
        Std: 1ns
    Slave master delay:
        Average: 51ns
        Min: 51ns
        Max: 71ns
        Std: 2ns
    Mean path delay:
        Average: 52ns
        Min: 52ns
        Max: 72ns
        Std: 3ns
    Offset from master:
        Average: 53ns
        Min: 53ns
        Max: 73ns
        Std: 4ns

Clock ID aaaabbbecccc00, steps removed 1, receiving-port 2:
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is not valid
    Period is not complete
    Measurement has been taken with reference to system clock
    Master slave delay:
        Average: 50ns
        Min: 50ns
        Max: 70ns
        Std: 1ns
    Slave master delay:
        Average: 51ns
        Min: 51ns
        Max: 71ns
        Std: 2ns
    Mean path delay:
        Average: 52ns
        Min: 52ns
        Max: 72ns
        Std: 3ns
    Offset from master:
        Average: 53ns
        Min: 53ns
        Max: 73ns
        Std: 4ns

Step 4

Run the show ptp dataset performance port to display the Performance Monitoring Port Data-set in 15 minutes intervals.

Example:

Router#show ptp dataset performance port GigabitEthernet 0/0/0/1

performanceMonitoringPortDS for the current 15-minute window:
Interface GigabitEthernet 0/0/0/1
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is valid
    Period is not complete
    Measurement has been taken with reference to system clock
    Packets                     Sent        Received         Dropped
    ----------------------------------------------------------------
    Announce                       3              83              11
    Sync                           0              32               5
    Follow-Up                      0              31               0
    Delay-Req                     22               0               0
    Delay-Resp                     0              21               7
    Pdelay-Req                     0               7               0
    Pdelay-Resp                    0               0               0
    Pdelay-Resp-Follow-Up          0               0               0
    Signaling                      2               1               0
    Management                     0               0               0
    Other                          0               3              12
                               -----           -----           -----
    TOTAL                         27             178              35

PTP Profile Interoperation

Table 11. Feature Hisstory Table

Feature Name

Release Information

Description

PTP Profile Interoperation

Release 7.2.1

PTP profile interoperation enables users to deploy newer profiles in a network containing older devices that do not support these profiles. This support allows for a gradual upgrade path.

For this release, interoperation is supported only between the G.8275.1 and G.8275.2 profiles.

PTP Profile Interoperation

Release 7.5.1

Support for this feature is now extended on the following Cisco NCS 540 router variants:

  • N540-FH-CSR-SYS

  • N540-FH-AGG-SYS

  • N540X-6Z18G-SYS-A/D

  • N540X-8Z16G-SYS-A/D

  • N540X-4Z14G2Q-A/D

For this release, interoperation is extended between default, G.8275.1, and G.8275.2 profiles.

PTP profile interoperation occurs when a device that is running a particular profile is also configured to interoperate with one or more peer clocks that are running different profiles. To enable this behavior, use the ptp interop profile profile command to configure the interfaces that are connected to such peer clocks to interoperate.

For each such interface, the following configuration are available:

  • Profile of the peer clock. If the profile is not specified, the profile of the local clock is used.

  • Domain Number of the peer clock. If not specified, the domain number of the local clock is used. Incoming PTP messages with a different domain number are dropped.

  • The Ingress-Conversion behavior. This behavior allows you to specify how to convert the clock properties received in incoming Announce messages.

    • The Priority1 and Priority2 values. If not specified, the default mapping is applied.

    • The ClockAccuracy value. If not specified, the default mapping is applied.

    • The OffsetScaledLogVariance value. If not specified, the default mapping is applied.

    • Any number of Clock-Class-Mappings. These mappings override the default mappings whenever present.

    • The Clock-Class-Default value. If present, this value is used for all clock class values for which a more specific mapping is not configured.

  • The Egress-Conversion behavior: This behavior allows you to specify how to convert the clock properties sent in outgoing Announce messages. The options are the same as for Ingress-Conversion.

Consider the following example:

Figure 4. Simple Illustration of PTP Profile Interoperation

Router R1 (acting as grandmaster clock) is running the profile G.8275.2 through Path A towards router R2. R2 acts as a boundary clock and is running profile G.8275.1. The egress interface of R2 is an interop port that converts profile G.8275.2 to G.8275.1.

The profile G.8275.1 is carried over Path B toward the ordinary clock or router R3.

Configure the following on the interop port of Boundary Clock ‘B’:

interface TenGigE0/0/0/15
 ptp
  interop
   profile g.8275.1
   domain 24
  !
  multicast target-address ethernet 01-1B-19-00-00-00
  transport ethernet
  port state master-only
  sync frequency 64
  clock operation one-step
  announce interval 1
  delay-request frequency 32
 !
 frequency synchronization

Verifying PTP Interoperation

Run the following show commands on the interop port of R2 (see the figure above):

RP/0/RP0/CPU0:R2# show ptp platform servo 
Sat Jul  3 17:28:50.107 UTC
Servo status: Running
Servo stat_index: 2
Device status: PHASE_LOCKED
Servo Mode: Hybrid
Servo log level: 0
Phase Alignment Accuracy: 1 ns
Sync timestamp updated: 24668
Sync timestamp discarded: 0
Delay timestamp updated: 24668
Delay timestamp discarded: 0
Previous Received Timestamp T1: 1625246930.271485001  T2: 1625246930.271485039  T3: 1625246930.280721326  T4: 1625246930.280 
Last Received Timestamp T1: 1625246930.333474633  T2: 1625246930.333474671  T3: 1625246930.344744853  T4: 1625246930.3447448 
Offset from master: -0 secs, 1 nsecs
Mean path delay   :  0 secs, 25 nsecs
setTime():1  stepTime():2 adjustFreq():12246 
Last setTime: 1625245327.000000000 flag:0  Last stepTime:141500000 Last adjustFreq:5 

RP/0/RP0/CPU0:JAGUAR# show ptp interop        
Sat Jul  3 17:28:53.477 UTC
Interface TenGigE0/0/0/15

  Egress Conversions:
    Profile:                 G.8275.2 -> G.8275.1
    Domain:                        44 -> 24
    Priority1:                    128 -> 128
    Priority2:                    128 -> 128
    ClockClass:                     6 -> 6
    ClockAccuracy:               0x21 -> 0x21
    OffsetScaledLogVariance:   0x4e5d -> 0x4e5d

  Ingress Conversions:
    This port is not receiving Announce messages


RP/0/RP0/CPU0:R2# show ptp interfaces brief 
Sat Jul  3 17:37:09.018 UTC
Intf              Port         Port                  Line
Name              Number       State        Encap    State         Mechanism
--------------------------------------------------------------------------------
Te0/0/0/13        1            Slave        IPv4     up            1-step DRRM
Te0/0/0/15        2            Master       Ethernet up            1-step DRRM

RP/0/RP0/CPU0:R2# show ptp advertised-clock 
Sat Jul  3 17:48:28.691 UTC
Clock ID: 8a96fffef6a0d8
Clock properties:
  Domain: 44, Priority1: 128, Priority2: 128, Class: 6
  Accuracy: 0x21, Offset scaled log variance: 0x4e5d
  Time Source: GPS
  Timescale: PTP
  Frequency-traceable, Time-traceable
  Current UTC offset: 37 seconds (valid)
1 sources equal in their advertised QL and user configured priority