NTP100 – Rev 2.2.0 Oct-12
40
© Masterclock
®
, Inc.
4. Verify that you are currently the only user accessing the clock via WinDiscovery or telnet.
5. The network may currently be experiencing heavy traffic which is reducing bandwidth and/or causing collisions
with the UDP messages/packets between the clock(s) and WinDiscovery. Since delivery of UDP messages are not
guaranteed, this can cause WinDiscovery to not receive the latest configuration or status packets, and thus show
outdated or garbled information. In some cases, the clock may not be discovered and displayed in the
WinDiscovery device tree. In others, previously discovered clocks may no longer be accessible or responding.
• Press the “Discover” button again and wait until the discovery process completes. This will occasionally
resolve issues with units not being discovered.
• Close the current WinDiscovery session and restart the WinDiscovery application.
• Take steps to increase the bandwidth and reduce network traffic.
• If this is an ongoing problem, consider the Telnet configuration method or remove the clock system to an
isolated LAN.
Problem: Device appears in RED text under WinDiscovery device tree.
Problem: Device is being assigned an IP address of 169.254.xxx.xxx
Problem: Device not maintaining its assigned IP address.
Problem: Device function is erratic, appears to periodically reset itself.
Possible reasons/solutions:
1. Incorrect network configuration may be causing the device to receive a fallback IP address and or perform soft
restarts. Verify that the IP address configured for the clock is correct. If you manually enter (or DHCP assigns) an
IP address that already exists on the network, this will create an IP address conflict. The device will reset its address
(fallback) to one within the link-local address space. Determine the cause of fallback IP address and resolve issue.
View the error status field under the status window to help determine the cause of why the clock received a
169.254.xxx.xxx. Near the bottom of the Status window the error will be displayed. (If there is no error the text box
will not be displayed.)
[Note: Devices which have been assigned a fallback IP address of 169.254.xxx.xxx will be displayed in the main
WinDiscovery window with RED text, indicating a problem with the configuration.]
When the Ethernet interface is initialized the network device will verify that the IP address (either static or assigned
by DHCP) is not being used by another device on the network. If a conflict is found the NTD clock will default to a
169.254.xxx.xxx address. The IP address that caused the error is saved and returned as an error to WinDiscovery.
This error status is available to the user via the Status window on WinDiscovery.
• If static IP addressing is being used the original conflicting static IP address can be restored by doing a soft
restart of the device using either WinDiscovery or telnet prior to changing any other configuration
parameters.
[IMPORTANT NOTE: if the configuration of the network device is changed while a 169.254.xxx.xxx is
being use, then the current 169.254.xxx.xxx address will become the permanent static address and the
original conflicting static address is lost. At this point, it is necessary to manually change the static IP
address to a one that will not conflict, or you may do a “Reset Configuration” to restore the system to factory
default settings.]
• If DHCP was selected and the network device fell back to a 169.254.xxx.xxx address approximately every
10 [depending upon the “Advanced Settings” values] minutes the Ethernet interface will be reinitialized
and the NTD clock will attempt to get an IP address from the DHCP server. If the NTD is successful, the
error will be cleared and the new address from the DHCP server will be used. If a discovery was done using
WinDiscovery or telnet was used this initialization will be delayed by 2 hours.
To Next Page
Loading...