The Portmapper service eliminates the need to preconfigure all client and server remote procedure call (RPC) applications with the port numbers they use. The Portmapper "listens" at port 111 and maintains a database of registered server programs, their unique program numbers, and assigned port numbers.

You must run the Portmapper if you intend to use the following applications:

• NFS
• PC-NFS
• MOUNT
• Any customer-developed programs that use RPC

This chapter describes how to:

• Configure the services that use RPC with information that the Portmapper needs ( Section 9.1)
• Display Portmapper settings ( Section 9.2)

For information about programming with the DIGITAL TCP/IP Services for OpenVMS RPC application programming interface (API), see the DIGITAL TCP/IP Services for OpenVMS ONC RPC Programming manual.

9.1 Configuring Services to Use the Portmapper

The SET SERVICE command configures the applications so they are known to the Portmapper. To set RPC-related parameters, use the /RPC qualifier. Enter:

TCPIP> SET SERVICE service - _TCPIP> /RPC=(PROGRAM_NUMBER=n, VERSION_NUMBER=(LOWEST=n, HIGHEST=n))

The TCPIP services that use the Portmapper have the following default values for the /RPC qualifier:

• MOUNT
  • PROGRAM_NUMBER=100005
  • VERSION_NUMBER=(LOWEST=1, HIGHEST=1)
• NFS Server
  • PROGRAM_NUMBER=100003
  • VERSION_NUMBER=(LOWEST=2, HIGHEST=2)
• PCNFSD
  • PROGRAM_NUMBER=150001
  • VERSION_NUMBER=(LOWEST=1, HIGHEST=2)
• PORTMAPPER
  • PROGRAM_NUMBER=100000
  • VERSION_NUMBER=(LOWEST=1, HIGHEST=1)

The SHOW SERVICE command with the /RPC and /PERMANENT qualifiers displays the current RPC options.

Example 1:
The following example displays the RPC options for these running services: MOUNT, NFS, PC-NFS, and the Portmapper:

TCPIP> SHOW SERVICE /RPC /PERMANENT RPC Protocol Versions Service Program Number Lowest / Highest MOUNT 100005 1 1 NFS 100003 2 2 PCNFS 150001 1 2 PORTMAPPER 100000 2 2 TCPIP>

Example 2:
In the next example, the /FULL and /PERMANENT qualifiers display the RPC options for the NFS server, whose program number is 100003, lowest version is 2, and highest version is 2:

TCPIP> SHOW SERVICE NFS /FULL /PERMANENT Service: NFS Port: 2049 Protocol: UDP Address: 0.0.0.0 Inactivity: 0 User_name: TCPIP$NFS Process: TCPIP$NFS Limit: 1 File: TCPIP$SYSTEM:TCPIP$NFS_RUN.COM Flags: TCPIP Socket Opts: Rcheck Scheck Receive: 64000 Send: 64000 Log Opts: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr File: SYS$SYSDEVICE:[TCPIP$NFS]TCPIP$NFS_RUN.LOG RPC Opts Program number: 100003 Low version: 2 High version: 2 Security Reject msg: not defined Accept host: 0.0.0.0 Accept netw: 0.0.0.0 TCPIP>

To list information about all the registered applications, for example, enter the SHOW PORTMAPPER command.

TCPIP> SHOW PORTMAPPER Program Number Version Protocol Port-number Process Service-name --------------------- ------- -------- ----------- -------- ------------ 000186A0 ( 100000) 2 TCP 111 24800126 PORTMAPPER 000186A0 ( 100000) 2 UDP 111 24800126 PORTMAPPER 000186A3 ( 100003) 2 UDP 2049 24800125 NFS 2C30B587 ( 741389703) 1 UDP 2049 24800125 000186A5 ( 100005) 1 UDP 10 24800125 MOUNT

To monitor the server, enter the SHOW SERVICE PORTMAPPER command. For example:

TCPIP> SHOW SERVICE PORTMAPPER Service Port Protocol Process Address State PORTMAPPER 111 TCP,UDP TCPIP$PORTM 0.0.0.0 Enabled

The Network Time Protocol (NTP)¹ provides a means to synchronize time and coordinate time distribution throughout a TCP/IP network. NTP aims to provide accurate and dependable timekeeping for hosts on TCP/IP networks.

NTP provides synchronization traceable to clocks of high absolute accuracy and avoids synchronization to clocks keeping incorrect time.

Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and timestamping of instrumental data.

This chapter reviews key NTP concepts and provides guidelines for configuring and administering NTP software on your OpenVMS system. This chapter also describes NTP utility programs NTPQ and NTPDC; a local clock-setting program called NTPDATE; and a traceback utility called NTPTRACE that locates suitable synchronization sources.

10.1 Reviewing Key Concepts

