Re: [cisco-voip] Unusual UCOS installation condition - sanity check please

[秀王]

Have you tried changing the mac address of your VM? Sometimes it just
happen to generate the same Mac Address as other VM in the network.

Regards,
Ki Wi

On Sun, Mar 20, 2016 at 11:55 PM, Ryan Huff  wrote:

> Encountering the *duplicate ip on eth0* installation error for UCOS. The
> IP is not actually duplicated on the segment though.
>
>
> My experience with this error is that it is usually right; in the sense
> that * something* is not compatible with UCOS in the network. What I'm
> not certain of, is what method the installer uses to determine the
> duplicate condition. I believe the installer is using an ARP ping to
> determine if there is a dup condition. The error comes on a subscriber,
> right after the validation to first node check.
>
>
> I believe the network may be using Proxy ARP (not completely sure); which
> to my knowledge, won't work with UCOS. I don't have visibility/access into
> the network but I do need to be able to articulate *why* the
> installer detects a dup IP (when there really isn't a dup IP). I have
> quadruple verified I am using the right first node / security password.
> This is happening for multiple subscriber nodes too (same segment), so I'm
> confident it is network related, not fat-finger related.
>
>
> Here is the Scenario:
>
>- CUCM 10.5.2 cluster over WAN (not sure what the WAN link is)
>- 2 sites; SITE_A and SITE_B (not sure what infrastructure gear is at
>each site)
>   - SITE_A: pub
>   - SITE_B: sub
>
> In SITE_A, the pub install without issue. In SITE_B, right after the
> sub installer does the validation to first node check, it pops the *duplicate
> ip* error. I have a linux server installed on the SITE_A and SITE_B
> segment.
>
>
> From the SITE_A linux server, I do an ARPing to the SITE_B IP addresses
> and I get the MAC address for the SITE_A WAN router (Cisco OID). From the
> SITE_B linux server, I do an ARPing to the SITE_A IP addresses and I get
> the MAC address for the SITE_B WAN router (Cisco OID).
>
>
> Anyone have any thoughts into this?
>
> Thanks,
>
> Ryan
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Unusual UCOS installation condition - sanity check please

[Ryan Huff]

Encountering the duplicate ip on eth0 installation error for UCOS. The IP is 
not actually duplicated on the segment though.


My experience with this error is that it is usually right; in the sense that 
something is not compatible with UCOS in the network. What I'm not certain of, 
is what method the installer uses to determine the duplicate condition. I 
believe the installer is using an ARP ping to determine if there is a dup 
condition. The error comes on a subscriber, right after the validation to first 
node check.


I believe the network may be using Proxy ARP (not completely sure); which to my 
knowledge, won't work with UCOS. I don't have visibility/access into the 
network but I do need to be able to articulate why the installer detects a dup 
IP (when there really isn't a dup IP). I have quadruple verified I am using the 
right first node / security password. This is happening for multiple subscriber 
nodes too (same segment), so I'm confident it is network related, not 
fat-finger related.


Here is the Scenario:

  *   CUCM 10.5.2 cluster over WAN (not sure what the WAN link is)
  *   2 sites; SITE_A and SITE_B (not sure what infrastructure gear is at each 
site)
 *   SITE_A: pub
 *   SITE_B: sub

In SITE_A, the pub install without issue. In SITE_B, right after the sub 
installer does the validation to first node check, it pops the duplicate ip 
error. I have a linux server installed on the SITE_A and SITE_B segment.


>From the SITE_A linux server, I do an ARPing to the SITE_B IP addresses and I 
>get the MAC address for the SITE_A WAN router (Cisco OID). From the SITE_B 
>linux server, I do an ARPing to the SITE_A IP addresses and I get the MAC 
>address for the SITE_B WAN router (Cisco OID).


Anyone have any thoughts into this?

Thanks,

Ryan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] IM - services reported in unknown state after SAN cert install

[Kevin Przybylowski]

My typical process with Godaddy is to open the cert - manually copy the root 
and intermediate certs to a file.  Then upload the root, followed by inter 
certs as tomcat-trust, then upload the tomcat cert itself.  It's been pretty 
successful with that process...  The certs on UC can be fun.



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Thursday, March 17, 2016 3:19 PM
To: Erick Wellnitz 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] IM - services reported in unknown state after SAN 
cert install

