Configurations Fail to Be Delivered to Cloud APs

Symptom

Configurations fail to be delivered to cloud APs.

Possible Causes

• Network problems occur.

  When the network is unstable, a cloud AP goes offline almost at the same time as the configuration delivery failure.

• Cloud APs restart.

  A cloud AP is restarting. After the AP is restarted, the configuration will be delivered successfully.

• The maximum transmission unit (MTU) of an AP channel is small.

  The default channel MTU of a cloud AP is 1400, corresponding to the maximum segment size (MSS) of 1360. Tunnels are configured on some networks, and their MTU or MSS values are smaller than the default settings.

Troubleshooting Procedure

1. Check whether a cloud AP goes online on iMaster NCE-Campus. If not, rectify the fault according to A Cloud AC or AP Fails to Go Online.
2. Check network connectivity between the AP and iMaster NCE-Campus.

   Run the ping command to check whether packet loss occurs between the AP and iMaster NCE-Campus. If packet loss occurs, configurations may fail to be delivered. In this case, ensure network stability.

   1. Check whether Ethernet0/0/47 on the device is Up and has a correct IP address configured.

      #
      interface Ethernet0/0/47
       ip address 169.254.3.1 255.255.255.0
      #

   2. Check whether the bidirectional ping operations are successful.

      <AP> ping -c 1000 10.1.1.1
      PING 10.1.1.1: 56  data bytes, press CTRL_C to break
      Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=128 time=3 ms
      Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=128 time=1 ms
      Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=128 time=1 ms
      Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=128 time=1 ms
      Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=128 time=1 ms
      
      --- 10.1.1.1 ping statistics ---
      5 packet(s) transmitted
      5 packet(s) received
      0.00% packet loss
      round-trip min/avg/max = 1/1/3 ms

   3. On the cloud AP, log in to iMaster NCE-Campus through Telnet.

      <AP> telnet 10.1.1.1 10020

   If the ping operation fails, check the network between the AP and iMaster NCE-Campus. Ensure that they can communicate with each other. If the ping operation succeeds but Telnet fails, check whether port 10020 is disabled.

3. Check whether the MTU is configured properly.
   # Perform the ping operation between the AP and iMaster NCE-Campus using packets of the specified size.

   <AP> ping -s 1372 -f 10.1.1.1  //The MTU corresponding to 1372 is 1400, and the MSS value is 1360.
   PING 10.1.1.1: 1500  data bytes, press CTRL_C to break
   Reply from 10.1.1.1: bytes=1372 Sequence=1 ttl=128 time=3 ms
   Reply from 10.1.1.1: bytes=1372 Sequence=2 ttl=128 time=1 ms
   Reply from 10.1.1.1: bytes=1372 Sequence=3 ttl=128 time=1 ms
   Reply from 10.1.1.1: bytes=1372 Sequence=4 ttl=128 time=1 ms
   Reply from 10.1.1.1: bytes=1372 Sequence=5 ttl=128 time=1 ms
   
   --- 10.1.1.1 ping statistics ---
   5 packet(s) transmitted
   5 packet(s) received
   0.00% packet loss
   round-trip min/avg/max = 1/1/3 ms

   If the ping operation fails, the MTU between the AP and iMaster NCE-Campus is improper. Change the MTU to a value greater than 1400 (default MTU value of a cloud AP). The procedure is as follows:

   • In a private cloud scenario, change the MTU value of the intermediate network between the cloud AP and iMaster NCE-Campus.
   • In a public cloud scenario, run the tcp adjust-mss mss command in the WAN view of the AP to change the MSS of TCP packets on the interface, or run the mtu mtu command in the view of VLANIF 1 to modify the MTU.

   For devices connected across the public network, the MTU on the public network may change dynamically or the configuration may fail to be delivered. In this case, adjust the MTU value based on the actual situation.

4. Rectify the fault by referring to the troubleshooting procedure on iMaster NCE-Campus.

   For details, see Service Configuration Delivery Fails.

5. If the fault persists, collect the following information and seek technical support:
   1. Collect debugging information.

      <Huawei> terminal debugging
      <Huawei> terminal monitor
      <Huawei> debugging syslog
      [Huawei-diagnose] terminal diag-logging

      After running the preceding commands, wait for 10 minutes and save the information in the command output.

   2. Collect device and log information.
      • Device information

        Information Type	Command View	Command
        Version	Diagnostic view	vrbd
        Patch information	All views	display patch-information
        Startup information	All views	display startup
        Configuration information	All views	display current-configuration
        File system information	All views	dir flash:/

      • Log files

        Export all log files (in the .dblg, .log, .dblg.zip, or .log.zip format) that record the fault occurrence time in the flash:/logfile directory using FTP or the web platform.