[cisco-voip] 'interesting' EMCC behavior

[Erick Wellnitz]

I thought I'd try anyway.  :)

 Device packs still require reboot, correct?


On Wed, Oct 16, 2013 at 1:36 PM, Brian Meade (brmeade) <brmeade at cisco.com>wrote:

>  Erick,****
>
> ** **
>
> Did you also install the device pack?  Until that’s installed on the home
> cluster, that CUCM won’t be able to generate the signed config files for
> that phone model.****
>
> ** **
>
> Brian****
>
> ** **
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Wednesday, October 16, 2013 1:31 PM
> *To:* Brian Meade (brmeade)
> *Cc:* Ryan Ratliff (rratliff); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
> ** **
>
> Getting the same behavior with firmware SCCP8941_8945.9-3-4-17****
>
> ** **
>
> On Wed, Oct 16, 2013 at 11:11 AM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> It was started in 9.3(2)-
> http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/8941_8945/firmware/932/release_notes/P415_BK_RF066255_00_rn-9_3_2-8941-8945_chapter_00.html
> ****
>
>  ****
>
> Definitely going to need that device pack on the home cluster so the
> encrypted config files can be generated.****
>
>  ****
>
> *From:* Ryan Ratliff (rratliff)
> *Sent:* Wednesday, October 16, 2013 12:08 PM
> *To:* Erick Wellnitz
> *Cc:* Brian Meade (brmeade); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior
> *Importance:* High****
>
>  ****
>
> I don't think the 8945 picked up support for SBD until 9.2(3) so if the
> phone is running something later than this and the cluster with the issue
> shows that as the default firmware then that is indeed your issue.****
>
>  ****
>
> -Ryan ****
>
>  ****
>
> On Oct 16, 2013, at 11:10 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
>  ****
>
> It has SCCP894x.9-1-2-SR-1 for the firmware version.****
>
>  ****
>
> I have registered an 8945 to the cluster in the past.  Would we be able to
> install a newer firmware (matching our 9.1 clusters, for example) or would
> we need to do it via device pack?****
>
>  ****
>
> On Wed, Oct 16, 2013 at 9:58 AM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> Erick,****
>
>  ****
>
> Does that home cluster have any 8945s?  The problem may be that you don’t
> have the device pack that enabled security by default on the 8945s
> installed on the home cluster.****
>
>  ****
>
> Brian****
>
>  ****
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Wednesday, October 16, 2013 10:49 AM
> *To:* Brian Meade (brmeade)
> *Cc:* Ryan Ratliff (rratliff); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
> Update:****
>
>  ****
>
> We have it working for 79xx series phones.  Still have the 404 - File not
> found error, now from both TFTP servers, when the 8945 looks for it's
> config.****
>
>  ****
>
> On Thu, Oct 10, 2013 at 9:11 AM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> Erick,****
>
>  ****
>
> For the replication issue, everything is already in a state of 2 so
> running a “utils dbreplication repair all” on the publisher should
> hopefully clear out the Repl Queues.****
>
>  ****
>
> Brian****
>
>  ****
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Wednesday, October 09, 2013 10:49 AM
> *To:* Brian Meade (brmeade)
> *Cc:* Ryan Ratliff (rratliff); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
> Well, I think we have a replication issue.****
>
>  ****
>
> DB and Replication Services: ALL RUNNING****
>
> Cluster Replication State: BROADCAST SYNC Completed on 3 servers at:
> 2012-03-05-
> 18-58
>      Last Sync Result: SYNC COMPLETED  530 tables sync'ed out of 530
>      Sync Errors: NO ERRORS****
>
> DB Version: ccm8_5_1_13900_5
> Number of replicated tables: 530****
>
> Cluster Detailed View from PUB (4 Servers):****
>
>                                 PING            REPLICATION     REPL.
> DBver&
> R
> EPL.    REPLICATION SETUP
> SERVER-NAME     IP ADDRESS      (msec)  RPC?    STATUS          QUEUE
> TABLES
> L
> OOP?    (RTMT) & details
> -----------     ------------    ------  ----    -----------     -----
> --------
> ----    -----------------
> ASI-LNX-UCMP-1  10.129.146.20   0.032   Yes     Connected       0
> match
> Y
> es      (2) PUB Setup Completed
> ASI-LNX-UCMS-1  10.129.146.21   0.248   Yes     Connected       148
> match
> Y
> es      (2) Setup Completed
> ASI-LNX-UCMS-2  10.129.146.22   0.259   Yes     Connected       148
> match
> Y
> es      (2) Setup Completed
> ASI-LNX-UCMS-3  10.130.146.20   1.24    Yes     Connected       148
> match
> Y
> es      (2) Setup Completed****
>
>  ****
>
> All of our other clusters show 0 for Repl. Queue****
>
>  ****
>
> On Tue, Oct 8, 2013 at 4:25 PM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> Eric,****
>
>  ****
>
> Just checked your packet capture and see the 404 you’re talking about from
> the home cluster.  It’s indeed for the SEP<MAC>.cnf.cml.sgn file that’s
> having the problem.****
>
>  ****
>
> Can you use a TFTP client to try downloading other signed files from that
> home cluster?****
>
>  ****
>
> From your mini-config, it looks like the 2 TFTP servers it gets is
> XXX-XXX-UCMP-1 and 10.12x.xx.22.****
>
>  ****
>
> I then see a failed DNS lookup for ASI-LNX-UCMP-1 so it uses the
> 10.12x.xx.22 address.  I wonder if there’s any sort of replication issues
> that may be causing the 404 Not Found.****
>
>  ****
>
> Can you check “utils dbreplication runtimestate” on the publisher of the
> home cluster?****
>
>  ****
>
> Thanks,****
>
> Brian****
>
>  ****
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Tuesday, October 08, 2013 4:27 PM
> *To:* Brian Meade (brmeade)
> *Cc:* Ryan Ratliff (rratliff); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
> No, as soon as I get the 404 not found response in regards to the .sgn
> config file the logout is initiated.****
>
>  ****
>
> On Tue, Oct 8, 2013 at 3:16 PM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> Erick,****
>
>  ****
>
> Does the user ever show up in the Remotely Logged-In Device Report on the
> home cluster?****
>
>  ****
>
> Brian Meade****
>
>  ****
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Tuesday, October 08, 2013 4:03 PM
> *To:* Ryan Ratliff (rratliff)
> *Cc:* Brian Meade (brmeade); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
> I may have found something but I'm not sure.****
>
>  ****
>
> In the packet capture, I see that the request
> for SEPXXXXXXXXXXXX.cnf.xml.sgn is sent to the user's cluster but is not
> found.  At that point the logout is initiated.****
>
>  ****
>
> On Mon, Oct 7, 2013 at 10:51 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
> And this:****
>
>  ****
>
> 7730: WRN 09:00:37.155813 SECD: WARN:getTLInfoFromFile: ** phone has no TL
> file /flash0/sec/ctl//CTLFile.tlv****
>
>  ****
>
> On Mon, Oct 7, 2013 at 10:48 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
> The only 'abnormal' thing I see is this:****
>
>  ****
>
> 7739: WRN 09:00:37.178303 SECD: WARN:getTLInfoFromFile: TL signer's issuer
> name too big, may truncate****
>
>  ****
>
> On Fri, Oct 4, 2013 at 6:26 PM, Ryan Ratliff (rratliff) <
> rratliff at cisco.com> wrote:****
>
> I it's easier get the console logs there will likely be something there to
> go off.
>
> Sent from my iPhone****
>
>
> On Oct 4, 2013, at 5:10 PM, "Erick Wellnitz" <ewellnitzvoip at gmail.com>
> wrote:****
>
>   The profile logs in, phone resets, profile gets logged out, phone
> resets and displays 'extension mobility unavailable.****
>
>  ****
>
> We believe it is somehow related to DNS because when we register a phone
> to one of the 9.1 clusters in the other location login works as expected.
> I haven't had a chance to do a packet capture yet.****
>
>  ****
>
> On Fri, Oct 4, 2013 at 4:00 PM, Ryan Ratliff (rratliff) <
> rratliff at cisco.com> wrote:****
>
> By the way what's the error code that the phone displays?  EM has been
> better than most about having useful errors, even if they are subject to
> the secret decoder ring. ****
>
>  ****
>
> -Ryan ****
>
>  ****
>
> On Oct 4, 2013, at 4:10 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
>  ****
>
> Yes, it is also the primary tftp server.****
>
>  ****
>
> On Fri, Oct 4, 2013 at 12:57 PM, Ryan Ratliff (rratliff) <
> rratliff at cisco.com> wrote:****
>
> System->Server values don't impact certificates.  They will impact what
> the phone gets in config files so if you aren't using DNS this will be an
> issue.  Is that pub also the TFTP server that is going to show up in the
> mini-config? ****
>
>  ****
>
> -Ryan ****
>
>  ****
>
> On Oct 4, 2013, at 1:13 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
>  ****
>
> I always forget about doing a packet capture on the phone.****
>
>  ****
>
> I'm thinking it is cert related because on this one cluster the Publisher
> is set up under servers using it's hostname instead of IP while all the
> others are using IP. ****
>
>  ****
>
> We're going to change this once we get approval then re-export,
> consolidate and import.****
>
>  ****
>
> On Thu, Oct 3, 2013 at 4:49 PM, Brian Meade (brmeade) <brmeade at cisco.com>
> wrote:****
>
> Erick,****
>
>  ****
>
> Can you grab a packet capture from the phone trying to log in?  The packet
> captures seem to show the EMCC issues very clearly.  You should see after
> the login, the phone will download its mini-config with the new TFTP server
> info.  You’ll then see it try to download its ITL from the other cluster.
> If you don’t see the phone request anything after that, most likely it
> didn’t trust the signer of the ITL and it will show the “Extension Mobility
> is unavailable” error message.****
>
>  ****
>
> Usually that means you need to do a Re-Export, Consolidate, Import of the
> certificates.****
>
>  ****
>
> Brian Meade****
>
>  ****
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Erick Wellnitz
> *Sent:* Thursday, October 03, 2013 5:01 PM
> *To:* Jason Aarons (AM)
> *Cc:* cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
> That's the odd thing.  All of the traces look like it is successful but
> the phone (7965) resets, logs the user out and displays a message that
> extension mobility is not available without an error code.  I get similar
> behavior on the 8945 but without the message.****
>
>  ****
>
> I've gon through the EMCC guide a number of times and nothing sticks out
> as obvious.****
>
>  ****
>
> On Thu, Oct 3, 2013 at 3:41 PM, Jason Aarons (AM) <
> jason.aarons at dimensiondata.com> wrote:****
>
> I was using 8.6 the first time I setup EMCC to another 8.6 box.****
>
>  ****
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Anthony Holloway
> *Sent:* Thursday, October 03, 2013 3:39 PM
> *To:* Erick Wellnitz
> *Cc:* cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
>  ****
>
>  ****
>
> I have one idea.****
>
> EMCC does not work very well in 8.5 because you cannot "home" a user to a
> cluster.  Therefore, if your LDAP integrations are the same for each
> cluster, it would be impossible to know which cluster the user is homed
> to.  9.1 on the other hand has this feature on the end user page, and thus
> overcomes this limitation.****
>
>  ****
>
> On Thu, Oct 3, 2013 at 1:50 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
>  I have a strange situation.****
>
>  ****
>
> 3 Clusters. 2 on 9.1 and the other on 8.5  EMCC works except with users
> configured on the 8.5 cluster.  The profile logs in then immediately logs
> out without an error message.****
>
>  ****
>
> Any ideas would be greatly appreciated!****
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
>   ****
>
>
>
> itevomcid ****
>
>  ****
>
>  ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>   ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131016/151f1964/attachment.html>