As much as I hate to plug for MS Windows; you can typically use the Windows 
certificate viewer to extract each CA in a bundle (speaking from Godaddy 
experience myself). However the penguin (Linux) can do it faster IMO, but not 
always as intuitive.

Sent from my iPad

On Mar 17, 2016, at 3:15 PM, Erick Wellnitz 
> wrote:
It was Go Daddy.

I uploaded the bundle they sent all at once to the tomcat-trust then the 
individual multi-server cert to tomcat.  The root was missing from that bundle. 
 Going out to their website and downloading the root, G2 root in this case, and 
uploading it to tomcat-trust was all I needed to do.

Maybe the customer didn't provide me with the file containing the entire chain 
but I remember vaguely this happening on previous jobs with Go Daddy.


On Thu, Mar 17, 2016 at 8:35 AM, Anthony Holloway 
> wrote:
Thanks for replying.  Did you use a public CA or private CA?  And did you 
upload all certs in the chain (sans the root) as one file, or as separate files?

On Wed, Mar 16, 2016 at 8:06 PM, Erick Wellnitz 
> wrote:

The root CA cert wasn't uploaded.  The bundle the CA provided didn't contain 
the root for whatever reason.  Once the root was in place and after a tomcat 
restart everything started working properly.

So, the whole thing was caused by not paying close enough attention to what got 
added to romcat-trust after the cert bundle upload.
On Mar 16, 2016 4:35 PM, "Anthony Holloway" 
> 
wrote:
What do you mean?  Was it simply not uploaded to the Tomcat Trust?  Or was the 
cert bad?

On Mon, Mar 14, 2016 at 3:31 PM, Erick Wellnitz 
> wrote:
It was the root ca cert causing this.

Thanks everyone for the input

On Mon, Mar 14, 2016 at 1:44 PM, Ryan Huff 
> wrote:
Correct; tomcat-trust is the trust store where the trusted CA chain goes and 
then the server certificate goes in the tomcat category.

Afterwards; you should only need a restart of tomcat services. However, if the 
nodes are having issues trusting one another within the cluster (assuming that 
your issue is a cert trust issue); left that way long enough will likely start 
to cause replication issues within the cluster.

After you resolve the issue, I would verify db replication is healthy.

Sent from my iPhone

On Mar 14, 2016, at 3:38 PM, Erick Wellnitz 
> wrote:
I did that as well but I'm not 100% sure if the entire Root CA chain got 
installed.  I'll check that.

What made me try inserting the multi-server SAN into the tomcat-trust is that 
the IM entries for tomcat-trust have vanished.  Maybe I'm mis-remembering 
seeing them there in the first place.

On Mon, Mar 14, 2016 at 12:54 PM, Anthony Holloway 
> wrote:
Just to clarify, your Multi-Server SAN cert should be installed to Tomcat and 
not Tomcat Trust.  The signing CA cert should go in Tomcat Trust.  Is that what 
you meant to say you did?

On Mon, Mar 14, 2016 at 1:47 PM, Erick Wellnitz 
> wrote:
I have a strange issue with CUCM 11.0.1 and IM 11.0.1

We installed the multi-server SAN cert for tomcat and now the IM data monitor 
service is in an unknown state according to the system troubleshooter.

The SAN cert is installed to tomcat-trust so it shouldn't be a cert issue.  
Done service restarts, reboots and nothing seems to resolve this.

Anyone seen something like this before?

Thanks in advance!

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip




___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] CUBE code upgrade

[Barnett, Nick]

I'm currently running 15.3(3)M6 on our CUBE HA pairs. I'm looking at upgrading 
to 15.4(3)M6, as it looks like the best fit for us. No critical security 
advisories, it's acceptable in CVP/UCCE... but more importantly, it gives us 
some nice options for routing on URI and other incoming numbers.

Our current code has CUBE level 9.5.1   I see that the new code has CUBE 10 
inside.  Does anyone have any experience with jumping CUBE levels? Any pointers 
on this undertaking?

Thanks,
Nick
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip