Cisco Catalyst 3850 Upgrade Issue - Internal Error

While upgrading a pair of non-stacked 3850-48Ps, I encountered this error message:


[1]: % An internal error was encountered. Operation aborted.

I did have some space issues, so I deleted previous versions. Even that did not fix the issue. I tried installing it from tftp, to no avail.

Eventually, I ran the software install command with "new force"

software install file tftp://10.20.30.40/cat3k_caa-universalk9.SPA.03.06.09.E.152-2.E9.bin new force

Success. I rebooted both switches. One crashed on reboot, but rebooted cleanly afterward.

Cisco 3850 WS-C3850-48P-E Switch with Wrong License Level Lanbase

I received a couple of refurbished 3850 PoE Enterprise switches. One switch was perfectly fine, with IP services enabled permanently.

The other:

Slot#  License name   Type     Count   Period left

----------------------------------------------------------

1      lanbase      permanent     N/A   Lifetime

License Level on Reboot: lanbase

I issued a request for an RMA - however, the switch was labeled correctly on the case: WS-C3850-48P-E.

On a whim, I ran this command:

license right-to-use activate ipservices

I rebooted as instructed from the switch, and now I have:

Switch#show license right-to-use
 Slot#  License name   Type     Count   Period left
----------------------------------------------------------
 1      ipservices   permanent     N/A   Lifetime
 1      lanbase      permanent     N/A   Lifetime

License Level on Reboot: ipservices

So, yay - no need for an RMA.

Upgrading pfsense 2.4.3_1 to 2.4.4 - Issue Replacing PHP 5.x with 7.x Due to FRR

I ran into a problem upgrading pfsense 2.4.3_1 to 2.4.4 due to a dependency on the old PHP 5.6.x from the older package of FRR .2_2 (Free Range Router.) The problem was that PHP56 was marked as vital due to the FRR dependency, and it was not possible to update FRR to .2_4, as FRR .2_4 needed pfsense 2.4.4 (I could not decide whether this was a modern O. Henry story or a missing epilogue from Catch 22.)

The fix:

1. connect to the pfsense server with SSH
2. Open a shell
3. Run this command:

pkg set -v 0 php56

Your upgrade should work - I had to do a couple of update attempts before it worked.

SSH No Matching Cipher Found With SSH to Older Cisco Gear

I've seen this error on recent SSH versions, including the OpenSSH used by OS X and others:

Unable to negotiate with 192.168.77.1 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Several people suggest modifying your local ssh client config. However, I'd rather not use 3DES unless I have to. So, I created an alias and put it in .bash_profile:

alias ssho='ssh -c 3des-cbc'

after a quick . ~/.bash_profile

I can ssh with the alias:

ssho 192.168.77.1
password:

Of course, the best fix would be to update IOS on the Cisco gear.

Openstack Ansible Pike - Cannot Create Image in Horizon

There is a bug with OpenStack Pike deployments using Ansible. When you attempt to create an image in Horizon, you will see the following error:

Followed by this entry in the images list after closing this:

You should still be able to create images via command line, but Horizon won't work. 

There is a bug filed for this:

https://bugs.launchpad.net/openstack-ansible/+bug/1730722

Their fix is simple: connect to the horizon container from an infrastructure node:

lxc-attach -n `lxc-ls -1 | grep horizon | tail -1`

edit /etc/horizon/local_settings.py

and change:

HORIZON_IMAGES_UPLOAD_MODE = 'direct'

to

HORIZON_IMAGES_UPLOAD_MODE = 'remote'

After that, restart the horizon container

lxc-stop -n `lxc-ls -1 | grep horizon | tail -1`

lxc-start -n `lxc-ls -1 | grep horizon | tail -1`

And simply wait a few minutes. Image creation should work. 

Powercenter Integration Service Won't Start: Error SF_34004 - Missing Environment Variables

I recently had an issue where I could not get the Informatica PowerCenter Integration Service to start after an install. The service generated this error code: SF_34004. There is an Informatica KB article describing this problem and the appropriate fix:

https://kb.informatica.com/solution/18/Pages/120251.aspx


Basically, it's suggesting that the Integration Service was configured to connect to the PowerCenter repo using the schema credentials and not the domain administrator.

However, I found that this did not help. the repo service was running correctly and the integration service was using the correct credentials. I checked the user running PowerCenter, and realized the INFA_HOME, INFA_DOMAIN_FILE, and other variables were not set correctly. After setting these and restarting PowerCenter, I was able to enable the Integration Service.

Abnormally Long First Boot Times on Cisco 3750x's with 15.2.x code

I recently upgraded some Cisco 3750x (WS-C3750X-48T-S to be precise) from 12.2.x code to 15.2 code (15.2(4)E4.)

The reboot took a rather long time due to microcode updates. It was about 25-30 minutes. The following messages were displayed:



ssssssssspssssssssssssssssssspssssssssssssssssssspssssssssssssssssssspssssssssssssssssssspsssssssssp
Front-end Microcode IMG MGR: Preparing to program device[0]...25166 bytes.
Front-end Microcode IMG MGR: Programming device 0...rrrrrrwssssssssssssssssssspssssssssssssssssssspp
Front-end Microcode IMG MGR: Preparing to program device[0]...86370 bytes.
Front-end Microcode IMG MGR: Programming device 0...rrrrrrwssssssssssssssssssspssssssssssssssssssspw

% Front-end Microcode IMG MGR: HW image is upgraded. MCU reset causes the switch to reload

If you're making such an upgrade, be prepared for a long wait. It will likely be worse on a stack.

While the 3750x is not a speedy switch, management-wise, this was impressively slow. The regular boot time after the upgrade was about 5-6 minutes, so be patient. Switches in a stack will take even longer to boot.