Alcatel Carrier Internetworking Solutions omniswitch User Manual
Configuring Network Time Protocol (NTP)
NTP Overview
OmniSwitch 6600 Family Switch Management Guide
March 2005
page 3-7
When planning your network, it is helpful to use the following general rules:
• It is usually not a good idea to synchronize a local time server with a peer (in other words, a server at
the same stratum), unless the latter is receiving time updates from a source that has a lower stratum
than from where the former is receiving time updates. This minimizes common points of failure.
than from where the former is receiving time updates. This minimizes common points of failure.
• Peer associations should only be configured between servers at the same stratum level. Higher Strata
should configure lower Strata, not the reverse.
• It is inadvisable to configure time servers in a domain to a single time source. Doing so invites
common points of failure.
Note. NTP does not support year date values greater than 2035 (the reasons are documented in RFC 1305
in the data format section). This should not be a problem (until the year 2035) as setting the date this far in
advance runs counter to the administrative intention of running NTP.
in the data format section). This should not be a problem (until the year 2035) as setting the date this far in
advance runs counter to the administrative intention of running NTP.
Authentication
NTP is designed to use MD5 encryption authentication to prevent outside influence upon NTP timestamp
information. This is done by using a key file. The key file is loaded into the switch memory, and consists
of a text file that lists key identifiers that correspond to particular NTP entities.
information. This is done by using a key file. The key file is loaded into the switch memory, and consists
of a text file that lists key identifiers that correspond to particular NTP entities.
If authentication is enabled on an NTP switch, any NTP message sent to the switch must contain the
correct key ID in the message packet to use in decryption. Likewise, any message sent from the authenti-
cation enabled switch will not be readable unless the receiving NTP entity possesses the correct key ID.
correct key ID in the message packet to use in decryption. Likewise, any message sent from the authenti-
cation enabled switch will not be readable unless the receiving NTP entity possesses the correct key ID.
The key file is a text (.txt) file that contains a list of keys that are used to authenticate NTP servers. It
should be located in the /networking directory of the switch.
should be located in the /networking directory of the switch.
Key files are created by a system administrator independent of the NTP protocol, and then placed in the
switch memory when the switch boots. An example of a key file is show below:
switch memory when the switch boots. An example of a key file is show below:
2
M
RIrop8KPPvQvYotM
# md5 key as an ASCII random string
14
M
sundial
# md5 key as an ASCII string
In a key file, the first token is the key number ID, the second is the key format, and the third is the key
itself. (The text following a “#” is not counted as part of the key, and is used merely for description.) The
key format indicates an MD5 key written as a 1 to 31 character ASCII string with each character standing
for a key octet.
itself. (The text following a “#” is not counted as part of the key, and is used merely for description.) The
key format indicates an MD5 key written as a 1 to 31 character ASCII string with each character standing
for a key octet.
The key file (with identical MD5 keys) must be located on both the local NTP client and the client’s
server.
server.