[cisco-voip] WAN Delays > 80ms for CUCM cluster?

Nick Barnett nicksbarnett at gmail.com
Tue Nov 6 15:24:33 EST 2018


Not a bad idea, but they have so much many more tools to do this. I'll keep
this in mind though. Thanks.

On Tue, Nov 6, 2018 at 11:06 AM Matt Jacobson <m4ttjacobson at gmail.com>
wrote:

> You could use the CLI packet capture with some filters to maximize the
> capture window, run the dbreplication command once or twice, and then stop
> the capture. Pop open RTMT, download the capture(s), and then see what you
> find in Wireshark.
>
> On Tue, Nov 6, 2018 at 20:58 Nick Barnett <nicksbarnett at gmail.com> wrote:
>
>> We all know the max latency is 80ms, but ours occasionally goes over. I'm
>> trying to track down why but the network team cannot find an issue. We are
>> able to reproduce the issue repeatedly by running "utils dbreplication
>> runtimestate." Whether this is causing the issue (I doubt it) or that
>> command just takes long enough to run that it will eventually find a time
>> that is > 80ms (my guess Is yes)... I'm not 100% sure.
>>
>> We opened a case with TAC to find out what that command is actually
>> doing, but they won't divulge the info that our network team needs.
>>
>> My theory is that it's actually calling some shell script in redhat under
>> the CLI appliance layer. Has anyone investigated that? Do we know what this
>> command is actually doing? Specifically, i want to know where it's getting
>> those ping times... is it running a generic ping with generic datagram
>> data? Is it sending a 1497 packet of 0x0000 and then 0xFFFF? Basically, I'm
>> trying to give the network team something to go on because they are saying
>> it's not them. (Of course they could run a packet capture and tell me
>> (mostly) what it's doing, but it's hard to get their attention when they
>> don't think it's on their end).
>>
>> Thanks,
>> Nick
>>
>> P.S.  We have frequent DB replication issues... at least a few times per
>> quarter. This is so annoying and I'm pretty sure it's due to this latency,
>> but I can't get anyone to pay attention.
>> _______________________________________________
>> 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/20181106/480128a1/attachment.html>


More information about the cisco-voip mailing list