Unanswered Question
Sep 4th, 2008

Have an issue where the LWAPP uptime constatly is not atching the AP up time. When I am monitoring the APs. Pings from the AP to the controller are under 10ms.

The AP up time is days and the LWAPP up times is sometimes hours or minutes at that?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Scott Fella Thu, 09/04/2008 - 18:28

I believe the lwapp uptime is the time the ap has been joined to a WLC. It may loose lwapp packets to the AP and vice versa, but since the AP still has an IP Address and has not gone through a reboot process, there is still network connectivity to the AP. DO you have more than one WLC and is the ap moving from one wlc to another? Also, the ap's are in local mode, not in h-reap?

If you run a show ap config general , you will see the following:

AP Up Time....................................... 9 days, 23 h 46 m 41 s

AP LWAPP Up Time................................. 9 days, 23 h 45 m 37 s

Join Date and Time............................... Mon Aug 25 21:40:03 2008

Now if I shut the port down I get this:

AP Up Time....................................... 9 days, 23 h 08 m 03 s

AP LWAPP Up Time................................. 0 days, 00 h 00 m 33 s

Join Date and Time............................... Thu Sep 4 21:28:55 2008

So as long as the ap has network connectivity, it will be pingable but does not mean the ap is connected to the wlc.

reginald-pugh Fri, 09/05/2008 - 07:43


thanks for the swift reponse There are two WLCs, but all the AP (94) are only using one of the controllers. The APs are not moving between the controllers.

They are in the same mobility group.

We had an incident today where all the APs went down. Only 3 of 94 fell over to the secondardy controller. The other 91 failed to come up ? Five minutes later all show up on the primary controller The controller's uptime is 15 days and steady?

Should we just enable HREAP? Our path to all the APs is above 25Mbps. It is fiber based from the controller to the sites with the APs.

Scott Fella Fri, 09/05/2008 - 08:05

Changing to h-reap means configuration changes not only to the wlc, but also on the remote network side. Did got wan go down that it took all your ap's down? Your wlc stayed up, but it looks like connectivity between the ap's and the wlc failed.

reginald-pugh Fri, 09/05/2008 - 08:51

Thanks for the heads up on the HREAP. Will read up on the configuration required for the remote side of the network, most likey DNS and DHCP?

The WAN stayed up according to our WAN team. The APs crashed. I sent a log to the Cisco System Engineer to pass along to TAC if neccessary to decrypt. Yes, all the APs crashed and the WLC stayed up.

Scott Fella Fri, 09/05/2008 - 17:00

That is weird that all the ap's crashed. Did you see that the ports went up/down on the switch at all?

reginald-pugh Fri, 09/05/2008 - 18:23


Yes, but this might attribute to why the APs couldn't fall to the secondary WLC. The primary WLC is a 4404 with up to 100 APs (94 APs are on that controller now), the secondary WLC 4402 supports up to 50 APs.

We sent the AP crash log file to TAC for resolution.

Scott Fella Fri, 09/05/2008 - 18:36

I had an issue where ap's moved over to the secondary controller an never went back to the primary. I blew out the configuration on the primary and reconfigured the wlc. AP's were able to fallback to the primary. I guess the config (xml file) was corrupt.


This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode