I realized that the fixed version is the latest (16.6.3 was the latest when I had this issue) so I just upgraded a 9400 and turned lacp back on. I can now verify it works great. Thanks again.
... View more

Ah, I missed that one. By making the state active manually, I'm not sure it wouldn't go into suspend again in case of a power outage or reboot. I'll just try the next upgrade using the fixed 16.6.4 to be safe.
... View more

I've upgraded two 4500 chassis with 9400 so far. Replaced with 9407 with L3 PC uplink config on other end 6880 untouched, but when I do 'channel-group x mode active' on the 9400 both sides claim lacp isn't configured on the other side. Switch originally had 16.6.2, upgrading to 16.6.6 didn't help the issue. Finally went to 'channel-group x mode on' to get the port-channel to come up. Cisco says it should work and are going to lab it up and to try to find why it doesn't. Anyone seen this?
... View more

I found it. There was an InitialPhoneSelection keyword set to 'deskphone' in the policies section of the jabber-config.xml. I changed it to 'softphone', but perhaps I could have removed it.
... View more

I'm using UCM 10.5(2)SU2a (10.5.2.12901-1) & Jabber 11.1.1 on Windows and Mac, but I'm sure same thing happened with earlier versions of UCM and Jabber. Neither platform's Jabber client respects the CSF phone parameter in UCM 'Automatically Start in Phone Control'. It says the parameter:
"Sets the phone type for users when the client starts for the first time. Users can change their phone type after the initial start. ..."
But new installs or even just resetting Jabber resets it to 'Use my desk phone for calls'. It seems the client ignores that UCM CSF phone setting. Anyone else notice that?
... View more

Oops. I was going to restart Tomcat on the pub and see if it helped. That did it. Weird, I've never had it run slow like that. Must not have started right after the upgrade. Thanks for the response.
... View more

I recently upgraded from a 10.5.2 release to 10.5(2)SU2a, and it all works fine. But the GUI is sluggish compared to earlier versions. Adding and updating phones takes perhaps twice as long to add or save. If an add or change took 2-3 seconds I'm going to say it now takes 5-7. Very noticably slower. Has anyone else seen this behavior?
... View more

Jabber for Mac v9.6 fixed the SSL issues from v9.2.1 & 9.2.2. So now I've removed the keywords BDIConnectionUsername & BDIConnectionPassword, and let it use a given user's jabber credentials for their directory lookups. <BDIServerPort1>636</BDIServerPort1> <BDIEnableTLS>True</BDIEnableTLS> <BDIUseJabberCredentials>True</BDIUseJabberCredentials> Not sure if I had to, but I also added this part to the top at some point in time. At the state of Jabber development at the time at least I think, it eliminated the user having to enter any hostnames during Jabber setup. <CUCM> <PhoneService_UseCredentialsFrom>presence</PhoneService_UseCredentialsFrom> </CUCM> <Presence> <PresenceServerType>CUP</PresenceServerType> </Presence> <Voicemail> <VoiceMailService_UseCredentialsFrom>phone</VoiceMailService_UseCredentialsFrom> </Voicemail>
... View more

Here's the jabber-config.xml file I used to get directory searches for Mac Jabber 9.2.1 working in AD environment. Note that though I am using TLS, I could not get it working over the standard ldaps (636) port. I assume this is a bug in 9.2.1, but in any case wireshark confirms it is doing ssl. Also, I have the UCM service profile for Jabber is set to ldap not global catalog mode if that even matters when using a config file. <?xml version="1.0" encoding="UTF-8"?> <config version="1.0"> <Directory> <DirectoryServerType>BDI</DirectoryServerType> <BDILDAPServerType>AD</BDILDAPServerType> <BDIPrimaryServerName>1.1.1.1</BDIPrimaryServerName> <BDIPresenceDomain>mycompany.com</BDIPresenceDomain> <BDIServerPort1>389</BDIServerPort1> <BDISearchBase1>ou=My Users,dc=ad,dc=mycompany,dc=com</BDISearchBase1> <BDIConnectionUsername> ucm_query@ad.mycompany.com </BDIConnectionUsername> <BDIConnectionPassword>my_password</BDIConnectionPassword> <BDIEnableTLS>1</BDIEnableTLS> <BDIBaseFilter>(&(objectCategory=person)</BDIBaseFilter> </Directory> </config> NOTE (from v9.2.1 doc): The default value is (&(objectCategory=person). Configuration files can contain only valid XML character entity references. Use &amp; instead of & if you specify a custom base filter.
... View more

My memory may be incorrect, but I think the SSH rule error was a cosmetic bug and not related to the main problem, which I do remember well. Namely, the mobility connectivity problems. Those problems began after shifting a number of APs onto a lightly loaded controller. The mobility issues baffled everyone, and I finally just moved the APs back off the affected controller and the mobility issues went away. Moved them back again and the mobility problems did not return. It must have been some bizarre fluke.
... View more

I have a 4260 with the latest software and I know it is rated at 1 - 2 Gbps (transactional / media rich) throughput. I have it monitoring a 400 Mbps pipe that is pretty well maxed out at 400 down and 100 up during peak times for a total of 500 Mbps throughput. My CPU Usage shown in the 4260 management GUI gets as high as 80% at peak times. Should it be that high for this unit with that amount of traffic?
... View more

That isn't my understanding. My understanding is that compatibility works within major version numbers. http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp89677
... View more

After upgrading my 5508s to 7.2.110.0, they are reporting mobility data path errors to one of my WiSMs running 7.0.235.0. I get these messages on the 5508s reporting that it can't send a ping to the affected WiSM: *ethoipSocketTask: Aug 08 21:15:41.175: %ETHOIP-3-PKT_RECV_ERROR: ethoip.c:341 ethoipSocketTask: ethoipRecvPkt returned error *ethoipSocketTask: Aug 08 21:15:41.175: %ETHOIP-3-PING_RESPONSE_TX_FAILED: ethoip_ping.c:312 Failed to tx a ping response to <ip address>, rc=5 But maybe there is another clue because I also see in the same log these errors referencing the same WiSM: *bcastReceiveTask: Aug 08 21:15:45.310: %LOG-1-Q_IND: mm_dir.c:1969 Failed to recreate the SSH Rule for <ip address>. *mmSSHPeerRegister: Aug 08 21:15:44.829: %MM-1-SSHRULE_CREATE_FAILED: mm_dir.c:1969 Failed to recreate the SSH Rule for <ip address>. Why is the controller trying to SSH to another controller? Was some SSH related feature added to 7.2 that has been accidentally enabled? Any insight into this issue would be appreciated.
... View more