Frequently Asked Questions s29

Frequently Asked Questions

Timesync NLM

Created by Vithalprasad Gaitonde, Novell India 18 February 1999

Revised by Marcus Williamson, Connectotel Ltd 6 April 1999

Revised by Vithalprasad Gaitonde, Novell India April/May 1999

Latest revised by Marcus Williamson, Connectotel Ltd 16 May 1999

Novell's Recommendations on Time Synchronization

Why is time synchronization necessary?

Time synchronization ensures that all servers in a enterprise network report the same time. Such synchronization is important because applications and services such as Novell Directory Services (NDS) require time stamps to establish the order of events and record real-world time values.

What is Novell's recommended approach to achieve time synchronization amongst NetWare servers?

Novell recommends the use of TIMESYNC NLM to achieve time synchronization amongst NetWare servers.

TIMESYNC NLM version 5.08 onwards has the capability to talk to other NTP sources and exchange time information with them. This allows a NetWare server running TIMESYNC NLM version 5.08 and above to synchronize time with an external time server (public NTP source) as well as allowing an NTP client to obtain time from a NetWare server.

I need to synchronize my NetWare servers with an NTP time source. What is Novell's recommendation on this?

TIMESYNC NLM has been enhanced to work with NTP time sources. This version of TIMESYNC NLM (ver 5.08 or later) is available on http://support.novell.com and will also be available on future support packs of NetWare 5. Please check http://www.support.novell.com for the latest downloadable TIMESYNC NLM.

The latest downloadable version (as of 16 May 1999) is 5.09 from NW5SP2.EXE.

What is the role of NTP NLM in time synchronization?

Novell is committed to making Internet standards available on its platform. To achieve this, Novell has provided the NTP.NLM on NetWare 5 -- a service that implements the Network Time Protocol (NTP) definition described in RFC1305. In addition, Novell has enhanced its time synchronization service, TIMESYNC NLM, to inter-operate directly with NTP based time sources.

TIMESYNC NLM has features such as : a comprehensive collection of set parameters, easy setup, auto discovery over IPX, interoperability with IPX and IP, and interoperability with NetWare 4.x and NetWare 5. This makes the TIMESYNC NLM easy to use and manage. NTP.NLM met some specific customer needs when it was introduced, but is much less robust.

Of the two implementations for synchronizing time in a NetWare environment, Novell recommends using TIMESYNC NLM. Wherever standard NTP interoperability is needed (to either serve time or take time from NTP time sources), TIMESYNC NLM's new features can be used. In effect, the NTP interoperability enhancement to TIMESYNC NLM eliminates the need to use NTP.NLM.

Since NTP.NLM was introduced for the first time on NetWare 5 whereas TIMESYNC NLM has been in the field since NetWare 4.x and is now capable of providing NTP functionality on NetWare, it is best to use TIMESYNC NLM for all purposes of time synchronization.

How is the working of TIMESYNC NLM different in NetWare 5 compared to NetWare 4.11?

TIMESYNC NLM on NetWare 4.x only used IPX as its communication protocol. This also implies that it used SAP (Service Advertising Protocol) to advertise itself. This protocol relies on periodic network broadcasts to advertise services.

TIMESYNC NLM in NetWare 5 has been enhanced to work over IP. It still retains its ability to work over IPX. This implies that if you have a network comprising both pure IP and pure IPX servers, time can flow from IPX to IP, and vice- versa, as long as there is at least one server that has both IP and IPX to provide translation between the two sides. You do not need the Migration Gateway solution for this purpose.

SLP (Service Location Protocol) is used to advertise and locate services in an IP network. This is much less bandwidth intensive than SAP, but requires more administration. TIMESYNC NLM has not yet been enhanced to perform auto discovery of time servers over IP. This feature is expected to be available in Support Pack 3.

Apart from these differences in protocols, the working of TIMESYNC NLM in NetWare 4.x and NetWare 5 remains identical. There is no difference in the packet format, time synchronization algorithms, or for that matter, in anything.

With NetWare 5 Support Pack 2, TIMESYNC NLM has the capability to serve as an NTP client as well as an NTP server as described in an answer to an earlier question. How do I achieve time synchronization in a mixed environment comprising platforms such as NetWare, Unix, Windows NT and mainframes?

The only way to achieve time synchronization in a mixed environment is by using an open, standard protocol for time synchronization such as NTP.

