<div dir="ltr">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 :)<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 12:25 PM Wes Sisk (wsisk) <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nick,<br>
<br>
The command is invoking database commands that Cisco does not own. They are not being obtuse; they genuinely do not know.<br>
<br>
It will cause a spike in database communication between nodes.<br>
<br>
My first guess is very much in line with yours that the burst in traffic exceeds certain QoS queues.<br>
<br>
IMHO - and I emphasize the MY in that - this a rather classic discussion point between application teams and network teams.<br>
<br>
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.<br>
<br>
-Wes<br>
<br>
On Nov 6, 2018, at 11:57 AM, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" target="_blank">nicksbarnett@gmail.com</a>> wrote:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Thanks,<br>
Nick<br>
<br>
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.<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote></div>