★ Device can not come online Cloudnet troubleshooting steps

2023-12-29 15:18:40 Published

0 Followed
1Collected ，5734Browsed

Naomi

Network Topology

Traditional topology

Problem Description

Device can not come online Cloudnet

Process Analysis

1 Failure to Add the Device SN

1.1 Check Whether the Device Model Is Supported by Cloudnet

First verify that the device model is adapted by Cloudnet.

NOTE You can query device adaptation on the Cloudnet Support Matrix page. Log in to the Cloudnet web portal, click Manuals at the top right of the page, and then select SupportMatrix, as shown in the following figures.

Figure 1 Selecting SupportMatrix from the Manuals menu

Figure 2 Support Matrix page on International Cloudnet

1.2 The Device Has Been Registered with Another Account

NOTE If the device has already been registered, you must unbind it from the original account before adding it to Cloudnet.

1. If you can log in to the original account: delete the device from that account directly, and then add the device under the new account to bring it online.

Figure 3 Deleting the device under the original account

2. If you cannot log in to the original account: obtain an unbinding code from Cloudnet, execute the unbinding command in the device CLI, and then add the device to the cloud.

Figure 4 Obtaining the unbinding code on the Device Unbinding page

3. If self-service unbinding cannot be completed: provide supporting evidence (a time-stamped photo of the AP) and send an email to h3cts@h3c.com to apply for unbinding by the backend.

2 The Device Is Added but Fails to Come Online

2.1 Verify That the SN Is Correct

If the SN is incorrect but the BOM is correct, the device will still be added to Cloudnet. In this case, the device status is Established on the device side, while Cloudnet shows the device as offline.

2.2 (Optional) IRF Check for Switch Devices

If the device is a switch, determine whether IRF is used. If IRF is used, make sure that all devices establishing the IRF fabric are added to the same IRF group.

Figure 5 Adding IRF member devices to the same IRF group

2.3 Public Network Connectivity and DNS Tests

1. (Optional) Check IP address: If the device is an AP, check whether VLAN 1 is being used as the management VLAN; if a different VLAN is used, it must first be created in Cloudent.

Path: Network > Settings > Cloud AP > VLAN Settings

Figure 6 Adding Cloud AP VLANs

2. Check routes: check the routes to confirm connectivity between the device and the public network. For example:

[WA6630]dis int b
*down: administratively down
(s): spoofing (l): loopback
Interface Physical Protocol IP Address Description
Vlan1 up up 192.168.1.5 --
[WA6630]ping -c 10 -a 192.168.1.5 8.8.8.8
Ping 8.8.8.8 (8.8.8.8) from 192.168.1.5: 56 data bytes, press CTRL_C to break
56 bytes from 8.8.8.8: icmp_seq=0 ttl=113 time=5.268 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=3.962 ms

3. Verify connectivity to Cloudnet: confirm connectivity between the device and Cloudnet. For example:

<WA6636>ping oasiscloud.h3c.com
Ping oasiscloud.h3c.com (52.163.242.100): 56 data bytes, press CTRL_C to break
56 bytes from 52.163.242.100: icmp_seq=0 ttl=113 time=5.268 ms
56 bytes from 52.163.242.100: icmp_seq=1 ttl=113 time=3.962 ms

4. Check DNS resolution: if the device can ping a public IP address but cannot ping public domain names — for example, pinging oasiscloud.h3c.com on the device does not resolve the correct IP address — the DNS configuration on the device is incorrect.

5. Use a public DNS server: ISPs usually have their own DNS servers, and some DNS servers fail to resolve oasiscloud.h3c.com or cannot resolve it. In this case, try configuring 8.8.8.8 as the DNS server on the device.

6. Configure a static domain mapping: if DNS resolution still fails or no DNS server is available, try configuring a static domain name mapping to check whether the device can come online (not recommended for long-term use):

ip host oasiscloud.h3c.com 52.163.242.100

2.4 Verify MTU and TCP MSS Settings

1. Test with large packets: if the device can ping the public network and DNS resolution works correctly, check whether the packets sent from the device to the cloud are oversized. Try pinging with large packets. For example:

<WA6636>ping -s 1400 www.google.com
Ping www.google.com (31.13.94.37): 1400 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- Ping statistics for www.google.com ---
5 packet(s) transmitted, 0 packet(s) received, 100.0% packet loss

2. Find the maximum passing packet size: if the ping fails, decrease the packet size gradually to find the maximum size that can pass. For example:

<WA6636>ping -s 1300 www.google.com
Ping www.google.com (31.13.94.37): 56 data bytes, press CTRL_C to break
56 bytes from 31.13.94.37: icmp_seq=0 ttl=112 time=75.764 ms
56 bytes from 31.13.94.37: icmp_seq=1 ttl=112 time=52.661 ms
56 bytes from 31.13.94.37: icmp_seq=2 ttl=112 time=60.651 ms
56 bytes from 31.13.94.37: icmp_seq=3 ttl=112 time=64.823 ms
56 bytes from 31.13.94.37: icmp_seq=4 ttl=112 time=52.918 ms
--- Ping statistics for 31.13.94.37 ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 52.661/61.363/75.764/8.566 ms

3. Configure MTU and TCP MSS: configure the following settings on the egress VLAN interface. Also make sure that devices between the local device and Cloudnet negotiate the correct MSS and MTU values:

[WA6636]int vlan 1
[WA6636-Vlan-interface1]tcp mss xxx
[WA6636-Vlan-interface1]mtu xxx

2.5 Ensure That Required IP Addresses and Ports Are Permitted on the Firewall or Internet Behavior Management Device

Make sure that the firewall or Internet behavior management device permits the following IP addresses and ports.

IP Address	Protocol	Source Port	Destination Port
52.163.242.100	TCP	any	80/443/19443
52.187.3.51	TCP	any	80/443/19443
172.188.163.61	TCP	any	80/443/19443/17443
20.212.143.78	TCP	any	80/443/17443
4.194.169.132	TCP	any	80/443/17443
13.76.182.179	TCP	any	80/443
13.76.252.214	TCP	any	5555/28443
52.187.0.95	TCP	any	80/443
4.194.200.126	TCP	any	57000/57001/57500/57080/57443/10000-49999
20.247.232.140	UDP	any	5683

Table 1 IP addresses and ports required by Cloudnet (Singapore cloud)

2.6 Collecting Information If the Device Is Still Offline

If the device still fails to come online after the preceding checks, collect the following information:

1. Collect the command output:

<H3C>display cloud-management state
<H3C>sys
[H3C]probe
[H3C-probe]display system internal cloud-management state

2. Collect online debugging information: enable debugging, collect the debugging information for 3 to 4 minutes, and then disable debugging:

[H3C]debugging cloud-management all
[H3C]t m
[H3C]t d

[H3C]undo debugging cloud-management all
[H3C]u t m
[H3C]u t d

3. Collect the diagnostic information (diag-info) of the offline device:

Method A: save the operation record and save the displayed information through the terminal to save the session. (The output is long and takes some time to display.)

[H3C]display diagnostic-information
Save or display diagnostic information (Y=save, N=display)? [Y/N]: n

Method B: save the diagnostic information to the device storage, and export the file through FTP.

[H3C]dis diagnostic-information
Save or display diagnostic information (Y=save, N=display)? [Y/N]: y
Please input the file name (*.diag) [cfa0:/default.diag]:
Diagnostic information is outputting to cfa0:/default.diag.
Please wait...
Save successfully.