Unix boxes often have NTP built into the base OS. NTP implementations are also available for MS Windows NT and Apple Macintosh computers. Once you have identified an NTP implementation for your platform, and have deployed it on your platform, you are ready to talk to other NTP sources such as NetWare, Unix boxes, Internet time sources etc.

How do I build fault tolerance into the time synchronization at my enterprise?

Fault tolerance is achieved by configuring Timesync NLM with multiple time sources. This can be done by setting the "timesync time source" set parameter. Therefore, if one server cannot be contacted for any reason, the time can be got from other servers in the time source network.

Multiple time sources can be entered by separating the two time sources with a semicolon. For example :

SET TIMESYNC TIME SOURCES=1.2.3.4; 5.6.7.8;

The semicolon (;) is used as a separator between two sources.

TIMESYNC NLM and NTP

What are the similarities and differences between TIMESYNC NLM and NTP?

TIMESYNC NLM is a Novell proprietary time synchronization service available on NetWare. NTP is an Internet protocol specification (Internet RFC 1305), that needs to be implemented by vendors on platforms. NTP implementations are available on NetWare, NT, Mac, Unix, etc.

TIMESYNC.NLM now provides Novell timesync protocol, NTP client and NTP server capability.

NTP believes in the absolute concept of time i.e. the number of seconds elapsed since 1 January, 1900 referred to as UTC (Universal Coordinated Time). All clocks need to synchronize with UTC time. However, TIMESYNC NLM has no such absolute concept of time. As long as all the computers in an intranet serve the same time, they are considered to be synchronized. The NetWare server may show a time different from the actual time of the day and still claim to be synchronized to the network provided all other NetWare servers are showing the same time. NTP has been designed for the Internet, whereas TIMESYNC NLM has been designed keeping an intranet in mind.

TIMESYNC NLM is actually an adaptation of NTP. TIMESYNC NLM uses the same algorithms as NTP to account for network delay when obtaining time from a time source. However, NTP as a protocol is quite a heavyweight. When adapting TIMESYNC NLM, some features have been omitted to make it simple and practical. Some of the features in NTP that are not present in TIMESYNC NLM, are :

 Leap second insertion: At regular intervals, clocks need to be compensated by inserting a leap second to the clock time.

 Drift compensation: NTP keeps track of the pattern of changes to the clock, and over a period of time it computes a drift compensation factor that is applied to the clock.

 Clock filtering and clock selection algorithms: NTP uses fairly complex algorithms to assess the reliability of each of the time sources in its list of time sources, and selects only those that are considered to be reliable.

 Authentication: NTP can use authentication to ensure the integrity of the time source. TIMESYNC NLM, which has been designed for the intranet, trusts all time sources.

 NTP is quite strict while considering a time source as a contender for obtaining time. If a time source is more than 1000 seconds (about 17 minutes) away from the local clock, NTP rejects the time source. The time source is labeled an "insane" time source.

NTP never corrects time directly. The time polled is given as a feedback to the clock, so that the clock corrects its time. This is in contrast to TIMESYNC NLM, where the difference in time is gradually applied to the local clock. Typically, TIMESYNC NLM tries to correct time within one polling interval (the default value is 10 minutes). As a consequence of this approach, TIMESYNC NLM is able to synchronize time in a network much faster. NTP takes much longer to make this happen.

The other differences between TIMESYNC NLM and NTP have to do with manageability and ease of setup. TIMESYNC NLM has several set parameters that enables administrators to control the working of TIMESYNC NLM to a great extent. In NTP, the only things that can be configured are the time servers.

Almost nothing else is configurable. TIMESYNC NLM has features such as auto discovery over IPX, and uses multiple naming schemes ( SAP names , dotted NDS names and IP addresses can be entered into the time sources list) to identify time sources. These features make TIMESYNC NLM easier to setup and manage.

TIMESYNC NLM over IP

Does TIMESYNC NLM work over IP?

Yes, TIMESYNC NLM in NetWare 5 works over IP. IP addresses can be specified in the time sources set parameter. For example :

SET TIMESYNC TIME SOURCES=1.2.3.4;

Does TIMESYNC NLM require CMD (Compatibility Mode Driver) to work over IP?

TIMESYNC NLM in NetWare 5 works natively over IP. In other words, TIMESYNC NLM itself handles all IP related communication, and hence does not need CMD to work over IP.

