[cisco-voip] SRST and standby SUB?

Tue May 12 14:28:10 EDT 2009

Scott,

I have seen this in the past where the ASA will "shun" packets to CCM
servers.

Take a look at the ASA logs and see if you see any entries for shun
packets.  This is a "feature" in the ASA to keep from packet spoofing and
flooding.

Craig

On Tue, May 12, 2009 at 8:13 AM, Scott Voll <svoll.voip at gmail.com> wrote:

> Rebooted my cluster.... upgraded OS stuff while I was at it.
> still didn't fix the issue.  So i rebooted the ASA at the remote site.
>  magically it was fixed.  We were having lots of connectivity issues there
> before it happened so I'm assuming that the IPSEC tunnel got messed up a
> little.  we did try to reset the tunnel with no resolution, but a reboot of
> the ASA fixed it.
>
> Just wanted to follow up in case anyone else ends up with the issue in the
> future and googles this thread.
>
> Thanks all
>
> Scott
>
> On Mon, May 11, 2009 at 7:51 PM, Jason Burns <burns.jason at gmail.com>wrote:
>
>> Scott,
>>
>> Posting the "Debug Display" and "Status Messages" section of the phone web
>> page might be helpful. Usually when a phone fails over it throws some error
>> messages in there.
>>
>>
>> On Mon, May 11, 2009 at 3:51 PM, Wes Sisk <wsisk at cisco.com> wrote:
>>
>>>  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> <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> 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> <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
>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090512/d3f709f1/attachment.html>