[cisco-voip] SRST and standby SUB?
Wes Sisk
wsisk at cisco.com
Mon May 11 15:51:49 EDT 2009
spot on.
net result is phones with geometric TCP may (will likely?) failover
faster than any other device. failover depends on TCP:2000 (or
tcp:2443) connectivity.
On Monday, May 11, 2009 3:36:55 PM, Justin Steinberg
<jsteinberg at gmail.com> wrote:
> 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.
>
> 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.
>
> Sorry Scott, didn't mean to take your thread a different direction I
> just found the Geometric TCP interesting.
>
> Justin
>
> On Mon, May 11, 2009 at 2:50 PM, Wes Sisk <wsisk at cisco.com
> <mailto:wsisk at cisco.com>> wrote:
>
> you're catching on. have another espresso and you'll be there.
>
> TCP is almost completely independent of the SCCP keepalives.
>
> this tends to help folks:
> SCCP keepalives verify the CM process is still active and
> processing traffic. think "application layer"
> TCP works at the transport/session layer to verify data makes it
> over the network.
>
> 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.
>
> purely hypothetical numbers here:
> Geometric TCP:
> 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.
>
> "Slow Failover" or non-Geometric:
> 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.
>
> Geometric TCP is perceived particularly poorly if you have fast
> but unreliable network.
>
> /wes
>
>
> On Monday, May 11, 2009 2:24:46 PM, Justin Steinberg
> <jsteinberg at gmail.com> <mailto:jsteinberg at gmail.com> wrote:
>> nevermind, what i wrote doesn't make any sense.
>>
>> 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.
>>
>> On Mon, May 11, 2009 at 2:21 PM, Justin Steinberg
>> <jsteinberg at gmail.com <mailto:jsteinberg at gmail.com>> wrote:
>>
>> 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?
>>
>>
>> On Mon, May 11, 2009 at 1:18 PM, Wes Sisk <wsisk at cisco.com
>> <mailto:wsisk at cisco.com>> wrote:
>>
>> 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.
>>
>> CSCsm81227.
>>
>> /Wes
>>
>>
>> On Monday, May 11, 2009 11:55:08 AM, Ryan Ratliff
>> <rratliff at cisco.com <mailto:rratliff at cisco.com>> wrote:
>>
>> So coming back from SRST there are 3 things that have
>> to happen before the phone will re-register.
>> 1. Establish TCP connection to one of the CMs
>> 2. Wait out the "Connection Monitor Duration" timer
>> so it knows the connection is stable (Enterprise
>> Params, default 120 secs)
>> 3. Request and receive a registration token from the
>> server indicating that it can proceed with registration.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> -Ryan
>>
>> On May 11, 2009, at 11:43 AM, Scott Voll wrote:
>>
>> no
>> sub
>> pub
>> srst
>>
>>
>> all via IP addresses
>>
>> sub -- Standby
>> pub
>> SRST -- Active
>>
>> Scott
>>
>> On Mon, May 11, 2009 at 8:41 AM, Ryan Ratliff
>> <rratliff at cisco.com <mailto:rratliff at cisco.com>> wrote:
>> On the phone what is the list of Communications
>> Manages? Does it somehow think the SRST is higher in
>> priority than the sub?
>>
>> -Ryan
>>
>>
>> On May 11, 2009, at 11:29 AM, Scott Voll wrote:
>>
>> I'm banging my head on a wall. What am I missing?
>>
>> have a remote site over IPSEC VPN connection back to
>> central CM cluster.
>>
>> 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?
>>
>> I don't really understand the logs on the 7942.
>>
>> I can ping from the sub and pub to the phones. any
>> ideas?
>>
>> I can attach logs from the phone is that helps.
>>
>> Thanks
>>
>> Scott
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> <mailto: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/20090511/3b7397cc/attachment.html>
More information about the cisco-voip
mailing list