ok, thanks guys for clearing that up. Looking at a packet capture from an idle phone all I see is the SCCP KA and the SCCP KA ACK every 30 seconds by default so there is some dependency on the SCCP KA traffic generating the required TCP traffic for Geometric TCP to work.<br>
<br>So theoritically, with your example of 2 ms RTT, if the CM server were to lose power at the beginning of the 30 second KA cycle then the IP phone would failover after approximately 30.030 seconds with Geometric TCP enabled instead of 61.8 seconds with Geometric TCP disabled.<br>
<br>Sorry Scott, didn't mean to take your thread a different direction I just found the Geometric TCP interesting.<br><br>Justin<br><br><div class="gmail_quote">On Mon, May 11, 2009 at 2:50 PM, Wes Sisk <span dir="ltr"><<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
you're catching on. have another espresso and you'll be there.<br>
<br>
TCP is almost completely independent of the SCCP keepalives.<br>
<br>
this tends to help folks:<br>
SCCP keepalives verify the CM process is still active and processing
traffic. think "application layer"<br>
TCP works at the transport/session layer to verify data makes it over
the network.<br>
<br>
this only becomes confusing because the 'network' doesn't really do
anything by itself. the 'application' must initiate data. at that
point the network must reliably deliver the data. data can be
signaling for an inbound call, signaling for an outbound call,
signaling for an MWI update, signagling for a shared line update, or
data for an SCCP keepalive.<br>
<br>
purely hypothetical numbers here:<br>
Geometric TCP:<br>
tcp retransmits very rapidly at multiples of round trip time. If
normal round trip time is 2msec the phone may retransmit at 2, 4, 8,
and 16 msec. If phone does not receive a TCP ACK within 2+4+8+16msec =
30msec the phone gives up on the TCP session and fails over.<br>
<br>
"Slow Failover" or non-Geometric:<br>
TCP retransmits at 250,400,750, 1400, 2000, 4000,8000,15000 msec
(CSCed01179). Sum = 31.8 seconds. Phone can wait 31 seconds for a TCP
ACK from CM before giving up on TCP session and failing over.<br>
<br>
Geometric TCP is perceived particularly poorly if you have fast but
unreliable network.<br><font color="#888888">
<br>
/wes</font><div><div></div><div class="h5"><br>
<br>
On Monday, May 11, 2009 2:24:46 PM, Justin Steinberg
<a href="mailto:jsteinberg@gmail.com" target="_blank"><jsteinberg@gmail.com></a> wrote:<br>
<blockquote type="cite">nevermind, what i wrote doesn't make any sense.<br>
<br>
I assume it must work something more like, the phones follow the SCCP
keepalive timers defined in the ccmadmin service parameters but when
the KA ACKs begin to fail the phone must use some 'geometric TCP' logic
to force a quicker failover.<br>
<br>
<div class="gmail_quote">On Mon, May 11, 2009 at 2:21 PM, Justin
Steinberg <span dir="ltr"><<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">interesting.
I must have missed this new addition to 7.2(1). So, this means that
with Geometric TCP enabled the phones don't really use the SCCP
keepalive timers configured in the CCMADMIN service parameters
section? They basically come up with a baseline TCP RTT and failover
after that interval passes three times without any response?
<div>
<div><br>
<br>
<div class="gmail_quote">On Mon, May 11, 2009 at 1:18 PM, Wes Sisk <span dir="ltr"><<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">One
more variable I do not see in Ryan's response - Geometric TCP. With
Geometric TCP enabled the phones failover MUCH more aggressively. With
this phone may determine CM is down with only 1.5 second network
outage. With Geometric TCP disabled phone may wait up to 45 seconds to
classify cm as "down" and attempt failover.<br>
<br>
CSCsm81227.<br>
<font color="#888888"><br>
/Wes</font>
<div>
<div><br>
<br>
On Monday, May 11, 2009 11:55:08 AM, Ryan Ratliff <<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So coming back from SRST there are 3 things that have to happen before
the phone will re-register.<br>
1. Establish TCP connection to one of the CMs<br>
2. Wait out the "Connection Monitor Duration" timer so it knows the
connection is stable (Enterprise Params, default 120 secs)<br>
3. Request and receive a registration token from the server indicating
that it can proceed with registration.<br>
<br>
Both connection monitor duration and the registration token mechanisms
are in place to make sure the failback process is as fast and
problem-free as possible.<br>
<br>
In your case is there anything between the sites that could be proxying
the tcp connection from phone to CCM? All "Standby" means is that
there's a TCP session established but it's not actually registered.<br>
<br>
Your best bet is going to be to reset the phone and get a packet
capture. look at the traffic on tcp 2000 to the CCM servers to see
what's going on.<br>
<br>
-Ryan<br>
<br>
On May 11, 2009, at 11:43 AM, Scott Voll wrote:<br>
<br>
no<br>
sub<br>
pub<br>
srst<br>
<br>
<br>
all via IP addresses<br>
<br>
sub -- Standby<br>
pub<br>
SRST -- Active<br>
<br>
Scott<br>
<br>
On Mon, May 11, 2009 at 8:41 AM, Ryan Ratliff <<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>>
wrote:<br>
On the phone what is the list of Communications Manages? Does it
somehow think the SRST is higher in priority than the sub?<br>
<br>
-Ryan<br>
<br>
<br>
On May 11, 2009, at 11:29 AM, Scott Voll wrote:<br>
<br>
I'm banging my head on a wall. What am I missing?<br>
<br>
have a remote site over IPSEC VPN connection back to central CM cluster.<br>
<br>
all has been working fine. but today I find that the three phones (all)
are in SRST mode. the VGW is still registered to the cluster. but from
the web interface of the phones shows reg'd with SRST and standby with
SUB. How does that work?<br>
<br>
I don't really understand the logs on the 7942.<br>
<br>
I can ping from the sub and pub to the phones. any ideas?<br>
<br>
I can attach logs from the phone is that helps.<br>
<br>
Thanks<br>
<br>
Scott<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" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
<br>
<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" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote>
<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" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>