[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