Synchronized timekeeping means that hosts with accurate system timestamps send time quotes to each other. Hosts running NTP may be either time servers or clients although they are often both servers and clients.

NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Universal Coordinated Time (UTC) using the best available source and best available transmission paths to that source. NTP expects that the time being distributed from the root of the synchronization subnet will be derived from some external source of UTC (for example, a radio clock)

If your network is isolated and you cannot access other NTP servers on the internet, you can designate one of your nodes as the reference clock to which all other hosts will synchronize.

10.1.1 Time Distributed Through a Hierarchy of Servers

In the NTP environment, time is distributed through a hierarchy of NTP time servers. Each server adopts a stratum that indicates how far away it is operating from an external source of UTC.² Stratum 1 servers have access to an external time source, usually a radio clock. A stratum 2 server is one that is currently obtaining time from a stratum 1 server; a stratum 3 server gets its time from a stratum 2 server, and so on. To avoid long-lived synchronization loops, the number of strata is limited to 15.

Stratum 2 (and higher) hosts might be company or campus servers that obtain time from some number of primary servers and provide time to many local clients. In general:

• Lower strata hosts act as time servers.
• Higher strata hosts are clients who adjust their time clocks according to the servers.

Internet time servers are stratum 1 servers. Other hosts connected to an internet time server have stratum numbers of 2 or higher and may act as time servers for other hosts on the network. Clients choose one of the available servers with which to synchronize. Usually this is one from among the lowest stratum servers to which it has access.

10.1.2 How Hosts Negotiate Synchronization

Each host has its identifying stratum number encoded within UDP datagrams. Peers communicate by exchanging these timestamped UDP datagrams. NTP uses these exchanges to construct a list of possible synchronization sources then sorts them according to stratum and synchronization distance. Peers are accepted or rejected leaving only the most accurate and precise sources.

NTP evaluates any new peer to determine if it qualifies as a new (more suitable) synchronization source.

NTP rejects the peer under the following conditions:

• The peer is not synchronized.
• The stratum is higher than the current source's stratum.
• The peer is synchronized to the local node.

NTP accepts the peer under the following conditions:

• There is no current time source.
• The current source is unreachable.
• The current source is not synchronized
• The new source's stratum is lower than the current source.
• The new source's stratum is the same as the current source, but its distance is closer to the synchronization source by more than 50%.

The OpenVMS system clock is maintained as a software timer with a resolution of 100 nanoseconds, updated at 10 millisecond intervals. A clock update is triggered when a register, loaded with a predefined value, has decremented to zero. Upon reaching zero, an interrupt is triggered that reloads the register, thus repeating the process.

The smaller the value loaded into this register, the more quickly it reaches zero and triggers an update. The clock runs more quickly in such an instance. A larger value means more time between updates; therefore, the clock runs more slowly.

10.1.4 How NTP Makes Adjustments to System Time

Once NTP has selected a suitable synchronization source, NTP compares the source's time with that of the local clock. If NTP determines that the local clock is running ahead of or behind the synchronization source, NTP uses a general drift mechanism to slow down or speed up the clock as needed. NTP accomplishes this by issuing a series of new ticks. For example, if NTP detects that the local clock is drifting ahead by +0.1884338 second, it issues a series of new ticks in an effort to reduce the difference between the synchronization source and the local clock.

NTP maintains a record of the resets it makes along with informational messages in the NTP log file, TCPIP$NTP.LOG. See Section 10.5 for more details about event logging and help in interpreting an NTP log file.

10.1.5 Configuring the Local Host

As the system manager of the local host, you determine which network hosts to use for synchronization and populate an NTP configuration file with a list of the participating hosts.

NTP hosts may be configured in one or more of the following modes:

• Client/server mode
  This mode indicates that the local host wants to obtain time from the remote server and is willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected through diverse network paths. Internet time servers generally use this mode.
  Indicate this mode with a peer declaration in the configuration file. For example:

  peer 18.72.0.3

• Client mode
  This 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. Client mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients. A host with higher stratum generally uses this mode.
  Indicate client mode with the server declaration in the configuration file. For example:

  server 18.72.0.3

• Broadcast mode
  This mode indicates that the local server will send periodic broadcast messages to a client population at the broadcast/multicast address specified. This specification normally applies to the local server operating as a sender.
  Indicate this mode with a broadcast declaration in the configuration file. For example:

  broadcast 18.72.0.255

10.1.6 Using NTP with Another Time Service

If you are running a time service in addition to NTP, you must stop NTP from setting the system clock by adding the following statements in the configuration file:

server 127.127.0 prefer fudge 127.127.1.0 stratum 0

These statements dupe NTP into using its own system clock as a reference clock. The host continues to respond to NTP time queries but won't make any adjustments to the system clock, allowing the other time service to make those changes.

10.2 Configuring Your NTP Host

