Hi Tristan,


Thanks for sending that through, had a look but it doesn't seem like we are 
hitting that bug.



Regards


jason



--

Jason Cook

Technology Services

The University of Adelaide, AUSTRALIA 5005

Ph    : +61 8 8313 4800



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:[email protected]] On Behalf Of Tristan Gulyas
Sent: Wednesday, 14 August 2013 12:40 PM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Slow Response for c5508 controllers



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]<mailto:[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]<mailto:[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]<mailto:[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/.


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

Reply via email to