HP OpenVMS Systems Documentation |
HP TCP/IP Services for OpenVMS
|
Previous | Contents | Index |
logconfig +sysevents +syncstatus |
logconfig +syncall +clockall |
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:
48773 10847.650 0.0001307 17.3478 2 |
48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142 |
49213 525.624 127.127.4.1 93 226 00:08:29.606 D |
51554 79509.68 9.20.208.53 9.20.208.97 3156617109.664603 3156617109.673268 03456142.801203010 3156619216.137622 |
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:
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). |
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 |
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:
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.
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:
|
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 |