Why won't CSCus46997 be fixed?

[ciscokid6969]

A memory leak bug, with the work around being to disable macros entirely? huh? Anyone know why cisco wouldn't fix this bug? This has been affecting us for months now. We have to reboot the stack weekly which is very annoying. Otherwise the console is unusable with the lag and pings are failing all over the place when its in this state.

Anyone know why this is marked as "status terminated" and "no releases planned to fix"??

huh?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCus46997/?referring_site=bugquickviewredir

[Palani Mohan]

CSCus46997 was not seen in 3.6.4 but inconsistently seen in 3.7.2. Attempts to reproduces were unsuccessful. This is why the bug could not be fixed.

CSCuq53377 is a variant of the behavior seen in CSCus46997. Either of these bugs are not applicable to 15.2E release train due to change in the underlying code.  CSCuq53377 was resolved in 15.1(2)SG7 and 15.0(2)SE9.

I hope this clarification helps .... Palani

[ciscokid6969]

Sorry for the ignorance, i find cisco's ios versioning to be less than intuitive, but shouldn't my release that i am running currently not have this bug then? I believe it is 15.2(2r)E1 (see below output from switch) which to me seems greater than 15.2E   (E1 being greater than E)...

I have been told we are on latest release but I have not looked yet. If we still have this bug, but we dont have any maintenance on this particular serial number to open a TAC case are we just SOL till someone else does it?

Attached pictures you can see why i think we have this bug now.

Switch-B#show ver
Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(5b)E, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Wed 14-Sep-16 06:29 by prod_rel_team

ROM: Bootstrap program is C2960X boot loader
BOOTLDR: C2960X Boot Loader (C2960X-HBOOT-M) Version 15.2(2r)E1, RELEASE SOFTWARE (fc1)

Switch-B uptime is 5 weeks, 13 hours, 3 minutes
System returned to ROM by power-on
System restarted at 23:04:09 UTC Sun Jan 15 2017
System image file is "flash:/c2960x-universalk9-mz.152-5b.E/c2960x-universalk9-mz.152-5b.E.bin"
Last reload reason: Reload command

[Palani Mohan]

Ok, we see you are running 15.2(5b)E which is part of 15.2E release tree. Based on what I had personally experienced, we have not seen the problem in 15.2#, until now.

I see the CPU use images. These are good. Are you experiencing any service impact? Being a IOS device, even if the CPU is at near 100% for extended periods of time, it should not impact any of the core services. Please don't mistake me - I am not saying it is alright. All I am saying that there may not be any immediate concerns.

Do you have any tools that track memory usage? If yes, what does the memory usage look like for the past five weeks?

At some point, to have this investigated with right level of engagement, kindly consider working with TAC.

Sincerely ... Palani

[Palani Mohan]

One more clarification. The high-CPU you observed may very well be the victim and so, I asked if you have any info about memory usage.

Sincerely ... Palani

[ciscokid6969]

Ok a colleague has put these images together and we do have some stats on memory usage now. The problem is now existing on another stack in the building as well, this one with only 3 switches :(

however these memory utilizations are all from the same switch stack as previous. You can find them attached. Hope it helps somehow!

[ciscokid6969]

We have zenoss version 3, but i cannot see how to track memory usage with it (i think you need zenoss 5). Other than that, I have no idea how i would do that. is there an IOS command?

The problems we face, and what caused us to look into the issue in the firstplace, was as i said in my initial message 1) extreme CLI lag when SSHing in. aprox 30-40 seconds between keypresses being registered. 2) zenoss reports that entire segments of the network that are connected to this switch stack go offline at the same time (ping failure) and then come back online when the switch calms down a bit. 3) lag in applying macros and reapplying them with this sort of CPU storm is going on.

we are a nonprofit charity so cannot afford the cisco fees for every piece of equipment we have, so i guess we just have to stick to rebooting it till someone more rich has the same issue :(