Fragmented LWAPP Join Request

[shasanain]

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

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

allowed.

[dancampb]

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.

[shasanain]

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?

[dancampb]

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.

[shasanain]

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 (10.99.6.201, 202, 203, 5).

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

[dancampb]

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.

[shasanain]

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.

[shahedvoicerite]

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

http://www.ccda.biz/en/US/products/ps6366/products_tech_note09186a00808f8599.shtml#P14

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 ?

[shahedvoicerite]

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.