No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FusionAccess 6.5 Alarm Handling 04

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
1000017 Communication Between the System and the NTP Server Is Abnormal

1000017 Communication Between the System and the NTP Server Is Abnormal

Description

The alarm module checks the communication between the system and the Network Time Protocol (NTP) server every 2 minutes. This alarm is generated when the alarm module detects that the communication between the system and the NTP server is abnormal for three consecutive times. This alarm is cleared when the alarm module detects that the communication between the system and the NTP server is normal.

Attribute

Alarm ID

Alarm Severity

Auto Clear

1000017

Critical

Yes

Parameters

Name

Meaning

Alarm ID

Identifies an alarm. Each alarm is uniquely identified by an alarm ID and an alarm name.

Alarm Severity

Indicates the severity of an alarm. Value:

  • Critical: indicates that a fault affecting services provided by the system occurs. You need to rectify the fault immediately. If a device or resource is faulty, rectify it immediately even if the fault occurs during non-working hours.
  • Major: indicates that a fault affecting the service quality of the system occurs. You need to rectify the fault immediately. If the service quality of a device or resource is degraded, rectify it immediately during working hours.
  • Minor: indicates a fault that does not affect service quality. To prevent more serious faults, this type of alarm needs to be observed or handled if necessary.
  • Warning: indicates a fault that may affect service quality. This type of alarm must be handled based on the error type.

Alarm Name

Identifies an alarm. Each alarm is uniquely identified by an alarm ID and an alarm name.

Object Type

Specifies the type of the object for which the alarm is generated.

Alarm Object Name

Specifies the name of the object for which the alarm is generated.

Generation Time

Specifies the time when the alarm is generated.

Clear Time

Specifies the time when the alarm is cleared.

Clear Mode

Specifies whether the alarm is manually or automatically cleared.

Operation

Specifies the operation that can be performed on the alarm.

Value: Manually Clear Alarm

Impact on the System

Abnormal communication between the system and the NTP server may cause time being out of sync between the system and other components. This may also bring the following effects.

  • When the time difference between the WI and the AD exceeds 5 minutes, users cannot log in to VMs properly.
  • When the AD time difference increases but time synchronization is not performed, the time on all user VMs is incorrect because the user VMs (that are provisioned or about to be provisioned) synchronize time with the AD.
  • When the time difference between the AD and the ITA exceeds 5 minutes, the provisioning task will fail.

Possible Causes

  • IP address conflict.
  • An upper-layer clock source is not installed for an AD server.
  • The network is faulty.
  • The W32Time service stops abnormally on Windows components.

