|
If anyone has the old arrowpoint load balancer (Cisco css) run "show groups", it has a similar easter egg
|
#
?
Jul 28, 2017 00:01
|
|
|
|
| # ? Apr 19, 2024 04:57 |
|
|
Sepist posted:If anyone has the old arrowpoint load balancer (Cisco css) run "show groups", it has a similar easter egg There was also llama mode for debugging.
|
|
#
?
Jul 28, 2017 01:17
|
|
|
It's always nice to think that behind those monolithic codebases real human beings sat down and wrote em.
|
|
#
?
Jul 29, 2017 01:09
|
|
|
Yeah when using Cisco ACS for authentication if you enter your username and no password it says "You can't change your password over telnet. YOU WILL REGRET THIS!" And I immediately think of 
|
|
#
?
Jul 30, 2017 00:36
|
|
|
abigserve posted:It's always nice to think that behind those monolithic codebases real human beings sat down and wrote em. Just remember the most hardcore of hardcore nerds were the ones to make all this stuff in the first place. I love it.
|
|
#
?
Jul 30, 2017 15:04
|
|
|
Sepist posted:If anyone has the old arrowpoint load balancer (Cisco css) run "show groups", it has a similar easter egg I once ran 'admin' command on one which autocompletes to 'admin-shutdown' and helpfully shuts down all interfaces with no prompting.
|
|
#
?
Jul 30, 2017 15:46
|
|
|
OmniCorp posted:I once ran 'admin' command on one which autocompletes to 'admin-shutdown' and helpfully shuts down all interfaces with no prompting. Reverse with the "no" form of the command 
|
|
#
?
Jul 31, 2017 01:33
|
|
|
He ran the "no no no no" verbal command afterwards
|
|
#
?
Jul 31, 2017 01:39
|
|
|
Would cisco ever change their md5 hashing algorithm in between code releases? I had a customer replace a greyware Nexus 3k with a brand new one (their original distributor tried to pull a fast one on them) and all of their md5 hashed passwords had to be re-imported in plain text. Never seen that before.
|
|
#
?
Aug 1, 2017 20:19
|
|
|
Sepist posted:Would cisco ever change their md5 hashing algorithm in between code releases? I had a customer replace a greyware Nexus 3k with a brand new one (their original distributor tried to pull a fast one on them) and all of their md5 hashed passwords had to be re-imported in plain text. Never seen that before. Was it the old MD5 algo (Secret 5) or was it different (secret 4 deprecated) or Secret 8? IIRC Cisco removed Secret 5 and Secret 7 legacy support in newer Nexus Code releases, and Secret 4 was a flawed version of Secret 8 which is gone as well. ate shit on live tv fucked around with this message at 20:28 on Aug 1, 2017 |
|
#
?
Aug 1, 2017 20:23
|
|
|
5. I originally thought it might be the copy and paste job but it happened on every single replaced switch and each of them had their own unique radius keys.
|
|
#
?
Aug 1, 2017 20:28
|
|
|
That was a great interim when they moved to SHA1 ( I think?) and immediately hosed up the salt and had to rip it out. At least that didn't cause the equipment to crash!
|
|
#
?
Aug 1, 2017 23:21
|
|
|
Partycat posted:That was a great interim when they moved to SHA1 ( I think?) and immediately hosed up the salt and had to rip it out. I loved that bug notice. Someone said "let's implement PBKDF2-SHA1" and whoever got the feature assignment just... didn't hear the "PBKDF2" part.
|
|
#
?
Aug 1, 2017 23:25
|
|
|
To spine leaf or not to spine leaf Running a couple of small colo deployments (6-8 racks each). Tons of east-west traffic, lots of sw defined scale out nas and block. Total is about 100 physical devices between vmware hosts and storage nodes. I have a moderate ESXi environment of about 30 hosts per site. The new scale-out nas platform requires 40gig-e today and will likely support 25/50/100E very shortly. We are currently all Cisco networking and looking at making some changes to either extend Nexus 9332PQs and reuse in a spine leaf or abandon them and just go with 9504 or even 9508 in our larger centers and just have two single chassis switches and not have to mess with the S/L madness. Everything today is run in NX-OS mode and no ACI/NSX in play, just ACLs. Thoughts?
|
|
#
?
Aug 5, 2017 02:08
|
|
|
I suspect you'd get more bang for your buck with a chassis solution, unless you have a pretty solid cabling group and network infrastructure tooling in place.
|
|
#
?
Aug 7, 2017 13:59
|
|
|
Would upgrading CUCM from 10.5.2.13901 to 10.5.2.15900 also include the newer device packs automatically for the newer version? I want to try out the CE software on a unit but don't have the option to add that device yet. I'm thinking I can update CUCM and hopefully the newer device types show up without having to also install a device pack too. Or maybe I have to do both.
|
|
#
?
Aug 16, 2017 14:52
|
|
|
mythicknight posted:Would upgrading CUCM from 10.5.2.13901 to 10.5.2.15900 also include the newer device packs automatically for the newer version? The release notes for the new version should tell you explicitly whether the device type is included or if a device pack needs to be installed. Generally if you're adding a new device type, you're also going to need to reboot. You'll probably have to do both. I'd do the device pack install and reboot first and then the version upgrade, in different maintenance windows if possible.
|
|
#
?
Aug 16, 2017 14:55
|
|
|
Reading through it, you're right, I'll have to do both unfortunately. Thanks for the tip.
|
|
#
?
Aug 16, 2017 15:57
|
|
|
Yeah anytime there would otherwise be a QED file or database change they want a reboot. The notes almost always say to do it regardless, but if it is only firmware you can generally skip it or just load the firmware manually. Supposedly this is better now in 11.5 or 12+ not requiring a reboot, though you still have to be relatively current on patch to get a device pack anyways.
|
|
#
?
Aug 21, 2017 01:23
|
|
|
Cool, CallManager 12 removes support for a specific phone model that we have about 150 of. Says they won't boot at all after upgrading to 12. Excellent.
|
|
#
?
Aug 21, 2017 01:26
|
|
|
It it's the 69xx series of phones then I support that move. gently caress those things.
|
|
#
?
Aug 21, 2017 10:45
|
|
|
Its not: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/12_0_1/deprecated_phones/cucm_b_deprecated-phone-models-for-1201.html It just removes more antiquated poo poo from support. There has been a ton of crying about this from customers who figured on buying a phone for 20 years or something, kind of ignoring them being little computers. Cisco just ended a promo with the 8800 and 7800 series being at a crazy discount. The rumor is there will be another one during this FY. Get upgraded, especially 7940/7960s, or stay in the digital dust I guess.
|
|
#
?
Aug 21, 2017 10:49
|
|
|
For us it's model 7970 being depreciated that sucks. I don't give a poo poo about support, but they're blocking them from even registering. But 7940 and 7960 will still work great. All we use phones for is legit phones, not much else.
|
|
#
?
Aug 21, 2017 13:17
|
|
|
Nobody is forcing you to update to 12, and they models they're removing are really old and should be replaced anyway.
|
|
#
?
Aug 21, 2017 14:21
|
|
|
We typically try to stay current, and yes they're old but they work. It's not like a brand new 8841 is going to give our end users in our manufacturing facility some great new tools. They answer calls, they page overhead. That's it. poo poo, we have ATA's with analog phones in various places because that's all they need.
|
|
#
?
Aug 21, 2017 14:27
|
|
|
I cannot wait to replace our 8.5 environment....
|
|
#
?
Aug 21, 2017 14:33
|
|
|
Moey posted:I cannot wait to replace our 8.5 environment.... 
|
|
#
?
Aug 21, 2017 14:34
|
|
|
GreenNight posted:We typically try to stay current, and yes they're old but they work. It's not like a brand new 8841 is going to give our end users in our manufacturing facility some great new tools. They answer calls, they page overhead. That's it. You should probably wait until the first SU for 12, or until 12.5 anyway. The initial releases are usually bug filled.
|
|
#
?
Aug 21, 2017 14:38
|
|
|
Bigass Moth posted:You should probably wait until the first SU for 12, or until 12.5 anyway. The initial releases are usually bug filled. Yeah, that's what we typically do. We just upgraded to 11.5 earlier this year and migrated off the Cisco supplied ESX boxes to our main HP ESX boxes. If we go to 12, it won't be until late 2018 or early 2019 and that's if we can budget phone replacements. We just implemented Finesse and Jabber too.
|
|
#
?
Aug 21, 2017 14:39
|
|
|
My project this month is 8.6 to 11.5. I'm waiting for the mid-upgrade disaster to hit.
|
|
#
?
Aug 21, 2017 15:10
|
|
|
That's a multi-step upgrade if you're going physical to virtual. Don't try to do it all at once.
|
|
#
?
Aug 21, 2017 15:12
|
|
|
We have virtual 8.6, using the same environment to 11.5. esxi is bumping from 5.0 to 6.0, and the 2821 is being replaced with a 4300. I've contracted the whole thing out because there's way too much that can go wrong along the way to dive in myself.
|
|
#
?
Aug 21, 2017 15:23
|
|
|
The best part is wondering how many phones are going to poo poo themselves after each firmware update.
|
|
#
?
Aug 21, 2017 15:28
|
|
|
Judge Schnoopy posted:We have virtual 8.6, using the same environment to 11.5. esxi is bumping from 5.0 to 6.0, and the 2821 is being replaced with a 4300. For the love of god, if you have to upgrade the certificates do it before you migrate because the ITL syncing issues are such a nightmare.
|
|
#
?
Aug 21, 2017 15:48
|
|
|
Yeah read other peoples errors with security by default before you step in that one. I don't know if 8.6 to 11.5 is supported in prime collab deployment, but that could be an option. As long as your hardware capacity is there, its not too bad, but there's a bunch of new poo poo to catch up on. Partycat fucked around with this message at 23:45 on Aug 21, 2017 |
|
#
?
Aug 21, 2017 23:38
|
|
|
There's hardware capacity for the VAR to spin up the 11.6 environment in parallel with 8.6 so we're doing a slow burn cutover, should reduce all the bullshit stress of debating whether to bail when something inevitably fucks up.
|
|
#
?
Aug 22, 2017 00:19
|
|
|
The "upgrades" we've done recently have been migrations where we spin up the new versions, then do an export of the phones/config on the old version, and import into the new, and spend some time doing some eyeball comparisons just to make sure everything looks right. Actually did an 8.6 to 11.5 a month ago using this method. Granted, it was a fairly straightforward configuration, but went smoothly. We don't really do in-place upgrades anymore unless there's a compelling reason.
|
|
#
?
Aug 22, 2017 00:24
|
|
|
I haven't had to back out of anything thus far from 4 on MCSs up through 11.5 now in VMware, for the UCMs and Connection when we moved to that. CCX has been a bit fidgety with some bugs. CER is a hunk of poo poo, at least it is dead simple to rebuild when it breaks or unsupports itself with database size if you do a lot of changes in it. Granted there are still down times and juggling issues to be had, but they are much improved. We're going all signed and mixed mode/secured so I'm not sure that exports are going to be viable for us. More to break too!
|
|
#
?
Aug 22, 2017 03:30
|
|
|
Generally the easiest way is (assuming you have new hardware) build the same version on the new gear with the same IPs, but in a different VLAN. DRS backup to it and then upgrade the version from there. You can make a time period where no changes can be made, or at least keep track of what changed, while you upgrade the new servers to whatever version. Then in a maintenance window swap the VLANs and cables, test, and clench your butt cheeks together all weekend dreading a call that some obscure setting isn't working anymore. The problem is there are so many bugs and things you need to be on the lookout for like critical cop files and phone firmware versions that must be updated to meet the minimum for the new CUCM version. And the loving CTL/ITL security by default, whoever decided that was a good idea should be publicly shamed. There should be an Administrator option to disable that poo poo. Partycat posted:
What a nightmare.
|
|
#
?
Aug 22, 2017 13:51
|
|
|
|
| # ? Apr 19, 2024 04:57 |
|
|
Does anybody have any sweet Grafana dashboards they like for keep tracking of network utilization, or other metrics? I spent a good chunk of time yesterday yesterday getting Telegraf to poll some basic information like bytes_recv'd per interface to dump into InfluxDB, but my graphs suck! There were so many ways of doing what I want, sFlow, SNMP, Telegraf, fancy EOS APIs and I really didn't know which to choose. Right now I'm going blind reading SNMP documentation to try that. What does everybody else use?
|
|
#
?
Aug 23, 2017 19:48
|
|
