cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1898
Views
0
Helpful
15
Replies

LWAPP problem

derly_ali
Level 1
Level 1

I have 2 WLC 4404 with capacity of 100 AP each one and i have 170 AP around the country (MX).

all 170 ap's in this moment work in autonomous mode, i want to upgrade each one to LAP mode, i starting with 2 in one location trough the WAN but after i upgrade the AP's only one is Join in the controller and other one isnt join.

i went to the site with the failure and unmount the AP to carry to my site where i have the controllers, i connect the ap in the local subnet and the AP is joining to the controller.

i downgrade the AP to autonomous and try to upgrade one more time form the remote site and i present the same problem.

the release of the controller is: 3.2.195.10

i connected in the console of the failed AP but i dont save the logs i remember only this:

LWAPP_CLIENT_ERROR_DEBUG:

spamHandleJoinTimer: Did not recieve the Join response

LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain.

%SYS-5-RELOAD: Reload requested by LWAPP CLIENT.

Reload Reason: DID NOT GET JOIN RESPONSE.

%LWAPP-5-CHANGED: LWAPP changed state to DOWN

i attach some outputs of commands in the controller.

Please help me, i need to upgrade all ap's in my network

15 Replies 15

Rob Huffman
Hall of Fame
Hall of Fame

Hi Derly,

You may be running into this issue;

Have a look at the methods in this good doc;

Self-Signed Certificate Manual Addition to the Controller for LWAPP-Converted APs

http://www.cisco.com/en/US/products/ps7206/products_configuration_example09186a00806a426c.shtml

Hope this helps!

Rob

thanks for your help, but all of my AP's have MIC certificate,

somebody that help me?

Please...

How does the AP know WLC's management IP? If you are sure the AP had got the correct WLC IP, then check if WLC's managment IP subnet can communicate with AP's IP subnet bi-directionally, if not, it's a routing issue, check routing config and if there's any access-list forbit it. If the AP only depend on broadcasting in the same subnet to find WLC's IP, then check if you have forward this broadcasting to WLC

the AP know the management IP by DNS, there isnt a connectivity problem and there isnt ACL's in the network.

the problem is that one of the Two AP's in the site is joining to the controller and one not, i think that can be a bandwith issue or a bug in the controller but i want to be sure what is the problem and i want to know if i need to do an upgrade of the controller software.

Somebody help me!

Hi Derly,

You probably want to upgrade the WLC (I'm sorry I missed that earlier) 3.2.195.10 is getting quite old now (newest version is 5.x.x.x)

The support for some upgraded AP's like the 1121 was not added until 4.1.171.1 (I think)

Maybe this is the issue.

Rob

Derly,

Do you have WLC configured for Layer 3 LWAPP mode? This needs to be enabled if you are using light weights..I would check to see if this is option is set correctly.

yes i configured the WLC in layer three mode,

I upgrade the WLC to 4.1.185 version and the problem is still present,

the APs is 1131,

i upgrade other ap from other site and it is sucessful but when i try to upgrade one second AP from the same site it not register with the controller.

help me!!!

derly_ali
Level 1
Level 1

Ok the issue was resolved by CISCO TAC, the problem was in the WAN between the CO and remote site.

a class map of frame relay network.

What did TAC have you change? I have similar issue with some recently converted AP's and ma at a loss. I do have class-map statements enabled on some of my Frame connections, but this traffic should not match any of them...

i had a problem with a ACL in class-map that match with the UDP ports of WLC destination paquets,

like this:

access-list 102 permit udp any any range 16384 37276

access-list 102 permit udp any any range 8100 8150

access-list 102 permit udp any any range 2048 3028

access-list 102 permit udp any any range 49152 53246

we only remove the first line in the ACl (access-list 102 permit udp any any range 16384 37276) and add the command:

match protocol rtp audio

to match the RTP audio paquets instead of the ports in the ACL.

review your configurations and make a sniffing trace of all of your links between the WLC and the AP to determine what is the device that is droping the lwapp paquets

Hi,

Did TAC explain the relevance of the protocol rtp audio with the WLC/AP issue? I don't see the relationship.

ok, the ports in the range of the ACL:

access-list 102 permit udp any any range 16384 37276

are used by the WLC to send the JOIN_REPLY paquet to the remote AP, the use of this ports in the ACL for voice was causing the issue,

Really? I thought the ports used by the WLC are 12222 and 12223 for sending/receiving JOIN packets?

Well, the issue I'm facing is that the AP in the branch office couldn't join the WLC (located in HQ). I found out that the JOIN request is not reaching the WLC AP-manager interface eventhough the Discovery phase is successful. I'm not sure if it has something to do with the branch site using IPSec VPN to connect to HQ. But if the AP is physically moved to the HQ site, it can join the WLC. Weird.

Anyone ever faced this kind of problem? I've already raised a TAC case for this.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: