NTP - Network Time Protocol ============================== .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **What is NTP?** * NTP stands for Network Time Protocol. It’s a protocol used to synchronize the clocks of computers and other devices over a network to a precise time source, like an atomic clock or GPS. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Why is NTP useful?** * Without NTP, devices would have different system times, which can cause problems in: * Logging and auditing * Scheduled tasks * Security protocols * Time-sensitive applications (e.g., financial transactions) * NTP ensures that all devices on a network agree on the correct time, improving coordination and reliability. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **How it works?** * Device requests time – A device sends a request to an NTP server asking for the current time. * NTP server responds – The server replies with the accurate time. * Device adjusts its clock – The device calculates the time difference and updates its system clock. * Periodic updates – Devices regularly check in with NTP servers to stay in sync. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Where is NTP used?** * Home devices – Computers, phones, and routers use NTP to keep accurate time. * Enterprise networks – Servers and workstations synchronize time for logging, backups, and security. * Data centers – Precise time is critical for coordinating distributed systems. * Financial systems – Accurate timestamps are essential for transactions and compliance. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Which OSI Layer Does NTP Belong To?** * NTP belongs to the **Application Layer (Layer 7)** of the OSI model because: * It provides a time synchronization service directly to applications and users. * Uses UDP (typically port 123) to exchange time information. * Involves high-level communication between client and server, characteristic of Layer 7 protocols. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow Topics in this section, * :ref:`Learnings in this section ` * :ref:`Terminology ` * :ref:`Version Info ` * :ref:`NTP Version&RFC Details ` * :ref:`NTP Basic Setup on Ubuntu using IPv4 ` * :ref:`NTP Basic Setup on Ubuntu using IPv6 ` * :ref:`NTP Protocol Packet Details ` * :ref:`NTP Usecases ` * :ref:`NTP Basic Features ` * :ref:`NTP Feature : Time Synchronization ` * :ref:`NTP Feature : Hierarchical Architecture ` * :ref:`NTP Feature : High Accuracy ` * :ref:`NTP Feature : Fault Tolerance ` * :ref:`NTP Feature : Clock Filtering and Selection ` * :ref:`NTP Feature : Security Support (NTPv4) ` * :ref:`NTP Feature : Support ` * :ref:`NTP Feature : Dynamic Server Discovery ` * :ref:`NTP Feature : Cross-Platform Compatibility ` * :ref:`NTP Feature : Low Bandwidth Usage ` * :ref:`Reference links ` .. _NTP_step1: .. tab-set:: .. tab-item:: Learnings in this section * In this section, you are going to learn .. _NTP_step2: .. tab-set:: .. tab-item:: Terminology * Terminology .. _NTP_step3: .. tab-set:: .. tab-item:: Version Info * Version Info .. _NTP_step5: .. tab-set:: .. tab-item:: NTP Version&RFC Details .. csv-table:: :file: ./NTP/ntp_rfc_details.csv :widths: 10,10,10,30 :header-rows: 1 .. _NTP_step20: .. tab-set:: .. tab-item:: NTP Basic Setup on Ubuntu using IPv4 **NTP Server Availability Test Case** * To ensure that the NTP server (e.g.,pool.ntp.org) is reachable and responding to time synchronization requests. This confirms the availability and responsiveness of the server for time services. * Step-1: Ping the NTP Server. .. code-block:: shell test:~$ping -c 5 pool.ntp.org PING pool.ntp.org (95.216.192.15) 56(84) bytes of data. 64 bytes from ntp1.ggsrv.de (95.216.192.15): icmp_seq=1 ttl=40 time=205 ms 64 bytes from ntp1.ggsrv.de (95.216.192.15): icmp_seq=2 ttl=40 time=228 ms 64 bytes from ntp1.ggsrv.de (95.216.192.15): icmp_seq=3 ttl=40 time=251 ms 64 bytes from ntp1.ggsrv.de (95.216.192.15): icmp_seq=4 ttl=40 time=275 ms 64 bytes from ntp1.ggsrv.de (95.216.192.15): icmp_seq=5 ttl=40 time=197 ms --- pool.ntp.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4002ms rtt min/avg/max/mdev = 196.561/231.214/274.950/29.027 ms * Step-2: (Optional) Query the NTP Server using an NTP Client. This sends an NTP request and receives a time response. .. code-block:: shell test:~$ntpdate -q pool.ntp.org 2025-07-25 10:43:47.396384 (+0530) +0.479906 +/- 0.618937 pool.ntp.org 95.216.192.15 s2 no-leap * Step-3: Capture and analyze packets in Wireshark. * Expected result: * Ping Response - The server should respond to ICMP echo requests with no or minimal packet loss. * NTP Packet Exchange - Client request and Server response Packets. * Step-4: Wireshark Capture :download:`Download wireshark capture ` **NTP Server Response Verification** * To ensure that the NTP server responds correctly to time synchronization requests from an NTP client, and client can successfully update its system time using the received data. * Step-1: Install and Start NTP Services. .. code-block:: shell test:~$sudo apt update test:~$sudo apt install ntp test:~$sudo systemctl start ntp test:~$sudo systemctl status ntp * Step-2: Install NTPSEC Utility for direct query. .. code-block:: shell test:~$sudo apt install ntpsec-ntpdig * Step-3: Query NTP Server Using ntpdig. This queries multiple NTP servers in the pool for accurate time data. .. code-block:: shell test:~$ntpdig pool.ntp.org 2025-07-25 11:02:44.193688 (+0530) +2.337326 +/- 2.750659 pool.ntp.org 95.216.144.226 s2 no-leap * Expected result: * The client should receive valid time responses from the NTP server. * System time should be updated or synchronized based on the received data. * Step-4: Wireshark Capture :download:`Download wireshark capture ` **Multiple NTP Server Responses Test Case** * To verify that the NTP client can communicate with multiple NTP servers for redundancy and select the most accurate server based on synchronization metrics such as delay, offset, and jitter. * Step-1: Configure Multiple NTP servers. .. code-block:: shell test:~$sudo nano /etc/ntp.conf #Add the following lines and save, exit the file server pool.ntp.org server time.google.com server time.windows.com * Step-2: Restart NTP service. .. code-block:: shell test:~$sudo systemctl restart ntp * Step-3: Verify Server Communication. .. code-block:: shell test:~$ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================================================= 0.ubuntu.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0005 1.ubuntu.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0005 2.ubuntu.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0005 3.ubuntu.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0005 prod-ntp-4.ntp1.ps5.canonical.com .STEP. 16 u - 1024 0 0.0000 0.0000 0.0005 +160.250.111.68 15.207.248.194 5 u 380 512 77 33.8858 -7.1772 23.2023 +www.time.nplindia.org .PPS. 1 u 404 1024 77 109.4294 -34.2470 29.5893 +ec2-65-0-119-56.ap-south-1.compute.amaz 169.254.169.123 4 u 383 512 77 24.4830 -0.3120 67.3801 +ntp-pool.time.4v1.in 139.59.15.185 6 u 441 1024 77 29.7021 -4.0310 37.7688 #ntp6.mum-in.hosts.301-moved.de 129.69.253.1 2 u 352 512 77 127.7853 -44.4622 44.2995 +160.250.111.199 14.139.60.106 2 u 440 1024 77 48.6330 -14.7381 34.4310 +40.81.94.65 10.0.6.21 3 u 387 512 77 26.2339 -0.9031 31.8296 +keralavisionisp-dynamic-31.84.59.137.ke 160.250.111.68 6 u 355 512 77 28.0111 -7.9955 25.7496 #ntp1.ggsrv.de 134.71.66.21 2 u 518 1024 77 286.5653 -57.9884 28.9191 +ec2-13-126-27-131.ap-south-1.compute.am 14.139.60.103 2 u 384 512 77 24.3805 -0.4415 39.7327 +ntp1.blr.in.hojmark.net 14.139.60.107 2 u 388 512 77 9.0280 -1.9096 62.2897 +ntp2.ggsrv.de 134.71.66.21 2 u 435 1024 77 227.1993 -24.6891 30.3548 * www.time.nplindia.org .PPS. 1 u 403 512 77 42.1376 -7.4883 69.0713 #ntp5.mum-in.hosts.301-moved.de 193.190.230.65 2 u 407 1024 77 106.3636 -38.4540 86.0079 +ec2-13-200-20-166.ap-south-1.compute.am 169.254.169.123 4 u 430 1024 77 39.6717 -10.6077 46.2089 #mail.nplindia.org .PPS. 1 u 482 1024 75 149.3471 -49.0882 22.6066 #103.189.191.15 14.139.60.103 2 u 565 1024 77 66.9174 4.4967 303.3041 #ec2-15-207-248-194.ap-south-1.compute.a 169.254.169.123 4 u 466 1024 77 112.4516 -42.9446 54.6964 +inbom5-ntp-002.aaplimg.com 17.253.60.253 2 u 378 512 77 28.3553 -0.1714 59.8335 .. note:: This command displays the list of NTP servers the client is communicating with, including server address, synchronization status, delay, offset, jitter. * Step-4: Capture and analyze packets in wireshark. * Expected result: * The client should send requests to all configured servers. * The client should select the best server for synchronization based on accuracy metrics. * Step-5 : Wireshark Capture :download:`Download wireshark capture ` **NTP Request Response Delay under Network Latency Test Case** * To verify that the NTP client can handle delayed responses from the NTP server due to simulated network latency, and still synchronize time within accetable limits. * Step-1: Query NTP server Under normal conditions. .. code-block:: shell test:~$sudo ntpdate pool.ntp.org 2025-07-25 13:08:02.214230 (+0530) -0.411155 +/- 0.137221 pool.ntp.org 95.216.192.15 s2 no-leap * Step-2: Simulate Network Delay. .. code-block:: shell test:~$sudo tc qdisc add dev root netem delay 100ms .. note:: Replace with actual network interface(e.g.,eth0,wlp2s0,enp0s3) * Step-3: Query the NTP server again. .. code-block:: shell test:~$sudo ntpdate pool.ntp.org 2025-07-25 13:08:10.906238 (+0530) -0.372080 +/- 0.170808 pool.ntp.org 95.216.192.15 s2 no-leap * Step-4: Remove Network delay. .. code-block:: shell test:~$sudo tc qdisc del dev root * Step-5: Capture and analyze packets in wireshark. * Expected result: * Normal Conditions- NTP request and response should occur with minimal delay. Time synchronization should complete quickly. * With Simulated delay- NTP response should be delayed by approximately the condigured latency (e.g., 100ms). Time synchronization should still succeed, with slightly increased offset and delay values. * Step-6 : Wireshark Capture :download:`Download wireshark capture ` **NTP Client Behaviour During Time Zone Change Test Case** * To verify that the NTP client continues to function correctly and maintains accurate system time when the system time zone is changed manually. * Step-1: Synchronize Time with NTP server. .. code-block:: shell test:~$sudo ntpdate time.google.com 2025-07-25 14:01:12.331256 (+0530) -0.028377 +/- 0.065796 time.google.com 216.239.35.0 s1 no-leap * Step-2: Change System time zone. .. code-block:: shell test:~$sudo timedatectl set-timezone America/New_York * Step-3: Resynchronize with NTP server. .. code-block:: shell test:~$sudo ntpdate time.google.com 2025-07-25 04:31:26.294259 (-0400) +0.017640 +/- 0.153789 time.google.com 216.239.35.4 s1 no-leap .. note:: To revert to Original Time zone - sudo timedatectl set-timezone Asia/Kolkata * Step-4: Capture and analyze packets in wireshark. * Expected result: * NTP client should succesfully synchronize time before and after the time zone change. * Wireshark NTP packets will show consistent UTC timestamps. Time zone changes are not visible in packet data (handled at the OS level). * Step-5: Wireshark Capture :download:`Download wireshark capture ` **NTP Verify Leap Second Handling Test Case** * To verify that the NTP server correctly handles leap second events and that the NTP client can interpret and respond to leap second indicators appropriately. * Step-1: Query the NTP server. Thsi sends a query to the NTP server and displays the time along with leap second status. .. code-block:: shell test:~$ntpdate -q time.nist.gov 2025-07-25 14:11:02.761912 (+0530) +0.011392 +/- 0.135807 time.nist.gov 132.163.97.4 s1 no-leap * Step-2: Capture and analyze packets in wireshark. * Expected result: * NTP client should successfully query the NTP server and receive a valid response, including leap second status. * The Leap Indicator (LI) field in the NTP response should be correctly set: * 0 → No leap second pending (normal case) * 1 → Leap second scheduled (rare, only shortly before an official event) * Wireshark should display: * NTP packet with Leap Indicator field under "Flags" * A value of no warning (0) in most cases * last minute has 61 seconds (1) only if a leap second is scheduled * Step-3: Wireshark Capture :download:`Download wireshark capture ` **NTP Verify Time zone Handling Test Case** * To verify that the NTP client Synchronizes time in UTC from the NTP server, adjusts and displays the correct local time based on the system's configured time zone. * Step-1: Set time zone to UTC (Coordinated Universal Time) .. code-block:: shell test:~$sudo timedatectl set-timezone UTC test:~$timedatectl | grep "Time zone" Time zone: UTC (UTC, +0000) * Step-2: Sync with NTP Server .. code-block:: shell test:~$sudo ntpdate time.google.com 2025-07-25 09:10:17.384603 (+0000) +0.035151 +/- 0.085497 time.google.com 216.239.35.4 s1 no-leap test:~$date -u #UTC time Fri Jul 25 09:10:41 AM UTC 2025 test:~$date #Local time (should match UTC) Fri Jul 25 09:10:41 AM UTC 2025 * Step-3: Change Time Zone to America/New_York .. code-block:: shell test:~$sudo timedatectl set-timezone America/New_York test:~$date -u #Should remian unchanged (still UTC) Fri Jul 25 09:11:07 AM UTC 2025 test:~$date #Should reflect New York local time Fri Jul 25 05:11:10 AM EDT 2025 * Step-4: Capture and analyze packets in wireshark. * Expected result: * The system time is synchronized in UTC. * Changing the timezone affects only the displayed local time, not the underlying UTC time. * Wireshark captures show NTP packets but not time zone conversions (as they are handled at the OS level). * Step-5: Wireshark Capture :download:`Download wireshark capture ` **NTP Verify Time Synchronization Test Case** * To verify that the NTP client correctly synchronizes its system time with the NTP server, even when the local time is manually set to an incorrect value. * Step-1: Set Incorrect System time. .. code-block:: shell test:~$sudo date --set="2025-01-01 00:00:00" Wed Jan 1 12:00:00 AM IST 2025 * Step-2: Synchronize time with NTP server .. code-block:: shell test:~$sudo ntpdate pool.ntp.org 2025-07-25 14:52:38.376695 (+0530) +17765495.955948 +/- 0.101456 pool.ntp.org 192.46.211.253 s2 no-leap CLOCK: time stepped by 17765495.955948 CLOCK: time changed from 2025-01-01 to 2025-07-25 * Step-3: Verify Updated system time. .. code-block:: shell test:~$date Fri Jul 25 02:53:06 PM IST 2025 * Step-4: Capture and analyze packets in wireshark. * Expected result: * The system time should be corrected to match the time provided by the NTP server. * Wireshark shows NTP client and server packets. Actual time correction is handled at the system level and not visible in packet captures. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **NTP C Packet Generation Code (Symmetric Active and Passive)** * This C program demonstrates how to craft and send custom NTP packets in symmetric mode: * Symmetric Active (mode 1)** — typically used by peers to initiate communication. * Symmetric Passive (mode 2)** — sent in response to a symmetric active packet. * The code manually constructs an NTP packet, sets essential fields like transmit timestamp and mode, and sends it over UDP to a specified peer IP. * This low-level interaction is useful for simulating peer-to-peer NTP behavior, testing NTP firewalls, or understanding packet structures beyond client-server models. * Replace the IP address (192.168.1.100) in the code with your actual NTP peer before running. * Step-1: Download C source code for symmetric active and passive packet generation. :download:`Download C source code ` * Step-2: Convert c code to executable file. .. code-block:: shell test:~$gcc NTP_Symmetric_Active_Passive_Code.c -o NTP_Symmetric_Active_Passive_Code test:~$./NTP_Symmetric_Active_Passive_Code NTP packet sent (mode 1) to 192.168.1.100 NTP packet sent (mode 2) to 192.168.1.100 * Step-3: Wireshark Capture :download:`Download wireshark capture ` **NTP Control Packet Generation Code** * This C program demonstrates how to manually craft and send an NTP control message** using Mode 6 (Control) with Opcode 2 (Read Status). * It directly interacts with an NTP server over UDP port 123 and requests status information (assoc ID 0 for system peer). * Useful for inspecting NTP server behavior, debugging peer states, or learning about the control message format. * The packet structure strictly follows NTP's control message format and uses `#pragma pack(1)` to avoid padding. * Replace the IP address argument with the target NTP server before execution. * Step-1: Download C source code for control packet generation. :download:`Download C source code ` * Step-2: Compile and run the program with an NTP server IP as argument. .. code-block:: shell test:~$ gcc NTP_Control_Packet_Read_Status.c -o NTP_Control_Packet test:~$ ./NTP_Control_Packet 192.168.1.100 Sent 12 bytes to 192.168.1.100 (NTP Control Message, Opcode 2) * Step-3: Wireshark Capture :download:`Download wireshark capture ` **NTP Broadcast Packet Generation Code (Mode 5)** * This C program constructs and sends an NTP broadcast packet using Mode 5, intended for automatic time synchronization in a LAN. * It sets up a UDP socket with broadcast capability and sends the NTP packet to a specified **broadcast IP** (e.g., `192.168.1.255`). * The packet includes standard fields such as reference timestamp, stratum, root delay, and transmit timestamp, formatted per NTP standards. * Useful for simulating NTP servers broadcasting time to multiple clients in a local network. * The code handles endianness for 64-bit timestamps to ensure compatibility across platforms. * Replace the broadcast IP with your network's broadcast address before running. * Step-1: Download C source code for broadcast packet generation. :download:`Download C source code ` * Step-2: Compile and run the program with a broadcast IP as argument. .. code-block:: shell test:~$ gcc NTP_Broadcast_Packet_Code.c -o NTP_Broadcast_Packet test:~$ ./NTP_Broadcast_Packet 192.168.1.255 Broadcast NTP packet sent to 192.168.1.255 (48 bytes) * Step-3: Wireshark Capture :download:`Download wireshark capture ` .. _NTP_step21: .. tab-set:: .. tab-item:: NTP Basic Setup on Ubuntu using IPv6 * Setup .. _NTP_step6: .. tab-set:: .. tab-item:: NTP Protocol Packet Details **Symmetric Active Packet** .. csv-table:: :file: ./NTP/ntp_packet1_details.csv :widths: 10,20,30,10 :header-rows: 1 **Symmetric Passive Packet** .. csv-table:: :file: ./NTP/ntp_packet2_details.csv :widths: 10,20,30,10 :header-rows: 1 **Client Packet** .. csv-table:: :file: ./NTP/ntp_packet3_details.csv :widths: 10,20,30,10 :header-rows: 1 **Server Packet** .. csv-table:: :file: ./NTP/ntp_packet4_details.csv :widths: 10,20,30,10 :header-rows: 1 **Broadcast Packet** .. csv-table:: :file: ./NTP/ntp_packet5_details.csv :widths: 10,20,30,10 :header-rows: 1 **NTP Control Message Packet** .. csv-table:: :file: ./NTP/ntp_packet6_details.csv :widths: 10,20,30,10 :header-rows: 1 .. _NTP_step7: .. tab-set:: .. tab-item:: NTP Usecases .. csv-table:: :file: ./NTP/ntp_usecases.csv :widths: 10,20,30 :header-rows: 1 .. _NTP_step8: .. tab-set:: .. tab-item:: NTP Basic Features .. csv-table:: :file: ./NTP/ntp_features.csv :widths: 10,10,30 :header-rows: 1 .. _NTP_step9: .. tab-set:: .. tab-item:: NTP Feature : Time Synchronization **Time Synchronization - Testcases** .. csv-table:: :file: ./NTP/ntp_feature1_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step10: .. tab-set:: .. tab-item:: NTP Feature : Hierarchical Architecture **Hierarchical Architecture - Testcases** .. csv-table:: :file: ./NTP/ntp_feature2_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step11: .. tab-set:: .. tab-item:: NTP Feature : High Accuracy **High Accuracy - Testcases** .. csv-table:: :file: ./NTP/ntp_feature3_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step12: .. tab-set:: .. tab-item:: NTP Feature : Fault Tolerance **Fault Tolerance - Testcases** .. csv-table:: :file: ./NTP/ntp_feature4_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step13: .. tab-set:: .. tab-item:: NTP Feature : Clock Filtering and Selection **Clock Filtering and Selection - Testcases** .. csv-table:: :file: ./NTP/ntp_feature5_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step14: .. tab-set:: .. tab-item:: NTP Feature : Security Support (NTPv4) **Security Support (NTPv4) - Testcases** .. csv-table:: :file: ./NTP/ntp_feature6_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step15: .. tab-set:: .. tab-item:: NTP Feature : Support **Support - Testcases** .. csv-table:: :file: ./NTP/ntp_feature7_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step16: .. tab-set:: .. tab-item:: NTP Feature : Dynamic Server Discovery **Dynamic Server Discovery - Testcases** .. csv-table:: :file: ./NTP/ntp_feature8_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step17: .. tab-set:: .. tab-item:: NTP Feature : Cross-Platform Compatibility **Cross-Platform Compatibility - Testcases** .. csv-table:: :file: ./NTP/ntp_feature9_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step18: .. tab-set:: .. tab-item:: NTP Feature : Low Bandwidth Usage **Low Bandwidth Usage - Testcases** .. csv-table:: :file: ./NTP/ntp_feature10_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _NTP_step19: .. tab-set:: .. tab-item:: Reference links * Reference links