[cisco-voip] Protecting Database replication from publisher to subscriber (SRND page 2-19)

Tue Oct 24 22:08:14 EDT 2006

Thanks, do you know offhand if 4.0x is one of the recent versions with the reason why?

----- Original Message ----
From: Wes Sisk <wsisk at cisco.com>
To: Erick Bergquist <erickbe at yahoo.com>
Cc: Jason Aarons (US) <jason.aarons at us.didata.com>; cisco-voip at puck.nether.net
Sent: Tuesday, October 24, 2006 11:39:56 AM
Subject: Re: [cisco-voip] Protecting Database replication from publisher to subscriber (SRND page 2-19)

check the CM/SDL traces when the link goes down, in recent versions we
say why it went down.  beyond that:

SDL exchanges link polls to make sure each peer is still responding. 
link drops if we don't get a poll response.

either poll did not make it over network, or peer node was too busy
(high CPU/disk I/O) to respond.  Need to identify which.

with just SDL traces from both nodes around the time of outage we can
tell some.

packet capture of data to/from port 8002 that only includes IP&TCP
headers will tell the reset of the story. - no need to capture data.

/Wes

Erick Bergquist wrote:

  Is
there a recommended way to prevent SDL Link error from occurring? I see
these errors about once a week or so for a client with a 3 node cluster
where 1 server is across a MPLS WAN link and no noticable errors/delay
from time to track the cause down usually. 

Thanks, Erick

  -----
Original Message ----

From: Wes Sisk <wsisk at cisco.com>

To: Jason Aarons (US) <jason.aarons at us.didata.com>

Cc: cisco-voip at puck.nether.net

Sent: Monday, October 23, 2006 9:56:24 AM

Subject: Re: [cisco-voip] Protecting Database replication from
publisher to subscriber (SRND page 2-19)

SQL replication isn't so time sensitive.  It's the SDL links
(ccm.exe/ctimanager.exe:random port<->ccm.exe:8002) that are
sensitive to latency/delay.

/Wes

Jason Aarons (US) wrote:

<!--

 _filtered {font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
h4
	{
margin-right:0in;

margin-left:0in;
font-size:12.5pt;
font-family:"Times New Roman";
color:black;
font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
text-decoration:underline;}
p
	{
margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle17
	{
font-family:Arial;
color:windowtext;}
p.DefaultParagraphFontParaCharCharCharChar2CharCharCharChar, li.DefaultParagraphFontParaCharCharCharChar2CharCharCharChar, div.DefaultParagraphFontParaCharCharCharChar2CharCharCharChar
	{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:12.0pt;
font-size:11.0pt;
font-family:Arial;}
_filtered {
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{}
_filtered {
}
_filtered {

text-indent:-.25in;

font-family:Symbol;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->

    In practice has anyone
seen a QoS policy protecting the SQL
intercluster communication/replication? Cisco Engineer is worried about
SQL
replication in a large cluster design. All links meet the 40ms Cluster
Across
WAN requirement, but he’d like to take it further. I’m not sure if
it’s a good idea.

    http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801ffe28.shtml

    Intra-cluster
Communications 
    This is traffic between Cisco
CallManager nodes/servers
themselves, and includes things like Cisco CallManager and computer
telephony
integration (CTI) Manager SDL communications, SQL replication, Server
Message
Block (SMB) communications and CTI/Quick Buffer Encoding (QBE)
activities. If
you have a Layer 3 device that separates Cisco CallManager nodes (by
either WAN
or LAN), you must have a maximum Round Trip Time (RTT) of 40 ms, or 20
ms delay
in either direction. 

    ·        
    Database
replication from publisher to
subscriber uses best effort (DSCP=0) by default. 

    ·        
    Directory
traffic from the LDAP directory
also uses best effort packet marking. 

    ·        
    For real-time
traffic via Intercluster
Communications (ICCS), which includes signaling, call admission
control, and so
forth, as well as CTI Manager realtime traffic, a DSCP value of 26
(AF31 or IP
precedence 3) is used. 

    Standard AutoQoS Policy

    class-map match-any AutoQoS-VoIP-Remark

     match ip dscp ef 

     match ip dscp cs3 

     match ip dscp af31 

    class-map match-any
AutoQoS-VoIP-Control-UnTrust

     match access-group name AutoQoS-VoIP-Control

    class-map match-any AutoQoS-VoIP-RTP-UnTrust

     match protocol rtp audio 

     match access-group name AutoQoS-VoIP-RTCP

    !

    policy-map AutoQoS-Policy-UnTrust

     class AutoQoS-VoIP-RTP-UnTrust

      priority percent 70

      set dscp ef

     class AutoQoS-VoIP-Control-UnTrust

      bandwidth percent 5

      set dscp af31

     class AutoQoS-VoIP-Remark

      set dscp default

     class class-default

      fair-queue

    interface Serial0/0/0

     description SerialT1 

     auto qos voip 

     service-policy output AutoQoS-Policy-UnTrust

    !

    ip access-list extended AutoQoS-VoIP-Control

     permit tcp any any eq 1720

     permit tcp any any range 11000 11999

     permit udp any any eq 2427

     permit tcp any any eq 2428

     permit tcp any any range 2000 2002

     permit udp any any eq 1719

     permit udp any any eq 5060

    ip access-list extended AutoQoS-VoIP-RTCP

     permit udp any any range 16384 32767

    Disclaimer:
This e-mail communication and any attachments may contain confidential
and privileged information and is for use by the designated
addressee(s) named above only. If you are not the intended addressee,
you are hereby notified that you have received this communication in
error and that any use or reproduction of this email or its contents is
strictly prohibited and may be unlawful. If you have received this
communication in error, please notify us immediately by replying to
this message and deleting it from your computer. Thank you. 

_______________________________________________
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/20061024/14ebfa9e/attachment-0001.html 