[cisco-voip] SRST and standby SUB?

[Ryan Ratliff]

SCCP and its keepalives are layer 7.  Geometric TCP is all layer 3  
and determines how fast the TCP session itself gets timed out due to  
lack of TCP acknowledgments.   The only time you'll see a phone reset  
due to missing sccp keepalives is if the network stack on the CUCM  
server is sending TCP Acks but the CCM process is out to lunch and  
not sending the sccp keepalive acks.  99% of the time whatever causes  
CCM to out to lunch also prevents the server from sending TCP Acks so  
you'll see the phone break the TCP session long before the sccp  
keepalive timeout happens.

-Ryan

On May 11, 2009, at 2:24 PM, Justin Steinberg 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> 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> 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> 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>  
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
https://puck.nether.net/mailman/listinfo/cisco-voip



_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip