1000003 DHCP Server Abnormal
Description
If the Dynamic Host Configuration Protocol (DHCP) server is Windows, the alarm module checks the DHCP server every 2 minutes. This alarm is generated when the alarm module detects that the DHCP server is abnormal or unavailable for three consecutive times. This alarm is cleared when the alarm module detects that the DHCP server becomes normal.
If the DHCP server is Linux, the DHCP server sends a heartbeat message to the IT adapter (ITA) every 2 minutes. This alarm is generated when the ITA does not receive the DHCP heartbeat message for three consecutive times. This alarm is cleared when the ITA receives the DHCP heartbeat message again.
Attribute
Alarm ID |
Alarm Severity |
Auto Clear |
---|---|---|
1000003 |
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:
|
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
Users cannot use VMs because the VMs cannot obtain IP addresses.
Possible Causes
- IP address conflict.
- The IP address has been changed. The alarms generated by the IP address must be manually cleared and the alarm component information must be reconfigured.
- The network is faulty.
- The DHCP server is not running properly.
Procedure
- Check the OS of the server on which the alarm is generated.
- Log in to the ITA server as user gandalf, and check whether the DHCP server network is normal. Run ping -c 3 IP address of the DHCP server on the CLI to check whether the network is normal.
- If yes, go to Step 5.
- If no, go to Step 3.
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.)
- Locate and rectify the network fault based on the actual situation on site.
- Choose FusionAccess > Alarm to check whether the alarm still exists.
- If yes, go to Step 5.
- If no, no further operation is required.
- Use an existing account (domain account or local account) in the environment to log in to the DHCP server.
- Choose
> Windows Administrative Tools > Services to open the service list.
- Check whether the status of Huawei Monitor Service is Started.
- Right-click Huawei Monitor Service and choose Restart or Start. Check whether the status of Huawei Monitor Service is Started.
- If yes, go to Step 9.
- If no, contact Huawei technical support.
- Choose FusionAccess > Alarm to check whether the alarm still exists.
- If yes, go to Step 10.
- If no, further operation is required.
- Check whether the DHCP Server service is in the Running state, as shown in Figure 79-4.
- If yes, contact Huawei technical support.
- If no, go to Step 11.
- Restart the DHCP server.
- Choose FusionAccess > Alarm to check whether the alarm still exists.
- If yes, go to Step 13.
- If no, no further operation is required.
- Restore the faulty DHCP server. For details, see Backup and Restoration > System Restoration > Restoring the AD/DNS/DHCP Server in the FusionAccess Desktop Solution 6.5 System Management Guide.
- Choose FusionAccess > Alarm to check whether the alarm still exists.
- If yes, contact Huawei technical support.
- If no, no further operation is required.
- 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 16.
- If no, go to Step 18.
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.)
- 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 17.
- Choose FusionAccess > Alarm to check whether the alarm still exists.
- If yes, go to Step 18.
- If no, no further operation is required.
- On the server where the alarm is generated, run the service dhcpd status to check whether the status of dhcpd is normal.
- If yes, contact Huawei technical support.
- If no, go to Step 19.
- Run service dhcpd restart to restart dhcpd. Two minutes after successful restart, 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