Why are questions such as: "Does TIMESYNC NLM work over IP?" still asked?

Users and administrators are familiar and comfortable with the TIMESYNC NLM of NetWare 4.x. TIMESYNC NLM over 4.x used SAP for auto discovery; the first server in a tree was set to TIMESYNC NLM type SINGLE reference, and subsequent servers were set to SECONDARY by the installation process. The Secondary servers discovered the Single reference server using SAP.

Because TIMESYNC NLM in NetWare 5 does not feature auto discovery over IP, each Secondary server needs to be explicitly configured to take time from the Single server. If this is not done, the Secondary server will report that it is out of sync, and hence gives the impression that "TIMESYNC NLM does not work over IP".

Auto-discovery over IP will be available by NetWare 5 Support Pack 3 and will us the SLP (Service Location Protocol) over IP instead of SAP in IPX for auto-discovering time servers on the network.

When will CMD be required?

If a pure IP network needs to obtain time from a pure IPX server by giving a server name in the time sources set parameter, CMD is required to resolve the IPX address.

Setting up TIMESYNC NLM over IP

I am setting up a network of NetWare 5 servers. How do I set up time synchronization?

Refer to the TIMESYNC NLM documentation to decide whether to use a Single - Secondary model, or a Reference - Primary - Secondary model. Single - Secondary models are good for small networks (30 servers or less). Reference - Primary - Secondary models are suitable for larger networks, and for networks that span geographical separate regions.

Each TIMESYNC NLM server, that needs to get time from another server, needs to be explicitly configured. For example, if server B needs to take time from Server A, server B needs to be set up as follows:

From the console prompt, type:

Set timesync configured sources = on Set timesync time sources = ;

Run monitor NLM. Select the option Server Parameters -> Time. The parameter "Timesync configured sources" should be on. The IP address of Server A should be entered in the "Timesync time sources" field.

Ensure that only dotted decimal IP addressed are entered. TIMESYNC NLM cannot understand DNS names. TIMESYNC NLM will be enhanced to understand DNS names in one of the support packs subsequent to Support Pack 3.

Over IPX, I did not need to set up configured sources. Why do I have to do it now?

Over IPX, TIMESYNC NLM could automatically discover other TIMESYNC NLM sources using SAP. TIMESYNC NLM over IP as yet does not have this capability. This functionality will be shipped in Support Pack 3 of NetWare 5.

Can I use a server name in the configured sources? In an IP only setup, IP addresses are preferred. This will de done away with the ability to recognise DNS names in a future release of TIMESYNC NLM.

Using TIMESYNC NLM with NTP time sources

Can TIMESYNC NLM work with NTP time sources?

Yes. TIMESYNC NLM, ver 5.08 or later, can work with NTP. This implies that TIMESYNC NLM can take time from an NTP time source, and can serve time to NTP clients.

How do you setup a TIMESYNC NLM server to obtain time from an NTP time source?

The configuration is similar to obtaining time from a normal TIMESYNC NLM time source. Set the value of the "Configured Source" set parameter to "on". Specify the IP address of the NTP time source in the "Time sources". However, an NTP time source needs to be differentiated from a TIMESYNC NLM time source by suffixing ":123" to the IP address. 123 has been chosen as it is the standard port for NTP.

For example :

SET TIMESYNC CONFIGURED SOURCES=ON SET TIMESYNC TIME SOURCES= 1.2.3.4:123;

Where 1.2.3.4 is an NTP source.

Can Timesync Reference and Timesync Single servers take time from an NTP time source?

In a pure timesync scenario, Single and Reference servers read time from their local hardware clocks and serve it to time clients. They do not change their time. In other words, even if you have entered timesync time sources in Single or Reference server, they will not be used to change the time on the Single or Reference server.

However, the NTP feature now enables Single and Reference servers to obtain time from NTP time sources. This means that the Single or Reference server, if setup with NTP sources in its time sources set parameter, would poll the NTP time source periodically, and adjust its local clock to synchronize with the NTP time source.

Can Timesync Secondary and Timesync Primary servers take time from an NTP time source?

Yes. All types of timesync servers can obtain time from an NTP time source.

I have an existing network of NetWare servers. I want this network to take time from an NTP time source. How do I configure the network? Identify the "root" time servers in the network. If you have used a Single - Secondary model, the Single server is the root. If you have used the Reference - Primary - Secondary model, the Reference server and Primary servers together act as the root for serving time to the rest of the network. Update the root server(s) to get time from the NTP time source. The steps required to do this are explained above.

