We have a setup of two WiSMs (4 WLCs) in the HO and multiple branches connected to the
HO through MPLS with the same ISP.
In one of the branches, the APs are unable to join any of the cotrollers. I
troubleshooted this issue from different aspects with no success.
The APs are getting the management IP address of the four WLCs through DHCP option 43:
ip dhcp pool AccessPoints network 10.3.3.0 255.255.255.0 default-router 10.3.3.254 option 60 hex 4369.7363.6f20.4150.2063.3132.3430 option 43 hex f110.0a63.0601.0a63.0602.0a63.0603.0a63.0604
Which translates into 10.99.6.1, 10.99.6.2, 10.99.6.3, 10.99.6.4
I captured the APs traffic and found out the following:
- the APs get the controller IPs and send LWAPP discovery requests to all of them. - LWAPP Discovery responses arrive at the APs from all of the four WLCs. - APs send LWAPP join requests to all the AP Manager IPs of the WLCs.
According to Cisco documentation, the AP will pad the packet with additional data
until it exceeds the 1500 Byte MTU size and then sends it again with less padding
until it doesn't get fragmented.
The problem happens when the first LWAPP join request is sent from the APs. It gets
fragmented and never reaches the WLCs. Consequently, the APs give up immediately and
never send a subsequent LWAPP Join request and keep reloading and repeating the same
Even after I configured one AP as H-REAP and with static WLC IP addresses, it still faces the same issue.
I captured the fragmented packets that reached the HO from this H-REAP. Please find them attached to
I need to know what to do in order to allow the join request to reach the controllers.
There is no Firewall blocking the traffic, any traffic to the entire HO subnetwork is
The dynamic MTU discovery you refer to is on the 5.2 and higher versions. Prior to those versions there were issues with the join request and fragmentation. The issue is that the controller will drop any packet where the payload is less than 32 bytes. This can happen as the 1500 byte portion of the join request goes over a WAN.
Best way to get around this issue is the run 5.2 or 6.0 on the controller and prime the AP's before installing them at the remote sites. This way you will get the dynamic MTU discovery.
Its hard to tell with this capture since its filtered. Keep in mind that the join request is being sent to the controller's AP-Manager interface, not to the Management interface like the discovery request.
OK, so 10.99.6.201-203 are the ap-mgr interfaces. In that case you are missing about 1500 bytes of the join request. The Join request is over 1500 bytes so it is sent from the AP as a 1500-byte packet and a 68-byte packet. In your capture you are only seeing the fragment, not the main part of the join request. Looks like packets are being dropped somewhere between the AP and controller.
Following the capture of the branch and comparing it to what was received at the HO WAN router, you can notice that the entire LWAPP Join Request packet left the branch WAN router and what was received at the HO router is the fragment.
It would be really interesting to know what causes the ISP to drop the 1500 KByte frame and forward only the fragment to the HQ router.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...