[cisco-voip] Protecting Database replication from publisher to subscriber (SRND page 2-19)
Erick Bergquist
erickbe at yahoo.com
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
More information about the cisco-voip
mailing list