Procedure

  1. Check the component of the server on which the alarm is generated.

    • For the AD, DNS, or DHCP components, go to Step 2.
    • For other components, go to Step 18.

    Check the clock source configuration.

  2. Choose FusionAccess > System > Time Management to check whether a superior clock source is installed.

  3. Choose FusionAccess > System > Time Management to configure upper-layer clock source.
  4. After 5 minutes, Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 5.
    • If no, no further operation is required.

    Check the network.

  5. Check the OS of the server on which the alarm is generated.

    • If the OS is Windows, go to Step 6.
    • If the OS is Linux, go to Step 11.

  6. Log in to the system server using the domain account, choose Start > Administrative Tools > Services to open the service list.
  7. Check whether the Windows Time service is in the Started state.

  8. Right-click Windows Time, and choose Restart from the shortcut menu.
  9. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 10.
    • If no, no further operation is required.

  10. On the server for which the alarm is generated, check whether the network connection with the NTP server is normal.

    1. Choose Start > Run.
    2. Enter cmd and click OK to go the the CLI.
    3. Run ping IP address of the NTP server to check whether the communication is normal.
    • If yes, go to Step 17.
    • If no, go to Step 15.

      The communication is normal if the command output is as follows:

      Pinging 192.168.131.66 with 32 bytes of data: 
       
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
           (Note: The IP addresses are only examples. Use the actual IP addresses.)

  11. Log in to the server where the alarm is generated using an administrator account and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command to check whether IP conflict occurs.

    • If yes, go to Step 12.
    • If no, go to Step 14.

      If the information similar to the following is displayed, no IP conflict occurs:

      ARPING 192.168.162.11 from 0.0.0.0 eth0 
      Sent 3 probes (3 broadcast(s)) 
      Received 0 response(s) 
      (Note: The IP addresses are only examples. Use the actual IP addresses.)     

      If the information similar to the following is displayed, IP conflict occurs:

      ARPING 192.168.162.11 from 0.0.0.0 eth0 
      Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms 
      Sent 1 probes (1 broadcast(s)) 
      Received 1 response(s) 
      (Note: The preceding IP addresses and MAC addresses are only examples. Use the actual IP addresses and MAC addresses.)     

  12. Log in to the server that causes the IP conflict, shut down the server or change the server IP address, and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command again on the server where the alarm is generated to check whether the IP conflict persists.

    • If yes, contact Huawei technical support.
    • If no, go to Step 13.

  13. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 14.
    • If no, no further operation is required.

  14. On the server where the alarm is generated, run the ping -c 3 NTP server IP address command to check whether the network connection to the NTP server is normal.

    • If yes, go to Step 17.
    • If no, go to Step 15.

      The communication is normal if the command output is as follows:

      PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 
      64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 
      64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 
      64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms 
      (Note: The IP addresses are only examples. Use the actual IP addresses.)     

  15. Locate and rectify the network fault.
  16. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 17.
    • If no, no further operation is required.

  17. Check the component of the server on which the alarm is generated.

    • If the component is the AD component, contact Huawei technical support.
    • If the component is not the AD component, go to Step 18.

    Check whether the communication between the AD server and the system server is normal.

  18. Check the OS of the server on which the alarm is generated.

    • If the OS is Windows, go to Step 19.
    • If the OS is Linux, go to Step 25.

  19. Check whether the component type of the server for which the alarm is generated is DNS or DHCP.

  20. Log in to the system server using the domain account, choose Start > Administrative Tools > Services to open the service list.
  21. Check whether the Windows Time service is in the Started state.

  22. Right-click Windows Time, and choose Restart from the shortcut menu.
  23. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 24.
    • If no, no further operation is required.

  24. On the server for which the alarm is generated, check whether the network connection with the AD server is normal.

    1. Choose Start > Run.
    2. Enter cmd and click OK to go the the CLI.
    3. Run ping AD server IP address to check whether the communication is normal.
    • If yes, contact Huawei technical support.
    • If no, go to Step 30.

      The communication is normal if the command output is as follows:

      Pinging 192.168.131.66 with 32 bytes of data: 
       
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
      Reply from 192.168.131.66: bytes=32 time<1ms TTL=128 
           (Note: The IP addresses are only examples. Use the actual IP addresses.)

  25. Check whether the component type of the server for which the alarm is generated is DNS or DHCP.

  26. Log in to the server where the alarm is generated using an administrator account and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command to check whether IP conflict occurs.

    • If yes, go to Step 27.
    • If no, go to Step 29.

      If the information similar to the following is displayed, no IP conflict occurs:

      ARPING 192.168.162.11 from 0.0.0.0 eth0 
      Sent 3 probes (3 broadcast(s)) 
      Received 0 response(s) 
      (Note: The IP addresses are only examples. Use the actual IP addresses.)     

      If the information similar to the following is displayed, IP conflict occurs:

      ARPING 192.168.162.11 from 0.0.0.0 eth0 
      Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms 
      Sent 1 probes (1 broadcast(s)) 
      Received 1 response(s) 
      (Note: The preceding IP addresses and MAC addresses are only examples. Use the actual IP addresses and MAC addresses.)     

  27. Log in to the server that causes the IP conflict, shut down the server or change the server IP address, and run the arping -c 3 -f -D -I eth0 IP address of the server where the alarm is generated command again on the server where the alarm is generated to check whether the IP conflict persists.

    • If yes, contact Huawei technical support.
    • If no, go to Step 28.

  28. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 29.
    • If no, no further operation is required.

  29. On the server where the alarm is generated, run the ping -c 3 AD server IP address command to check whether the network connection to the AD server is normal.

    • If yes, go to Step 32.
    • If no, go to Step 30.

      The communication is normal if the command output is as follows:

      PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 
      64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 
      64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 
      64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms 
      (Note: The IP addresses are only examples. Use the actual IP addresses.)     

  30. Locate and rectify the network fault.
  31. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, go to Step 32.
    • If no, no further operation is required.

  32. If the AD server is a LiteAD server, check whether the LiteAD server reports the "System Time Changes" alarm and process it according to 1000018 System Time Changes.
  33. Choose FusionAccess > Alarm to check whether the alarm still exists.

    • If yes, contact Huawei technical support.
    • If no, no further operation is required.

Related Information

None

Translation
Download
Updated: 2019-10-11

Document ID: EDOC1100061083

Views: 4101

Downloads: 14

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next