Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Fragmented LWAPP Join Request

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
   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,,,

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

steps again.

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

this message.

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


Everyone's tags (1)

Re: Fragmented LWAPP Join Request

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.

New Member

Re: Fragmented LWAPP Join Request

Thanks for the reply.

Please note in the fragmented LWAPP join packet, as far as I can understand from the capture attached to my post, only a fragment of the packet arrived at the HO. Will this work after the upgrade?

Do you notice anything unusual about this WAN link? or this is the way a fragmented packet will look like in the capture?


Re: Fragmented LWAPP Join Request

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.

New Member

Re: Fragmented LWAPP Join Request

The filtering was done based on the IP address of the access point. All the traffic you see in the capture is what was received at the HO WAN router port.

I am aware that the Join requests are sent to the AP manager IP (, 202, 203, 5).

Again, would the captured packets be acceptable as LWAPP join requests in WLC version 5.2?


Re: Fragmented LWAPP Join Request

OK, so 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.

New Member

Re: Fragmented LWAPP Join Request

Thanks fo the note.

Any suggestion what may cause this drop?

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.

Any suggestions will be appreciated.

New Member

Re: Fragmented LWAPP Join Request

I too am in a similar situation,where I cannot get an AP 1130, that was previously joined to a cont

roller, to now join back, over a WAN/VPN

Discover responses go back to the AP, as seen in both controller and AP debugs.

The difference in my case is that I  have a site-to-site IpSec VPN.

Also, this is over cable modem, and the largest packet that does not get fragmented to the Manager Interface

is 1272 bytes.

I have upgraded to 5.2 code on my controller, although allowing frags in lwapp seems to have been fixed

in 4.0 onwards according to

I did not try setting the AP to H-REAP prior to taking it over the WAN, but will give that a try as well.

I have a feeling that it will make no difference, as you have pointed out.

I am not in a position to run a packet capture on the controller side, so I cant see if my fragments are being dropped,

before they get to the controller.

Did you manage to solve your problem ?

New Member

Re: Fragmented LWAPP Join Request

I updated my AP to run 5.2 after updating my controller.

Now the 1131AG LAP works both in H-REAP  * AND * Local mode !!!

This is over a L2L IpSec VPN.

CreatePlease to create content