|
Novell's Recommendations on Time Synchronization
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.
I need to synchronize my NetWare servers with an NTP. 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) will be available shortly on support.novell.com and will also be available on future support packs of NetWare 5.
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 NTP definition 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.
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 Advertisement 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 bridge 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 over IP. This feature is expected to be available in Support Pack 2.
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.
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 NT and Macs. 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.
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.
NTP believes that there can be only one time: the UTC time. UTC time is the number of seconds elapsed since 1st January, 1900. 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. 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 dropped 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 (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 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.
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, and subsequent servers were set to SECONDARY by the installation process. The Secondary servers discovered the Single server using SAP.
Since 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".
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 = <IP address of Server A>;
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.
Over IPX, I did not need to setup 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.
Can I use a server name in the configured sources?
In an IP only setup, IP addresses are preferred.
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.
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 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?
Absolutely. 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 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 have already been explained before.
Since 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 the UDP port 123. In other words, if you want your Unix machines to take time from a NetWare server, setup 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 (ntp.conf):
Server <DNS name or IP address of the NetWare 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.
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.
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 / 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 TIMSYNC.NLM?
Set parameter of TIMESYNC.NLM can be used to modify the traffic generated to suit your requirement. The following indicates the set parametes to be used to modify TIMESYNC.NLM traffic:
Advertisement Traffic - Use the timesync service advertising set parameter. Setting this parameter to off elimiates all advertisement traffic. This server cannot be discovered using auto discovery; explicit configuation is neede to take time from this server. Recommended for IPX and not for IP.
Discovery Traffic - There are no set parameters.
Time Request Traffic - There are three set parameters.
1- Timesync polling interval. Increase in polling interval may reduce traffic. Polling interval may be increased up to 60 minutes. Increasing the interval beyond 60 is not recommended.
2- Timesync synchronization radius. Increase in synchronization radius may reduce traffic. Syncchronization radius depends on the kinds of applications that run on networks. Some may need more precise time than others.
3- Time polling count. Timesync polls 3 times (the default vaalue of this parameter). A reduced value will reduce traffic. 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 Response Traffic - Depends entirely on request 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 an ephemeral port.
When communicating with an NTP time source, TIMESYNC NLM uses UPD 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 arbitrary 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 sometime, 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, including the time obtained from its own clock. Time from Reference servers is given more importance than the time obtained from Primary Servers. The difference in time is gradually applied over 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.11or from NetWare 5 (the packet formats are identical).
However, other considerations may favor one or the other alternative. If you need to setup the Single server to obtain time from an NTP time source, this is possible only in NetWare 5.
DNS Name Recognition feature and AutoDiscovery over IP in Timesync.NLM
DNS Name recognition feature has now been added to Timesync in ver 5.14 and will ship with NetWare Support Pack 4. So now a user can enter the DNS name of the NetWare server to contact for time instead of entering the IP address. The complete DNS name has to be entered including the domain name.
e.g. Timesync Time sources= MYSERVER.PROVO.NOVELL.COM;
If time is being taken from an NTP server, the DNS name need to be followed by the port no 123.
e.g. Timesync Time Sources = NTPSERVER.PROVO.NOVELL.COM:123;
Timesync internally resolves the name by doing a DNS lookup using the Winsock APIS exported by the winsock nlms. DNS feature works fine with NetWare 5 with Support Pack 3 installed on it. It may not work without SP3 as the winsock nlms had to be fixed for SP3.
Timesync can also now auto discover time sources over IP. This is also a feature that is being rolled out with Timesync ver 5.14. Timesync uses SLP in IP for autodiscovery of time sources. The autodiscovery in IP works the same way as autodiscovery in IPX which uses SAP. The set parameter which would enable this feature is TIMESYNC SERVICE ADVERTISING and DIRECTORY TREE MODE. Both of these need to be set ON.
TIMESYNC SERVICE ADVERTISNG set to ON enables Timesync to advertise the timesync.novell service in SLP. This would also enable advertiing over SAP if the server has the IPX stack enabled. The DIRECTORY TREE MODE set to ON confines autodiscovery to servers in the same NDS tree.
TIMESYNC.NLM Debug Switches
To open up the timesync debug screen , one needs to do set timesync debug=7 at the server console. At present there is only one Timsync debug switch enabled.
Timesync debug screen gives info like the time server type of thie server , which server was contacted for time and its time server type, at what time did the polling take place, what was the time offset discovered and if time is synchronized or not. This information is printed at each polling interval.
TID 2949745.
|
