[cisco-voip] 'interesting' EMCC behavior

[Erick Wellnitz]

Another thing I am seeing that I didn't notice before is that on my local
9.1 cluster the 8.5 cluster shows false for all 'remote activated' items.
Is that expected behavior?  My other 9.1 cluster shows the
appropriate values. The configuration on the 8.5 cluster is correct
according to the features and services guide.


On Wed, Oct 9, 2013 at 12:18 PM, Brian Meade (brmeade) <brmeade at cisco.com>wrote:

>  Yea, it’s doing a DNS lookup with the hostname+the domain configured on
> the phone.****
>
> ** **
>
> *From:* Erick Wellnitz [mailto:ewellnitzvoip at gmail.com]
> *Sent:* Wednesday, October 09, 2013 12:50 PM
> *To:* Brian Meade (brmeade)
> *Cc:* Ryan Ratliff (rratliff); cisco-voip
> *Subject:* Re: [cisco-voip] 'interesting' EMCC behavior****
>
> ** **
>
> This leads me to another question.  When I do a nslookup using the DNS
> servers the phone uses the name resolves fine.  ****
>
>  ****
>
> Does setting the phone's domain name make a difference in it's DNS lookup?
> ****
>
> ** **
>
> On Wed, Oct 9, 2013 at 9:49 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:****
>
> 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/20131010/035b1cb5/attachment.html>