Hello everyone, I noticed recently that when I do a write command on a 4500 that we have that it takes about 2-3 minutes to complete. I believe this is due to the config compression but still seems like a very long time.
Building configuration...
Compressed configuration from 51372 bytes to 13441 bytes[OK]
Tried removing the config compression but it's hardcoded into the 4500's. Any thoughts?
Quote from: Ironman on February 12, 2015, 09:26:03 PM
Tried removing the config compression but it's hardcoded into the 4500's. Any thoughts?
It's a hard-coded config "option" in the 4500s, you can't remove it. There's nothing about your setup.
Huh? I think you just repeated what I said above. . ?
Quote from: Ironman on February 13, 2015, 07:50:50 AM
Huh? I think you just repeated what I said above. . ?
I think he just repeated what you said above.
Lol, nice!
Quote from: Ironman on February 13, 2015, 07:50:50 AM
Huh? I think you just repeated what I said above. . ?
You said you couldn't remove config compression from your config, and I'm saying that's normal. It's not necessarily the cause of your long save times, but you'll probably never be able to prove it since you can't remove it.
What other thoughts do you want? You haven't really provided any other details which could impact the issue, like IOS versions and dual supervisors (config sync).
I have a few hundred 4500s around and they don't take 3 minutes to a save a config.
I said I couldn't remove the compress command because its hard-coded meaning I "knew" I couldn't remove it. . . . then you went and told me that it couldn't be removed because it was hard-coded. . . . . aka "repeated" what I said. . :think:
Quote from: Ironman on February 13, 2015, 10:24:39 AM
I said I couldn't remove the compress command because its hard-coded meaning I "knew" I couldn't remove it. . . . then you went and told me that it couldn't be removed because it was hard-coded. . . . . aka "repeated" what I said. . :think:
Now you repeated both what he said and what you said. Is this how switching loops develop?
I'm not as think as you drunk I am.... :wtf:
Quote from: ristau5741 on February 13, 2015, 10:53:05 AM
I'm not as think as you drunk I am.... :wtf:
Are you saying that you need to post on a weekend thread now?
Good luck resolving your issue, I'm out.
Quote from: javentre on February 13, 2015, 11:22:18 AM
Good luck resolving your issue, I'm out.
Good luck resolving my issues, your out! (Repeating continues)
Quote from: javentre on February 13, 2015, 11:22:18 AM
Good luck resolving your issue, I'm out.
im in. :problem?:
have you tried dumping your config into usbflash0 ? Do you notice the delays still? How about if you failover your sups. Still the same config compression speed?
Quote from: LynK on February 13, 2015, 12:52:28 PM
Quote from: javentre on February 13, 2015, 11:22:18 AM
Good luck resolving your issue, I'm out.
im in. :problem?:
have you tried dumping your config into usbflash0 ? Do you notice the delays still? How about if you failover your sups. Still the same config compression speed?
There we go, thanks for a usable response! :not_worthy:
So, I am now thinking that there may be an issue with the secondary/slave SUP. When I try and do a show slavebootflash or anything on the slave, it take awhile and sometimes comes back with an error. I think I will have to take a trip over to the site and console into the secondary SUP.
%Error show slavebootflash: (Error Sending Request)
This is what TAC exists for
Quote from: wintermute000 on February 13, 2015, 02:55:19 PM
This is what TAC exists for
Geesh, maybe I'm having a bad week. I thought this site was to gather a "community" of networking folks who could bounce ideas and issues off each other. The whole point of posting an issue is to see if someone else in the "community" came across this similar issue. TAC is generally a last resort. I usually like to do some digging of my own and ask my peers if they've seen this before I go running to TAC.
It is a community, but I think we're all feeling a little punchy today. Nothing personal, Ironman... take it as a general "Dang, we haven't seen stuff like that" when you get ribbing like this.
Honestly, what you're experiencing makes sense in the light of the failed hardware. Let us know what happened when you have more information.
Thanks Dean. I guess your right. Happy Valentines Weekend everyone!
Ironman, I was just being brief, as you've discovered its looking more and more like a HW issue.... I just couldn't be arsed typing 'looks strongly like buggy behaviour and I'd log a TAC case regardless of whatever other research I was doing'.
Quote from: Ironman on February 13, 2015, 03:44:18 PM
Quote from: wintermute000 on February 13, 2015, 02:55:19 PM
This is what TAC exists for
I usually like to do some digging of my own and ask my peers if they've seen this before I go running to TAC.
this is a waste of a whole crapload of money, an crap, no matter how lowly, open a TAC case first, your company is paying a lot money for SmartNet, not to use it, or to use it as a last resort is just not smart. open first than you can go to the community. and if we resolve it before TAC does, good for us.
we have Advanced Services at work, it costs a bank, we'll open TAC cases at the drop of a hat. just cause something doesnt' look right, something reloads in the middle of the night. We open proactive cases, when we reload gear to make sure hardware is available at the local depot, in case a device take a crap.
make use of the services, man.
1
So. . . .at the end of the day it wound up being a H/W bug. I popped out the secondary sup and waited a few mins and popped it back in and BAM! It works like a charm now.
Nice. hardware bug or IOS bug? I would look at upgrading either way... just to make sure it doesn't happen again.
Quote from: LynK on February 24, 2015, 02:33:57 PM
Nice. hardware bug or IOS bug? I would look at upgrading either way... just to make sure it doesn't happen again.
Looks like a Hardware bug. TAC said they have seen this before and have been replacing the sups. Its a flash problem on the supervisor itself. If it happens again we will just replace it.