S 2.152 Design of a time synchronisation concept

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators

The stability of a Netware  4.x network depends to great extent on the time synchronisation and is closely related to the Novell Directory Services (NDS)

In this case, time synchronisation means that, in a network incorporating NDS and containing several Netware servers, the clocks on these servers must display the same time. The standard tolerance is two seconds. In other words, the time deviation must not exceed two seconds between any of the clocks on the Netware servers of the NDS. If this is ensured, the clock time in the network is said to be synchronised.

In a multi-server network, several replications and/or partitions of the NDS are generally distributed among the Netware servers. If one of the NDS partitions is modified, it is supplied with a time stamp. During the next NDS comparison, this modification is forwarded to the partitions and replications on the other Netware servers in the network. If the clock on one of the Netware servers which receives this modification is an hour behind and is thereby not in sync, the changes for this NDS replication or partition can only be synchronised when the affected server is in sync again.

In principle, a distinction can be made between the following two scenarios:

• Single reference model

This time model is recommended by Novell for networks with up to 30 Netware servers. It is very easy to configure, and does not require detailed planning of the time synchronisation.

In this model, one single Netware server acts as the source of the clock signal (single reference), while the remaining Netware servers only act as signal recipients. The single-reference server indicates the time for the entire network, and thus needs to be linked with an external time source (e.g. a radio clock).

A major disadvantage of this time model is that a failure of the single-reference server would lead to a lack of time synchronisation, as well as all the resulting consequences.

• Time provider groups

In large networks, it is advisable to use time provider groups. These groups are easy to configure but require appropriate planning. Several Netware servers share the time server role. One of them is the reference server, which should be connected to an external time source.

Primary time servers are located one level below the reference server; at least two primary servers must exist in a network. There is hardly any difference between this type of time server and a reference server. Together, all reference and primary servers determine the valid network time and pass on this time to the secondary servers. The reference server is the stable factor in the network. As the reference server does not adjust its clock to agree with the network time, the network time must be adjusted to agree with the reference server. It is therefore the reference server that must be used when the network time is to be corrected. Primary servers, on the other hand, adjust their clocks to agree with the network time.

A decisive advantage of this model is that the primary servers serve as substitute sources of the clock signal, thus allowing time synchronisation to be continued even if the reference server fails. In spite of Novell's recommendation to use this model in networks consisting of 30 or more Netware servers, its use is also possible with a notably lower number of Netware servers.

In the standard configuration, time servers, single-reference servers, reference servers and primary servers are published dynamically in the network with SAP/RIP mechanisms. This has the disadvantage, that it is not possible to influence which time servers communicate with each other. This may be particularly undesirable in the case of WAN links. For this reason, it is possible to work with configurable lists and disable the SAP/RIP mechanisms.

The following items need to be observed during the design of a time synchronisation concept:

• An external time source (e.g. radio clock) should be installed in all networks containing more than one Netware server.

• For WAN links within a network, in which the NDS is implemented, at least one timer should be present at a location with several Netware  4.x servers, so that the local secondary servers can fall back on a local time server.

• If, due to a faulty configuration, the clock time set on a Netware server lies far in the future (say, one year), the server would issue after the conversion to the correct time the error message "Synthetic time ..." for all NDS events for a period of one year. This error message could be removed by declaring a new time phase in the DSREPAIR.NLM program. This would delete and recreate the entire NDS on the server. To interfere with the NDS in this way is a rather drastic measure and should therefore be well thought out.

Additional controls:

• Has the time synchronisation been planned appropriately?