[Case Study] Only part of APs can go online on the AC

In the cross-public-network scenario, only part of APs can go online on the AC.

[TroubleshootingSteps]

(1) Check the network topology, wireless configuration and version.

A. Deploy the APs and the AC (a single AC, noactive-standby ACs) across the public network. In hot-backup mode, check whether configurations of the active and standby ACs are the same.Configurations of normal APs and failed APs are exactly the same and the bind-ap-mac configuration is not set.

B. Requests of local users are locally forwarded, and gateway of APs and wireless users and the DHCP address pool are on the local aggregation switch. Troubleshot the local device.

C. The AC, normal APs and abnormal APs areall of the latest version, and online APs are of the same model. It means thatthe problem is not caused by the version and public network line of thecarrier.

(2) Log on to the failed AP to check the APmode and confirm whether any IP address is obtained. Check whether the largepacket can be communicated on the tunnel used for the AP to ping the AC.

Onsite check finds that the failed APs are in fit mode, the IP address can be obtained, and the large packet can be communicated on the tunnel.

(3) After check, we do not find any configuration difference between the access switch and the normal and failed AP interfaces, and the switch is in normal status.

(4) Collect logs and debugs on the failed APsand the AC.

The failed APs are always sending discoveryrequest packets. However, after the show capwap statistics command is run on the AC, the number of receiveddiscovery request packets does not increase. It is suspected that the discoveryrequest packets are discarded by intermediate link. Since the APs go online cross the public network and there are normal and failed APs, the problem is not caused by the public network line. It may be caused by the local device.

(5) Check the local device topology, egress EG, aggregation switch, access AC, and APs and capture packets at the uplinkinterface of the aggregation switch. Discovery request packets of failed APsare found. It is suspected that the packets are discarded at the egress EGdevice. Because we cannot directly capture packets for analysis at the egress,it is suspected that the application cannot identify the packets or the packetsare discarded because traffic of packets from the APs to the AC is too large,and thus some tunnels between APs and the AC cannot be created.

(6) Add the AP network segment to the egress device free of auditing and flow control, and place resources of users at thissegment to the EG key channel for preferential forwarding. The test resultshows that the failed APs can go online normally. After the resources are movedout of the key channel, the APs go offline after a period of time and cannot go online again.

[Cause]

Traffic on the key channel of the egress traffic control device is too large and thus the interaction packet for creating a tunnel between the AP and the AC is discarded.

[Solution]

Add traffic in the AP IP address segment tothe key channel of EG egress, to ensure that the AP packets are preferentiallyforwarded.

[Othertroubleshooting Commands]

Ø  On the AC, run the debug apmg join command to checkwhether the discovery request packet is received.

Ø  On the AP, run the debug capwap client fsm command tocheck whether the packet is successfully sent.

Ø  On the AP, run the debug capwap packet command to checkwhether the discover response packet is received. The prompt is displayedlater.

If no response packet is received, run thefollowing command on the AC:

debug efmp packet filter ipv4_sport range 5246 5247 counter30

Ø  If the AP tunnel cannot be created, run the following command on the AC to see whether a prompt is displayed:

debug efmp packet filter ipv4_sip host AP IP address  ipv4_sport eq 10000 counter 10

run-system-shell

dmesg

Ø  On the AC,run the show capwap ap tunnel id detail commandto see the following information:

If the data port changes frequently, thetraffic table is aging. You are recommended to adjust the channel keepalivetime to a smaller value

ap-config xxx

echo-interval xx (default: 30s; minimum:5s; maximum: 255s)