Network Synchronization Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.0.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the 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. Learn more about how Cisco is using Inclusive Language.
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.
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.
The following figure shows a typical 1588 PTP network that includes grandmaster clocks, routers in boundary clock mode, and
TSC mode. In this diagram, Server 1 is the grandmaster clock. If Server 1 becomes unavailable, the boundary clock clients
switch to Server 2 for synchronization.
Figure 1. PTP Network
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.
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 Profiles
Table 2. Feature History Table
Feature Name
Release Information
Description
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.
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.
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
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
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:
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:
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
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
Configuring the T-GM with GNSS as source
Note
If the server clock receives front panel inputs, skip to step b.
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
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
!
Configuring global frequency
frequency synchronization
quality itu-t option 1
clock-interface timing-mode system
!
interface HundredGigE0/0/0/1
ptp
profile 8275.2
!
frequency synchronization
!
Configuring G.8275.2 on T-BC
Configuring global SyncE
frequency synchronization
quality itu-t option 1
clock-interface timing-mode system
!
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 -->
!
interface HundredGigE0/0/0/1
ptp
profile 8275.2
!
frequency synchronization
!
!
Configuring G8275.2 on T-TSC
Configuring global SyncE
frequency synchronization
quality itu-t option 1
clock-interface timing-mode system
!
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 -->
!
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
!
!
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
!
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
!
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 3. 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.
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.
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:
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 560 Series Routers.
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
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
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_LOCKEDServo 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#
Configuring PTP Delay Asymmetry
Configure PTP delay asymmetry to offset the static delays on a PTP path that occur due to different route selection for forward
and reverse PTP traffic. Delays can also be due to any node having different delay for ingress or egress path. These delays
can impact PTP accuracy due to the asymmetry in PTP. With this feature, you can enable a higher degree of accuracy in the
PTP server performance leading to better synchronization between real-time clocks of the devices in a network.
Configuration of this delay asymmetry provides an option to configure static delays on a client clock for every server clock.
You can configure this delay value in microseconds and nanoseconds. Configured PTP delay asymmetry is also synchronized with
the Servo algorithm.
Note
If you configure multiple PTP delay asymmetries for the same PTP profile, the latest PTP delay asymmetry that you configure
is applied to the PTP profile.
For G8275.1 and G8275.2 PTP profiles, PTP delay asymmetry is supported for both, client port and dynamic port that act as
a client.
Fixed delay can be measured by using any test and measurement tool. Fixed delay can be compensated by using the positive or
negative values. For example, if the fixed delay is +10 nanoseconds, configure -10 nanoseconds to compensate the fixed delay.
A positive value indicates that the server-to-client propagation time is longer than the client-to-server propagation time,
and conversely for negative values.
Supported PTP Profiles
The following PTP profiles support the configuration of PTP delay asymmetry:
PTP over IP (G8275.2 or default profile)
PTP over L2 (G8275.1)
Restrictions
PTP delay asymmetry can be configured only on the PTP port of the grandmaster clock, which can either be a boundary clock
or an ordinary clock.
PTP delay asymmetry is supported for delay compensation of fixed cables and not for variable delay in the network.
PTP delay asymmetry can be configured within the range of 3 microseconds and -3 microseconds or 3000 nanoseconds and -3000
nanoseconds.
Configuration
To configure PTP delay asymmetry:
Configure an interface with PTP.
Configure PTP delay asymmetry on the client side.
Configuration Example
/* Configure an interface with PTP. */
Router# configure
Router(config)# interface HundredGigE 0/1/0/0
Router(config-if)# ptp
/* Configure PTP delay asymmetry on the client side. */
Router(config-if-ptp)# delay-asymmetry 3 microseconds
Router(config-if-ptp)# commit
Feedback