[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Management


Previous Contents Index


logconfig +sysevents +syncstatus

This configuration would list the synchronization state of the NTP server and the major system events.
For a simple reference server, the following minimum message configuration might be useful:


logconfig +syncall +clockall

This configuration lists all clock information and synchronization information. All other events and messages about peers, system events, and so forth, are suppressed.
  • tinker [panic panic | dispersion dispersion | minpoll minpoll | allan allan| huffpuff huffpuff]
    This statement can be used to alter several system variables in exceptional circumstances. It should occur in the configuration file before any other configuration options. The default values of these options have been carefully optimized for a wide range of network speeds and reliability expectations. In general, they interact in intricate ways that are hard to predict, and some combinations can result in unpredictable behavior. It is rarely necessary to change the default values.
    The options operate as follows:
    • panic panic
      This option becomes the new value for the panic threshold, normally 1000 seconds. If set to zero, the panic sanity check is disabled and a clock offset of any value is accepted.
    • dispersion dispersion
      This option becomes the new value for the dispersion increase rate, usually .000015.
    • minpoll minpoll
      This option becomes the new value for the minimum poll interval used when configuring a multicast client, a manycast client, and symmetric passive-mode association. The value defaults to 6 (64 seconds) and has a lower limit of 4 (16 seconds).
    • allan allan
      This option becomes the new value for the minimum Allan intercept, which is a parameter of the PLL/FLL clock discipline algorithm. The value defaults to 1024 seconds, which is also the lower limit.
    • huffpuff huffpuff
      This option becomes the new value for the experimental huff-n-puff filter span, which determines the most recent interval that the algorithm will search for a minimum delay. The lower limit is 900 seconds (15 minutes), but a more reasonable value is 7200 (2 hours). There is no default, since the filter is not enabled unless this statement is given.

    13.3.2.1 NTP Monitoring Options

    TCP/IP Services NTP includes a comprehensive monitoring facility that is suitable for continuous, long-term recording of server and client timekeeping performance. Statistics files are managed using file generation sets and scripts.

    You can specify the following monitoring commands in your configuration file:

    • statistics name [ ... ]
      Enables writing of statistics records. The following is a list of the supported name statistics:
      • loopstats
        Enables recording of loop filter statistics information. Each update of the local clock outputs a line of the following form to the file generation set named loopstats :


        48773 10847.650 0.0001307 17.3478 2
        

        The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). (A Julian Day [JD] begins at noon and runs until the next noon. The JD number is the number of days [or part of a day] since noon [UTC] on January 1, 4713 B.C. A Modified Julian Day [MJD] is the JD minus 2,400,000.5.)
        The next three fields show time offset (in seconds), frequency offset (in parts per million), and time constant of the clock discipline algorithm at each update of the clock.
      • peerstats
        Enables recording of peer statistics information. This includes statistics records of all peers of an NTP server and of special signals, where present and configured. Each valid update appends a line of the following form to the current element of a file generation set named peerstats :


        48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142
        

        The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the peer address and status, respectively. The status field is encoded in hexadecimal. The final three fields show the offset, delay, and dispersion (in seconds).
      • clockstats
        Enables recording of clock driver statistics information. Each update received from a clock driver outputs a line in the following form to the file generation set named clockstats :


        49213 525.624 127.127.4.1 93 226 00:08:29.606 D
        

        The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field shows the clock address. The final field shows the last time code received from the clock in decoded ASCII format, where meaningful. In some clock drivers, a good deal of additional information can be gathered and displayed as well. For further details, see information specific to each clock.
      • rawstats
        Enables recording of raw timestamps. Each valid update appends a line in the following form to the file-generation set named rawstats :


        51554 79509.68  9.20.208.53  9.20.208.97
        3156617109.664603  3156617109.673268  03456142.801203010
        3156619216.137622
        

        The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the peer and local addresses. The next four fields are:
        • The origination timestamp
        • The received timestamp
        • The transmitted timestamp (the last one sent to the same peer)
        • The timestamp of the packet's arrival on the server
      • statsdir directory-path
        Indicates the full path of a directory in which statistics files should be created.

    13.3.2.2 Access Control Options

    TCP/IP Services NTP implements a general-purpose address-and-mask based restriction list. The list is sorted by address and by mask, and the list is searched in this order for matches. The last match to be found defines the restriction flags associated with the incoming packets. The source address of incoming packets is used for the match. The 32-bit address is and'ed with the mask associated with the restriction entry, and then is compared with the entry's address (which has also been and'ed with the mask) to look for a match.

    Although this facility might be useful for keeping unwanted or broken remote time servers from affecting your own, it is not considered an alternative to the standard NTP authentication facility.

    13.3.2.2.1 The Kiss-of-Death Packet

    Ordinarily, packets denied service are simply dropped with no further action except to increment statistics counters. Sometimes a more proactive response is needed, such as a server message that explicitly requests the client to stop sending and leave a message for the system operator. A special packet format has been created for this purpose called the kiss-of-death (kod) packet. If the kod flag is set and either service is denied or the client limit is exceeded, the server returns the packet and sets the leap bits unsynchronized, stratum 0, and the ASCII string DENY in the reference source identifier field. If the kod flag is not set, the server simply drops the packet.

    A client or peer that receives a kiss-of-death packet performs a set of sanity checks to minimize security exposure. If this is the first packet received from the server, the client assumes an access-denied condition at the server. The client updates the stratum and reference identifier peer variables and sets the access-denied bit in the peer flash variable. For information about displaying the flash variable, see Section 13.8.1.2. If this bit is set, the client sends no packets to the server. If this is not the first packet, the client assumes a client limit condition at the server but does not update the peer variables. In either case, a message is sent to the server's log file.

    13.3.2.2.2 Access Control Statements and Flags

    The syntax for the restrict statement is as follows:

    • restrict address [mask mask] [flag][...]
      The address argument is the address of a host or network. The mask argument defaults to 255.255.255.255, meaning that address is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0) is always the first entry in the list. The text string DEFAULT with no mask option can be used to indicate the default entry.
      The flag argument always restricts access (that is, an entry with no flags indicates that free access to the server is to be given). The flags are not orthogonal in that more restrictive flags often make less restrictive ones redundant. The flags can generally be classed into two categories: those that restrict time service and those that restrict informational queries and attempts to do run-time reconfiguration of the server.
      You can specify one or more of the flags shown in the following table:

      Table 13-1 Restrict Statement Flags
      Flag Description
      kod If access is denied, send a kiss-of-death packet.
      ignore Ignore all packets from hosts that match this entry. If this flag is specified, do not respond to queries and time server polls.
      noquery Ignore all NTP mode 6 and 7 packets (that is, information queries and configuration requests, respectively) from the source. Time service is not affected.
      nomodify Ignore all NTP mode 6 and 7 packets that attempt to modify the state of the server (that is, run-time reconfiguration). Queries that return information are permitted.
      noserve Ignore NTP packets whose mode is other than 6 or 7. In effect, time service is denied, though queries are still permitted.
      nopeer Provide stateless time service to polling hosts, but do not allocate peer memory resources to these hosts even if they might be considered useful as future synchronization partners.
      notrust Treat these hosts normally in other respects, but never use them as synchronization sources.
      limited These hosts are subject to limitation of number of clients from the same network. In this context, net refers to the IP notion of net (class A, class B, class C, and so forth). Only the first clientlimit hosts that respond to the server and that are active during the last clientperiod seconds are accepted. Requests from other clients from the same net are rejected; only time request packets are taken into account. Query packets sent by the NTPQ and NTPDC programs are not subject to these limits. A history of clients is kept using the monitoring capability of the NTP server. Thus, monitoring is always active as long as there is a restriction entry with the limited flag.
      ntpport This is actually a match algorithm modifier, not a restriction flag. Its presence causes the restriction entry to be matched only if the source port in the packet is the standard NTP UDP port (123). Both ntpport and non-ntpport can be specified. The ntpport is considered more specific and is sorted later in the list.
      version Ignore these hosts if not the current NTP version. Default restriction list entries, with the flags ignore , interface , ntpport , for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present if it is otherwise unconfigured. No flags are associated with the default entry (that is, everything but your own NTP server is unrestricted).
    • clientlimit limit
      The limit argument sets the client_limit variable, which limits the number of simultaneous access-controlled clients. The default value for this variable is 3.
    • clientperiod period
      The period argument sets the client_limit_period variable that specifies the number of seconds after which a client is considered inactive and thus no longer counted for client limit restriction. The default value for this variable is 3600 seconds.

    13.3.2.3 Sample NTP Configuration File

    A sample of the NTP configuration template follows:


    #
    # File name:      TCPIP$NTP.CONF
    # Product:        HP TCP/IP Services for OpenVMS
    # Version:        V5.4
    #
    # © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
    #
    # NTP server configuration file
    #
    #
    # DESCRIPTION:
    #
    #    This file contains configuration information  for  the  NTP  server.
    #    Before  starting the NTP server, you must edit this  file  and  copy
    #    it to SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF.
    #
    #    Refer  to  the HP TCP/IP Services for OpenVMS Management  guide  for
    #    instructions on editing and using this file.
    #
    #
    # CONFIGURATION INSTRUCTIONS:
    #
    #    The Network Time Protocol (NTP) provides synchronized timekeeping among
    #    a set of distributed time servers and clients. The local OpenVMS host
    #    maintains an NTP configuration file, TCPIP$NTP.CONF, of participating peers.
    #    TCPIP$NTP.CONF is maintained in the SYS$SPECIFIC:[TCPIP$NTP] directory.
    #
    #    Determine the peer hosts with which the local hosts should negotiate
    #    and  synchronize.  Include at least one (but preferably three) hosts
    #    that you are certain have the following characteristics:
    #
    #      1. provide accurate time
    #      2. synchronize to Internet Time Servers
    #      (if they are not themselves Internet Time Servers)
    #
    #    The NTP configuration file is not dynamic, and therefore requires
    #    restarting NTP  after being edited to make the changes take effect.
    #    However, you can make run-time configuration requests interactively
    #    using the NTPDC utility.
    #
    # CONFIGURATION:
    #
    #    Your NTP configuration file should always include the following
    #    driftfile entry.  The driftfile is the name of the file that stores
    #    the clock drift (also known as frequency error) of the system clock.
    
    driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
    
    #    Samples entries follow below.  Replace them with your  own  list  of
    #    hosts and identify the appropriate association mode.  If you specify
    #    multiple hosts, NTP  can  choose  the  best  source  with  which  to
    #    synchronize.  This also provides redundancy in case one of the hosts
    #    becomes unavailable.
    #
    #    Client/Server Mode
    #
    #    Client/Server mode indicates that the local  host  wants  to  obtain
    #    time  from  the  remote server and is willing to supply time to  the
    #    remote server.  Indicate Client/Server mode with a  peer  statement.
    #    Identify each peer with a fully-qualified DNS host name  or  with an
    #    IP address in dotted-decimal notation.
    
    peer 10.1.2.3
    peer ntp0.myorg.mycorp.com
    peer ntp1.myorg.mycorp.com
    
    #    Client Mode
    #
    #    Client mode indicates that the local host wants to obtain time  from
    #    the  remote server but it is not willing  to  provide  time  to  the
    #    remote server.  Indicate client  mode  with  the  server  statement.
    #    Identify each server with a fully-qualified DNS host name or with an
    #    IP address in dotted-decimal notation.
    
    server 10.2.3.4
    server 10.3.4.5
    server ntp3.myorg.mycorp.com
    
    #    The following commands allow interoperation of NTP with another time
    #    service such as DTSS.  If enabled (by removing #), NTP will not  set
    #    the system clock.
    
    # server 127.127.1.0 prefer
    # fudge 127.127.1.0 stratum 0
    
    #    The following commands allow this node to act as a backup NTP server
    #    (or as the sole NTP server on an isolated network),  using  its  own
    #    system clock as  the  reference source.  If enabled (by removing #),
    #    this NTP server will  become  active  only  when  all  other  normal
    #    synchronization sources are unavailable.
    
    # server 127.127.1.0
    # fudge 127.127.1.0 stratum 8
    

    13.3.3 Using NTP with Another Time Service

    A local host can run more than one time service. For example, a host can have both NTP and DTSS (Digital Time Synchronization Service) installed. However, only one of these time services is allowed to set the system clock.

    If you are running a time service in addition to NTP, you must stop either the other time source or NTP from setting the system clock. You can stop NTP from setting the system clock by adding the following statements to the configuration file:


    server 127.127.1.0 prefer
    fudge 127.127.1.0 stratum 0
    

    In these statements, the hardware address of the local clock (LOCAL) is 127.127.1.0. These statements force NTP to use its own system clock as a reference clock. The host continues to respond to NTP time queries but does not make any adjustments to the system clock, thereby allowing the other time service to make those changes.

    13.4 Configuring NTP as Backup Time Server

    You can configure the NTP service as a backup time server. In this case, if all other network synchronization sources become unavailable, the NTP service becomes active. You can also use this method to allow the local node to act as the NTP server in an an isolated network. To configure the NTP service as the backup server or the sole NTP server, enter the following commands in the NTP configuration file:


    server 127.127.1.0
    fudge 127.127.1.0 stratum 8
    

    In this example, the stratum is set to a high number (8) so that it will not interfere with any other, possibly better, time synchronization source. You should set the stratum to a number that is higher than the stratum of all other time synchronization sources.

    13.5 NTP Event Logging

    NTP maintains a record of system clock updates in the file SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP_RUN.LOG. NTP reopens this log file daily, each time creating a new version of the file (older versions are not automatically purged). Events logged to this file can include the following messages:

    • Synchronization status that indicates synchronization was lost, stratum changes, and so forth
    • System time adjustments
    • Time adjustment status

    Logging can be increased by using the logconfig option in TCPIP$NTP.CONF. For more information, see Section 13.3.2.

    In addition, you can enable debugging diagnostics by defining the following logical name with /SYSTEM and a value from 1 through 6, where 6 specifies the most detailed logging:


    $ DEFINE /SYSTEM TCPIP$NTP_LOG_LEVEL n
    

    Table 13-2 describes the messages most frequently included in the NTP log file.

    Table 13-2 NTP Log File Messages
    Message Description
    Time slew time Indicates that NTP has set the local clock by slewing the local time to match the synchronization source. This happens because the local host is no longer synchronized. For example:
    time slew -0.218843 s
    
    Synchronization lost This usually occurs after a time reset. All peer filter registers are cleared, for example, for that particular peer; all state variables are reset along with the polling interval; and the clock selection procedure is once again performed.
    Couldn't resolve hostname, giving up on it Indicates that the host name could not be resolved. This peer will not be considered for the candidate list of peers. For example:
    couldn't resolve 'fred', giving up on it
    
    Send to IP-address: reason Indicates that a problem occurred while sending a packet to its destination. The most common reason logged is "connection refused." For example:
    sendto(16.20.208.100): connection refused
    
    Time Correction of delta-time seconds exceeds sanity limit (1000); set clock manually to the correct UTC time NTP has detected a time difference greater than 1000 seconds between the local clock and the server clock. You must set the clock manually or use the NTPDATE program and then restart NTP. Once NTP sets the clock, it continuously tracks the discrepancy between the local time and NTP time and adjusts the clock accordingly.
    offset: n sec freq x ppm poll: y sec error z An hourly message, in which:
    • offset is the offset (in seconds) of the peer clock relative to the local clock (that is, the amount to adjust the local clock to bring it into correspondence with the reference clock).
    • freq is the computed error in the intrinsic frequency of the local clock (also known as "drift") (in parts per million).
    • poll is the minimum interval (in seconds) between transmitted messages (that is, messages sent between NTP peers, as in a client to a server).
    • error is the measure of network jitter (that is, latencies in computer hardware and software).
    No clock adjustments will be made, DTSS is active Indicates that the DTSS time service is running on the system. The DTSS time service should be disabled if you would like NTP to set the system time. To disable the DTSS time service, enter the following command:
    $ RUN SYS$SYSTEM:NCL DISABLE DTSS
    

    Alternatively, you can configure the NTP server not to make clock adjustments, as described in Section 13.3.3. NTP dynamically detects whether the DTSS time service is enabled at any time and will log this message if appropriate.

    Clock adjustments will resume. DTSS no longer active Indicates that the DTSS time service has been disabled on the system. NTP will now handle clock adjustments. NTP dynamically detects whether the DTSS time service is enabled at any time and will log this message if appropriate.


    Previous Next Contents Index