As the entire network looks to the root time sources for time, we are ensuring that the entire network takes time from the NTP time source.

How does TIMESYNC NLM provide time to an NTP client?

TIMESYNC NLM, ver 5.08 or later, has the capability to provide time to an NTP client. This service is provided through UDP port 123. If you want your Unix machines to take time from a NetWare server, set up NTP on your Unix machines with the IP address of the NetWare server. This is done by entering the following statement in the NTP configuration file (usually /etc/ntp.conf) for the Unix system :

Server

Can TIMESYNC NLM obtain time from an Internet Time source?

Internet time sources are typically public domain NTP time sources that are at Stratum 1 or 2. This being the case, setting up TIMESYNC NLM to obtain time from an Internet source is no different from setting it up to obtain time from an NTP time source within the intranet. The configuration steps to achieve this are identical.

NTP uses the nomenclature of “stratum” to indicate the accuracy of a time source. The stratum ranges from 1 to 16. 1 stands for source which is most accurate where as 16 stands for one which is “out of sync”. A NTP server at stratum “n+1” is one which accepts time from a NTP server at stratum “n”. Thus a server at a lower stratum indicates a server which is more accurate than one at a higher stratum.

What are the limitations of this NTP enhancement to TIMESYNC NLM?

This enhancement enables TIMESYNC NLM to understand NTP wire format. However, the NTP Protocol specification, contained in RFC 1305, mandates several features such as: leap second insertion and clock drift correction, that were considered heavy weight, and have, therefore, not been included in this enhancement. Thus, TIMESYNC NLM provides the NTP client and NTP server functionality while at the same time continues to be light weight.

Traffic generated by TIMESYNC NLM

What are the different ways in which a TIMESYNC NLM server generates traffic? A TIMESYNC NLM server can generate the following kinds of traffic: advertisement traffic, discovery traffic, time request traffic and time response traffic.

Advertisement traffic is generated when TIMESYNC NLM announces its service in the network. Over IPX, this is achieved through SAP. Over IP, TIMESYNC NLM does not advertise its service. Service Advertisement using SLP is expected in future releases . SAP traffic is typically generated once every minute. SLP advertisement is performed only when TIMESYNC NLM starts up, or when TIMESYNC NLM has to re-register when the SLP Service or the SLP Directory Agent goes down. Advertisement traffic over IP (when this feature is available in future releases) is expected to be significantly less than the SAP based advertisement traffic in IPX.

Discovery traffic is generated when TIMESYNC NLM tries to discover the presence of other TIMESYNC NLM servers in the network. In IPX, this actually does not cause any traffic at all, as all NetWare servers contain a SAP cache, which can be queried to perform discovery. Over IP, SLP is used for discovery and hence, discovery implies that a call needs to be made to an SLP service agent.

Time request traffic is generated when a server needs to take time from another server. This is periodic in nature, and in the steady state, its frequency is controlled by the "timesync polling interval" set parameter. The default value of this polling interval is 10 minutes. However, the frequency of polling is higher when a NetWare server starts up, or loses time synchronization for any reason. This implies that TIMESYNC NLM will generate much more traffic during server startup.

Time response traffic is generated when a server receives a request for time from another server. In TIMESYNC NLM, time is provided only when it is requested by another server. In other words, a "pull" model is used to distribute time, and time is not "pushed" to other servers. Therefore, under normal circumstances time response traffic is equal to time request traffic, and hence follows the same periodicity.

How do you control the traffic generated by TIMESYNC NLM?

Set parameters of TIMESYNC NLM can be used to modify the traffic generated by TIMESYNC NLM to suit your requirements. The following table indicates the set parameters to be used to modify TIMESYNC NLM traffic:

Timesync Set Parameter to Notes of the use of the set Recommendations Traffic Type be used parameter Advertiseme Timesync service Set timesync service advertising This server cannot be discovered nt advertising = off eliminates all using auto discovery; explicit Traffic advertisement traffic. configuration is needed to take time from this server. Recommended for IPX and not for IP. Discovery No set parameter This traffic is quite minimal anyway. Traffic can control this traffic. Time Timesync polling Increase in polling interval may Polling interval may be increased request interval reduce traffic. up to 60 minutes. Increasing the traffic Timesync Increase in synchronization interval beyond 60 is not synchronization radius may reduce traffic. recommended. radius Timesync polls 3 times (the Time polling default value of this parameter). Synchronization radius depends on count A reduced value will obviously the kinds of applications that run on reduce traffic. networks. Some may need more precise time than others.