The NTP configuration file TCPIP$NTP.CONF contains a list of hosts your system will use for time synchronization. Before configuring your host, you must:

1. Select time sources.
2. Obtain the IP addresses or host names of the time sources.
3. Obtain the version number of NTP that the hosts are running.

To ensure reliable synchronization, select multiple time sources that you are certain provide accurate time and are synchronized to an Internet time server.

To minimize common points of failure, avoid synchronizing:

• The local host to another peer at the same stratum unless the latter is receiving time from a lower stratum source to which the local host cannot connect
• More than one host in a particular administrative domain to the same time server outside that domain

To simplify configuration file maintenance, avoid configuring peer associations with higher stratum servers.

10.2.1 Creating the Configuration File

To create a configuration file for your local host, edit a copy of the file TCPIP$NTP.TEMPLATE (located in SYS$SPECIFIC:[TCPIP$NTP]) to add the names of participating hosts, then save the file as SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF.

The following are valid NTP configuration statements:

• peer address [key ID] [version number] [prefer] [minpoll interval] [maxpoll interval]
• server address [key ID] [version number] [prefer ]
• broadcast address [key ID] [version number] [ttl nn]
  The following describes the options to the peer, server, and broadcast commands.

  key ID	For all packets sent to the address, includes authentication fields encrypted using the specified key identifier, an unsigned 32-bit integer. The default is no encryption.
  version number	Specifies the version number to be used for outgoing NTP packets. Version 1, 2, and 3 are the choices. The default is 3.
  prefer	Marks the server as preferred. This host will be chosen for synchronization among a set of correctly operating hosts.
  ttl nn	Used only with broadcast mode. It specifies the time-to-live to use on multicast packets.
  minpoll interval	Specifies the minimum polling interval for NTP messages, in seconds to the power of two. The allowable range is 4 (16 s) to 14 (16384s) inclusive. Not applicable to reference clocks. The default is 6 (64s).
  maxpoll interval	Specifies the maximum polling interval, in seconds, for NTP messages. The allowable range is 4 (16 s) to 14 (16384s) inclusive. The default is 10 (1024s). (Does not apply to reference clocks.)

• broadcastclient address
  Directs the local server to listen for broadcast messages at the broadcast address of the local network. The default address is the subnet address with the host file bits set to ones. Upon hearing a broadcast message for the first time, the local server measures the nominal network delay using a brief client/server exchange with the remote server, then enters the broadcastclient mode, in which it listens for and synchronizes to succeeding broadcast messages. Note, to avoid accidental or malicious disruption in this mode, both the local and remote servers should operate using authentication and the same trusted key and key identifier.
• multicastclient address
  Directs the local server to listen for multicast messages at the group address of the global network. This command operates like the broadcastclient command, but uses IP multicasting.
• driftfile file_name location
  Specifies the name of the file used to record the frequency offset of the local clock oscillator. If the file exists, it is read at startup to set the initial frequency offset, then updated hourly with the current frequency computed by the NTP server.
  If the file does not exist or the driftfile command is not specified in the configuration file, the initial frequency offset is assumed zero. If the file does not exist but the driftfile keyword is specified without a parameter, the default, SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT, will be used.

  In these cases, it may take some hours for the frequency to stabilize and the residual timing errors to subside.
  The drift file TCPIP$NTP.DRIFT consists of a single floating-point number, which records the frequency of the offset measured in parts-per-million (PPM).

• enable auth | bclient | monitor | pll | stats
  disable auth | bclient | monitor | pll | stats
  These commands provide a way to enable or disable various server options.

  auth	Enables synchronization with unconfigured peers only if the peer has been correctly authenticated using a trusted key and key identifier. The default is enable.
  bclient	Enables the server to listen for messages from broadcast or multicast servers. The default is disable.
  monitor	Enables the monitoring facility. The default is enable.
  pll	Enables the server to adjust its local clock by means of NTP. If disabled, the local clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is controlled by some other device or protocol and NTP is used only to provide synchronization to other clients. In this case, the local clock driver is used. The default is enable.
  stats	Enables the statistics facility. The default is enable.

A sample of the NTP configuration template follows:

# Copyright (c) Digital Equipment Corporation, 1998 # # Example NTP Configuration File # # Rename this template to TCPIP$NTP.CONF. # # See the DIGITAL TCP/IP Services for OpenVMS Management manual for # additional commands and detailed instructions on using this # configuration file. # # 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. # # As the system manager populating this file, you must 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: # # * provide accurate time # * 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 TCPIP$NTPDC utility. # 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 # Sample peer entries follow. 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 reliability in case one of the hosts # becomes unavailable. # Identify each peer with a DNS host name or with an IP address # in dotted-quad notation. peer 18.72.0.3 peer 130.43.2.2 peer 16.1.0.22 peer parrot # The following commands let you use 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