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

[Nick Barnett]

Yes, I agree, this is a super common "discussion" between app and network
teams... I'm a converted network engineer (like I bet many people are these
days)... so know all the tricks to push it back on the app :)

On Tue, Nov 6, 2018 at 12:25 PM Wes Sisk (wsisk) <wsisk at cisco.com> wrote:

> Nick,
>
> The command is invoking database commands that Cisco does not own. They
> are not being obtuse; they genuinely do not know.
>
> It will cause a spike in database communication between nodes.
>
> My first guess is very much in line with yours that the burst in traffic
> exceeds certain QoS queues.
>
> IMHO - and I emphasize the MY in that - this a rather classic discussion
> point between application teams and network teams.
>
> What Matt suggests in a subsequent response is the the rather data
> intensive way of getting that information. Fortunately wireshark has graphs
> for round trip time.
>
> -Wes
>
> On Nov 6, 2018, at 11:57 AM, 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/70e5d04a/attachment.html>