Precision Time Protocol (PTP) is a distributed nanosecond accuracy timing synchronization protocol for packet networks. PTP’s accuracy comes from the hardware support for PTP in the switch and server network interface cards (NICs). PTP uses multicast group 126.96.36.199 and UDP ports 319 and 320. Current PTP standard is IEEE 1588-2008 Precision Time Protocol (PTP) Version 2 (PTPv2)
The scalability of PTP comes from the fact that this protocol has a concept of Boundary Clock (BC), which can be multiple physical/logical hops away from the Grand Master (GM) clock and acts as a re-calibration point for the messages containing timestamps. The Nexus 3ks are widely deployed in Data Centres (DCs) to act as BC and provide accurate timings to the servers connected to Local Area Network (LAN). The BC and the GM need to be reachable via Layer3 (ip connectivity) only. There can be several layers of BC between the GM and the PTP end-client. There can be multiple GMs to provide redundancy and the Nexus 3K will select the best GM via Best Master Clock (BMC) algorithm.
Contributed by: Nishad Mohiuddeen
Edited by: Kumar Sridhar
N3k(config)# feature ptp
This command enables PTP on the switch.
N3k(config)# ptp source <ip address>
This command specifies the source IP address for the PTP packets generated by the switch.
N3k(config)# interface Ethernet slot/port
This command enables PTP on a port. The Cisco Nexus 3548 is a boundary clock, so it has both master and slave ports. There is no configuration difference between a master port and a slave port. They are both configured with the “ptp” option and BMC algorithm will determine whether the port is a PTP slave or master port.
N3k(config)# clock protocol ptp
This command configures the switch to use PTP to update the system calendar. This configuration keeps the clock of the switch synchronized with PTP. Not enabling this command won’t prevent the switch from propagating the PTP clock on its master ports. However, the time source will be the Nexus local clock.
N3k(config)# ptp priority1 <0-255>
N3k(config)# ptp priority2 <0-255>
Configure the priority values for the local (oscillator) clock. Lower numeric value indicates higher priority.
N3k(config)# no ptp grandmaster-capable
By default Nexus 3k is “ptp grandmaster-capable”, so disable this capability to get synched with the GM.
Optional parameters under the interface (configure to match parameter with GM):
1. Check if you can ping the GM from the PTP (unicast connectivity).
2. Check clock protocol, which should be PTP, via
N3k#show run | in clock
3. By default N3Ks are ‘grandmaster capable’. Need to disable it via
N3k# no ptp grandmaster-capable
4. Use show ptp brief command to check if port state is ‘Listening’.
5. Then do an ethanalyzer capture.
ethanalyzer local interface inbound-hi capture-filter "udp port 320" limit-captured-frames 0 <<< Announce and Follow up
ethanalyzer local interface inbound-hi capture-filter "udp port 319" limit-captured-frames 0 <<< Sync
From the PTP GM side there would be Announce and Sync messages. The client will send Delay_Req and GM will send Delay_Resp.
If no packets are captured in ethanalyzer then it may be a priority issue. If the Nexus 3k receives PTP packets with lower priority (or clock class in case of equal priority) it will discard the packet and will not punt to CPU.
6. The best way is to do packet captures (to get the packet between GM and BC) to see why the BC is not synchronizing with the GM. From the capture we can verify the PTP priority sent by GM by looking at the ‘Announce’ message coming from the GM. If the priority is lower (higher numeric value) than the configured priority in the BC, then change the PTP priority of the BC to higher numeric value.
7. If the BC (Nexus3k) is synchronized with GM but the downstream hosts/servers are not, then look for ‘Delay_Req_Messsage’ from the host/server. If not present, then there is something wrong with PTP daemon in host/server.