d RTT to only when the
>> dbreplication stat command is ran, or are there other times the RTT is OOB
>> that isn't related to querying the replication status?
>>
>> Thanks,
>>
>> -R
>> --
>> *From:* cisco-voip on behalf of
hanks,
-R
From: cisco-voip
mailto:cisco-voip-boun...@puck.nether.net>>
on behalf of Nick Barnett
mailto:nicksbarn...@gmail.com>>
Sent: Tuesday, November 6, 2018 11:57 AM
To: Cisco VoIP Group
Subject: [cisco-voip] WAN Delays > 80ms for CUCM cluster?
x27;t related
to querying the replication status?
Thanks,
-R
From: cisco-voip
mailto:cisco-voip-boun...@puck.nether.net>>
on behalf of Nick Barnett
mailto:nicksbarn...@gmail.com>>
Sent: Tuesday, November 6, 2018 11:57 AM
To: Cisco VoIP Group
Subject: [c
* Tuesday, November 6, 2018 11:57 AM
> *To:* Cisco VoIP Group
> *Subject:* [cisco-voip] WAN Delays > 80ms for CUCM cluster?
>
> 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
>
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) wrote:
> Nick,
>
> The command is i
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
wrote:
> You could use the CLI packet capture with some filters to maximize the
> capture window, run the dbreplication command once or twice, an
Sent: Tuesday, November 6, 2018 11:57 AM
To: Cisco VoIP Group
Subject: [cisco-voip] WAN Delays > 80ms for CUCM cluster?
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 iss
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.
I
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 wrote:
> We al
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 j
10 matches
Mail list logo
