Yes, I like easy.  I wanted to reboot the node earlier, but was told that 
should not be necessary.  Should have trusted my gut.  Now onto the other 
issues left over from this migration.

Jabber line presence is extremely delayed.  Have an IM&P cluster reboot 
scheduled for tonight.

From: Anthony Holloway <[email protected]>
Sent: Wednesday, January 13, 2021 12:24 AM
To: Riley, Sean <[email protected]>
Cc: Kent Roberts <[email protected]>; [email protected]
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Nice! That was easy.  This email chain goes into my folder called: When Someone 
Says Only Windows Servers Need Reboots.

On Tue, Jan 12, 2021 at 7:40 PM Riley, Sean 
<[email protected]<mailto:[email protected]>> wrote:
So far it seems the reboot resolved this problem.  Thanks for all the replies 
with guidance and help.

From: Kent Roberts <[email protected]<mailto:[email protected]>>
Sent: Tuesday, January 12, 2021 4:42 PM
To: Riley, Sean 
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [cisco-voip] CUCM call set up issue after migration

Ah split brains. Gotta love it.   Did you restart the ones that did not move?   
 I have seen this when things go stupid. The sync usually isn’t the problem 
it’s the real-time communication between the nodes that’s all messed up.     
Usually can fix with a node reboot or restarting the cucm and cti services.   
Course their maybe more to it but if things are in sync  should not be hard to 
fix

Kent

On Jan 12, 2021, at 14:06, Riley, Sean 
<[email protected]<mailto:[email protected]>> wrote:

This past weekend we migrated 2 CUCM servers to a new datacenter.  This 
involved changing the IP address on these 2 CUCM nodes.  These 2 nodes consist 
of the Publisher and 1 Subscriber.  We have another Sub at a remote datacenter 
that was not touched this past weekend.

Node configuration:

DC A
CM1: Pub which was re-ip’d
CM2: Sub which was re-ip’d

DC B:
CM3: Sub at remote site that was not changed

Phones are at many sites, but issue is independent of the phone type, phone 
location or subnet.  Also, Expressway phones have the same issue.

The issue is any phone that is registered to CM3 cannot call phones registered 
to CM1 or CM2 and vice versa.  The phones do not see the call coming in.  If 
SNR is configured, the call will ring to the remote destination. Phones 
registered to CM3 can make outbound PSTN calls without issue, but not receive 
inbound from PSTN (probably because the gateway is handing off to CM1 or CM2).  
While the gateways are not unique to the issue, they are running H323.

If the phones are both registered to CM3, they can call each other, but not 
phones registered to CM1 or CM2.

I have had my network team verify there is not anything they can see in the 
network causing this behavior. Database replication checks out OK and I can 
ping from/to each node.

Anyone able to point me in the right direction to figure this out?

Thanks.
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to