Hi Jason,

I have seen this once on some of our WiSM2 controllers running a release based 
off 7.2.111.3.  Incidentally, it cropped up while performing a configuration 
refresh from controller in the NCS.  CPU usage was low, even when the command 
line was close to unresponsive but I believe HTTPS was still fine.

Cisco advised we were hitting bug CSCtx03556 which I believe is still present 
in 7.3.101.0.

We are now running a version of code that resolves the issue and we haven't 
seen it since.
---
Tristan Gulyas                  [email protected]
Wireless Network Engineer       M:  +61 403224484
eSolutions division            P:  +61 3 9902 9092
Building 205  Monash University   3800   Australia


On 14/08/2013, at 1:04 PM, Jason Cook <[email protected]> wrote:

> Hi All,
> 
> Just wondering if anyone has seen something similar, we have a call with TAC 
> and are just escalating to the next level as first level support haven’t 
> identified a problem.
>  
> We are still on  7.3.101, we were going to 7.4 but by time the opportunity 
> came we chose to wait for 7.5. Now we probably won’t go 7.5 either due to 
> Prime compatibilities.
>  
> Essentially it started with Prime getting stuck on data collection tasks from 
> the controllers. In investigating this with TAC we found that some of the 
> controllers were very slow to respond. This only happens during peak times 
> 11am-3pm when the network is busiest.  Doing a ping test showed some quite 
> high results like averages of 150ms +. Further investigation shows this is 
> related to the AP count, and a controller with an AP count of 200 has 1ms, 
> while 350 has 150ms. Outside of peak times the ping time is higher, but more 
> like 30ms. Moving AP’s across controllers shows the issue to follow the 
> controllers with higher AP counts. We use LAG with 4x gig ports, no single 
> port goes over 25% utilisation.
>  
> So it seems related to load, but CPU and memory are barely in use and 350 
> AP’s is well below the 500 supported and about 2500 clients which is also 
> below the 7000 supported.
>  
> It seems most likely to be a config issue, or perhaps a bug. From what we can 
> tell there’s no impact on users, we’ve had no complaints and all testing 
> shows  normal performance and authentication times. Really the only impact we 
> have is the slow data collection. General UI usage seems unaffected.
>  
> Regards
>  
> Jason
>  
> --
> Jason Cook
> Technology Services
> The University of Adelaide, AUSTRALIA 5005
> Ph    : +61 8 8313 4800
> e-mail: [email protected]
>  
> CRICOS Provider Number 00123M
> -----------------------------------------------------------
> This email message is intended only for the addressee(s) and contains 
> information which may be confidential and/or copyright.  If you are not the 
> intended recipient please do not read, save, forward, disclose, or copy the 
> contents of this email. If this email has been sent to you in error, please 
> notify the sender by reply email and delete this email and any copies or 
> links to this email completely and immediately from your system.  No 
> representation is made that this email is free of viruses.  Virus scanning is 
> recommended and is the responsibility of the recipient.
>  
> ********** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> athttp://www.educause.edu/groups/.
> 


**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to