Polling count may be reduced to 2 in a LAN where the chance of packet loss is quite a loss. It is not prudent to reduce this value if timesync is operating across a WAN. Time Depends entirely response on request traffic. traffic All the set parameters that impact request traffic also impact response traffic.

TIMESYNC NLM, Transport Protocols, and Firewalls

What transport protocols does TIMESYNC NLM use? What are the port numbers used?

TIMESYNC NLM uses datagrams over IPX and IP.

In an IP environment, TIMESYNC NLM uses UDP on port 524. The request packet is dispatched from 524, but the response is received on a dynamic port.

When communicating with an NTP time source, TIMESYNC NLM uses UDP port 123, which is the popular port for NTP. The request packet is dispatched from 123, and the response is also received at 123.

Can TIMESYNC NLM work across a firewall?

TIMESYNC NLM can work across a firewall only if the firewall permits incoming UDP traffic.

If TIMESYNC NLM has to communicate with a TIMESYNC NLM source across the firewall, all incoming UDP traffic must be permitted. This is because the incoming TIMESYNC NLM packet is destined to be an dynamic port.

If TIMESYNC NLM has to communicate with an NTP source across the firewall, incoming UDP traffic for UDP port 123 must be permitted.

On the working of TIMESYNC NLM

How do servers establish time synchronization in the first place?

When a server starts up, TIMESYNC NLM on Secondary and Primary servers obtains time from Single / Reference servers as appropriate and sets the RTC (Real Time Clock) of the computer. The original time of the RTC is totally disregarded by this operation. Once the RTC of the Secondary / Primary server has been set, time synchronization should be established.

For a Single or Reference server that does not point to a NTP time source, TIMESYNC NLM copies time from RTC into its buffer, and declares that time is synchronized. By definition, Single or Reference (that do not point to NTP time sources) will always be synchronized.

If a Single or Reference server points to an NTP time source, its behavior is identical to that of Secondary or Primary servers.

How and why can servers fall out of time synchronization?

Assuming that servers have been synchronized for some time, exceptional conditions may cause them to fall out of time synchronization. Some of the conditions can be:

 A clogged network  A faulty router  An NLM that hogs CPU cycles and prevents the software clock from being updated  An NLM that sets off clock interrupts so that the software clock does not get updated

What are the differences between a Primary and Secondary server when obtaining time from multiple sources?

A Secondary server may be setup to have multiple time sources. However, it will contact only one time source. It will attempt to contact the next time source only if it fails to obtain a response from the first time source. After obtaining time from the time source, a Secondary server will adjust its clock to approach the time obtained. However, in this process, the Secondary server does not give any importance to its own clock. For example, if a Secondary server has the time 10:03, and the time obtained from the Single server is 10:04, the difference of 60 seconds is made up by accelerating the clock gradually over a polling interval. If the polling interval is 600 seconds, an adjustment of 60 / 600 or 1 second for every 10 seconds elapsed is made.

This gradual adjustment of time is very important. Sudden changes of time can throw many distributed applications out of gear.

A Primary server contacts all its time sources, and not just one of them (as the Secondary server does). This is done during every polling interval. The Primary server then calculates the average of all the values. Time from Reference servers is given more importance than the time obtained from Primary Servers. This is done by assigning a weight of 16 to the time from the Reference server and a weight of 1 to that obtained from other Primary servers. The difference in time is gradually applied to the RTC of the server.

Should the Single or Reference server be a NetWare 4.11 or a NetWare 5 server?

As mentioned before, apart from protocol differences, there are no fundamental differences between the working of TIMESYNC NLM between NetWare 4.11 and NetWare 5. At a fundamental level, it does not matter whether the Single server is on a NetWare 4.11 or a NetWare 5 server. Actually, a TIMESYNC NLM server has no way of making out if the time is from a NetWare 4.11 or from NetWare 5 (the packet formats are identical).

However, other considerations may favor one or the other alternative. If you need to set up the Single server to obtain time from an NTP time source, this is possible only in NetWare 5.