DBReplication Shows No Ping

[refram]

When issuing the command "utils dbreplication runtimestate" three of the servers in my cluster show "N/A" in the ping column.  The servers have a "2" listed in the replication column and they can be pinged from the publisher by IP and by hostname.  I've tried restarting the servers but it doesn't make a difference.  Does anyone have some idea of how this can be fixed?  Is it something I probably don't need to worry about?

[Roger Kallberg]

I would not say that it's nothing to worry about. You should absolutely see something in that column.

[Mohammadreza Hadi]

are all your PUB & SUB servers in same Vlan/Subnet ? or in different Vlan/Subnet ?
is there a Firewall between them ? (maybe something is blocking ICMP packet between them..)
did you test ping to each other servers using CLI command ? (utils network ping ...)

also, as dear @Roger Kallberg said, you must have an output like he is shared with us..
specially you must have "Y/Y/Y" for DB/RPC/DbMon section
and you must have "(2) setup completed" for Replication details section..

[Nithin Eluvathingal]

Run the following command to check the database replication status:

utils dbreplication status

Then, execute the following to get detailed runtime state information:

utils dbreplication runtimestate

The ping value represents the round-trip time (RTT) between servers. The maximum acceptable RTT is 80 milliseconds.

Please also provide the output of the following commands:

show network cluster
utils network connectivity <IP Address>

[refram]

Thanks for the replies folks. 

Mohammadreza, the Publisher and Subscribers are all on the same subnet, and there is no firewall between them.  Also, all of the servers that don't ping have a "(2) Setup Completed".

Nithin, the servers are inside the same physical chassis, so there isn't an issue with round-trip-time.  My organization won't allow me to post the output from the two commands you suggested for security reasons, but I had already run them and they looked fine other than the ping issue.  The fact is that I was on the line with a TAC engineer when we saw the output of "utils dbreplication runtimestate" and he didn't seem to indicate that it was any big deal at the time which is why I wondered if it was cosmetic for a 12.5 server. 

I'm going to open a separate TAC case and see if it can be worked out.

[Nithin Eluvathingal · Accepted solution]

If everything appears normal except for the PING showing as 'N/A', I would consider this a cosmetic issue, like the  TAC said, and leave it as is.

However, you should strongly consider upgrading to a latest version, as version 12.5 is reaching EOL in couple of months.

[refram]

We actually are going to be upgrading this summer.

[Elliot Dierksen]

I agree with the others that this sounds like a problem. If it is possible to reboot the node in question, you could use the "utils dbreplication forcedatasyncsub" command.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/12_5_1SU4/cucm_b_command-line-interface-reference-guide-125su4/cucm_b_command-line-interface-reference-guide-1251Su2_chapter_01001.html#CUCM_CL_U3F436F8_00

[refram · Accepted solution]

It turns out the issue was an MTU mismatch.  These servers had to be rebuilt a little while ago, and the person that did so didn't pay attention.  The MTU on the Publisher was at our organization's standard amount, but the servers that were rebuilt were at the default 1500.  I'm going to be changing the MTUs with a "set" command and have been assured that there will only be a short network drop from this change.